Let's Encrypt & Certbot: HTTPS i 14 Steg [2026]

Nittio dagar. Så länge lever ett standardcertifikat från Let’s Encrypt innan det slutar fungera och webbläsaren visar en varningssida i stället för ditt innehåll. Glömmer du att förnya det manuellt förlorar du trafik, SEO-ranking och förtroende på minuter. Det är därför automatisering inte längre är en “nice to have” för svenska och nordiska driftteam, utan grundkravet för att köra HTTPS överhuvudtaget. Enligt Let’s Encrypts egen dokumentation utfärdas certifikat via ett helt automatiserat API baserat på ACME-protokollet, byggt just för att eliminera det manuella steget. I den här guiden bygger vi den automatiseringen från grunden: från installation av Certbot till ett komplett produktionsklart projekt med flerdomänstöd, övervakning och automatisk förnyelse. Vi går igenom 14 konkreta steg, kodblock du kan klistra in direkt i terminalen, och de fallgropar som får svenska admin-team att vakna klockan tre på natten till en utgången TLS-kedja.

Vad är Let’s Encrypt och varför spelar gratis SSL roll 2026

Let’s Encrypt är en icke-vinstdrivande certifikatutfärdare som drivs av Internet Security Research Group (ISRG) och som sedan 2015 delat ut TLS-certifikat helt gratis. Skillnaden mot äldre certifikatutfärdare handlar inte bara om pris, utan om arbetsflöde: allt sköts via API i stället för manuella formulär, betalningar och veckolånga väntetider. Enligt data från W3Techs, uppdaterad 1 september 2026, används Let’s Encrypt av 67,7 procent av alla webbplatser vars certifikatutfärdare är känd, motsvarande 64,4 procent av samtliga undersökta webbplatser globalt. I Sverige är siffran ännu högre. W3Techs geografiska data från 11 maj 2026 visar att 85,6 procent av svenskhostade webbplatser med känd utfärdare kör på Let’s Encrypt, långt före GlobalSign (6,6 procent) och DigiCert Group (5,2 procent). Analystjänsten BuiltWith räknade under 2026 in 557 910 svenska domäner som aktivt använder tjänsten.

Skalan är svår att greppa utan siffror. Let’s Encrypt säkrar i dag mer än 700 miljoner webbplatser och har enligt organisationens egen årsrapport utfärdat över 7 miljarder certifikat sedan starten, med toppar på nästan 10 miljoner utfärdade certifikat under enskilda dygn. Det gör tjänsten till den de facto-standard som de flesta hostingleverantörer, CDN-tjänster och kontrollpaneler (cPanel, Plesk, DirectAdmin) bygger in som förval. Men förvalet räcker inte för egna servrar, VPS-instanser eller specialbyggda API-tjänster. Där måste du själv sätta upp Certbot eller en likvärdig ACME-klient, och det är precis det den här guiden lär dig göra korrekt första gången.

Värt att komma ihåg är att Let’s Encrypt bara utfärdar domänvaliderade (DV) certifikat. De bekräftar att du kontrollerar en domän, inte vem du eller din organisation faktiskt är. Behöver ni organisationsvaliderade (OV) eller utökat validerade (EV) certifikat, till exempel för vissa finansiella tjänster där kunden förväntar sig att se organisationens namn i certifikatdetaljerna, måste ni fortfarande vända er till en kommersiell certifikatutfärdare. För den absoluta majoriteten av webbplatser, API:er och interna tjänster räcker DV-certifikat gott och väl, vilket är en stor del av förklaringen till varför Let’s Encrypt tagit över så stor del av marknaden på bara elva år.

Så fungerar ACME-protokollet steg för steg

ACME står för Automated Certificate Management Environment och är det protokoll som Let’s Encrypt byggde och som senare standardiserades av IETF. Enligt Certbots officiella dokumentation är “målet med Certbot, Let’s Encrypt och ACME-protokollet att göra det möjligt att sätta upp en HTTPS-server och automatiskt få ett webbläsarbetrott certifikat, utan mänsklig inblandning” (Certbot manual, Ubuntu-paketet). I praktiken sker fyra saker när du kör en ACME-klient: klienten registrerar ett konto hos utfärdaren, den bevisar att du kontrollerar domänen genom en utmaning (challenge), utfärdaren signerar ett certifikat baserat på en nyckel du genererar lokalt, och klienten installerar certifikatet i din webbserver. Ingen privat nyckel lämnar någonsin din server, vilket är en viktig skillnad mot äldre manuella processer där du skickade en Certificate Signing Request via e-post.

De två vanligaste utmaningstyperna är HTTP-01 och DNS-01. Vid HTTP-01 lägger klienten en tillfällig fil på din webbserver som utfärdaren hämtar över port 80 för att bekräfta att du äger domänen. Vid DNS-01 skapar klienten i stället en TXT-post i din DNS-zon. Let’s Encrypts egen dokumentation om utmaningstyper beskriver DNS-01 som “svårare att konfigurera än HTTP-01, men nödvändig för wildcardcertifikat och i situationer där HTTP-01 inte kan användas”, medan HTTP-01 förblir den enklaste och vanligaste valideringsmetoden. Som tumregel: kör HTTP-01 för enskilda värdnamn på en vanlig webbserver, och DNS-01 när du behöver wildcard eller kör bakom en proxy som gör HTTP-valideringen opålitlig.

Vill du förstå grunderna kring vad ett hänglåsikon och certifikat faktiskt innebär för besökaren innan du går vidare, har vi tidigare förklarat HTTPS och TLS: hänglåset, certifikat och vad de skyddar mer konceptuellt. Den här guiden bygger vidare på det och går rakt in i själva driftarbetet: kommandon, konfigurationsfiler och automation snarare än teori.

Certifikaten som Let’s Encrypt utfärdar kedjas upp mot det egna rotcertifikatet ISRG Root X1, som numera är direkt inbyggt och betrott i alla större webbläsare och operativsystem, inklusive äldre Android-versioner tack vare en tidigare korssignering med IdenTrust. Det betyder att du i praktiken aldrig behöver installera något extra rotcertifikat manuellt på klientsidan. Det enda du hanterar är mellancertifikatet (intermediate) och ditt eget certifikat, vilket är precis vad filen fullchain.pem innehåller. Serverar du bara cert.pem för sig själv, utan mellancertifikatet, fungerar sajten i moderna webbläsare som redan cachar mellanledet, men fallerar i äldre klienter, API-bibliotek och en del mobilappar som inte gör det, vilket är en av de vanligaste källorna till “certifikatet fungerar för mig men inte för kunden”-buggar.

Förutsättningar: detta behöver du innan du börjar

Innan du sätter i gång behöver du en handfull saker på plats. Först en server med root- eller sudo-åtkomst som kör Ubuntu 24.04 LTS, Debian 12 eller motsvarande, med en publik IP-adress. Du behöver en registrerad domän där du kontrollerar DNS-zonen, och en webbserver som redan svarar på port 80: Nginx 1.30.4 (stabil gren) eller Apache HTTP Server 2.4.68 fungerar båda utmärkt med Certbots officiella plugins. Certbot självt bör vara version 5.8.0 eller senare, som var den aktuella utgåvan per 1 september 2026 enligt projektets releaseanteckningar. Du behöver också portarna 80 och 443 öppna i brandväggen, både på servern och i eventuell molnleverantörs säkerhetsgrupp, eftersom både HTTP-01-validering och själva HTTPS-trafiken passerar dessa portar.

Komponent	Rekommenderad version (sep 2026)	Syfte i guiden
Certbot	5.8.0 eller senare	ACME-klient som hämtar och installerar certifikat
Nginx	1.30.4 (stabil gren)	Webbserver, Certbot-plugin för automatisk konfiguration
Apache HTTP Server	2.4.68	Alternativ webbserver med mod_ssl
Ubuntu Server	24.04 LTS	Testad OS-bas för snap-paketet certbot
Python	3.12 eller senare (via snapd)	Körmiljö för Certbots snap-paket
OpenSSL	3.x (systempaket)	Nyckelgenerering och certifikatverifiering

Har du redan läst vår guide om OpenSSL: nycklar och certifikat i 12 steg känner du igen en del av grunderna kring nycklar och signering. Skillnaden här är att vi automatiserar hela livscykeln i stället för att hantera certifikat manuellt.

Steg 1: Kontrollera DNS och öppna rätt portar

Innan Certbot ens installeras, verifiera att domänen faktiskt pekar mot rätt server. Ett vanligt misstag är att köra valideringen mot en server vars DNS-post fortfarande pekar mot en gammal IP-adress eller en staging-miljö.

dig +short exempel.se A
dig +short www.exempel.se A
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status verbose

Kontrollera att svaret från dig matchar din servers publika IP exakt. Om du kör bakom Cloudflare eller en annan proxy måste du tillfälligt sätta DNS-posten till “endast DNS” (grått moln) under valideringen, annars kan HTTP-01-utmaningen misslyckas eftersom trafiken aldrig når din faktiska server.

Steg 2: Installera Certbot på servern

Certbot-projektet rekommenderar numera snap-paketet framför distributionens egna apt-paket, eftersom snap uppdateras oftare och därmed håller sig närmare den senaste versionen. Certbots officiella klientdokumentation säger rakt ut att “de flesta bör börja med Certbot-klienten. Den kan antingen bara hämta ett certifikat åt dig eller hjälpa till att installera det, beroende på vad du föredrar” (Let’s Encrypt, klientalternativ).

sudo apt update
sudo apt install snapd -y
sudo snap install core; sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
certbot --version

Kommandot certbot --version bör svara med 5.x. Om det svarar med en betydligt äldre version, till exempel 1.x eller 2.x från apt-förrådet, avinstallera det paketet först med sudo apt remove certbot innan du fortsätter, annars riskerar du konflikter mellan två parallella installationer.

Steg 3: Välj Certbot-plugin för din webbserver

Certbot är byggt kring plugins som pratar direkt med din webbserver. För Nginx installerar du pluginet separat via snap, medan Apache-pluginet ofta redan följer med. Att välja rätt plugin avgör om Certbot bara hämtar certifikatet (webroot-läge) eller om det även skriver om din serverkonfiguration åt dig (installer-läge).

sudo snap install certbot-dns-cloudflare
certbot plugins
# Förväntad utskrift inkluderar: nginx, apache, webroot, standalone, dns-cloudflare

Webroot-pluginet är det säkraste valet om du inte vill att Certbot ska röra din befintliga serverkonfiguration alls, eftersom det bara lägger en fil i en katalog som redan serveras. Installer-pluginen (nginx, apache) är snabbare för nya installationer men skriver om konfigurationsfiler, vilket kan skapa oväntade diffar om du hanterar konfiguration via Ansible eller Terraform.

Steg 4: Hämta ditt första certifikat med HTTP-01

Med Nginx redan igång och lyssnande på port 80 kan du nu begära ditt första certifikat. Certbots nginx-plugin sköter både validering och installation i ett enda kommando.

sudo certbot --nginx -d exempel.se -d www.exempel.se \
  --email [email protected] --agree-tos --no-eff-email

# Exempelutskrift vid lyckad körning:
# Successfully received certificate.
# Certificate is saved at: /etc/letsencrypt/live/exempel.se/fullchain.pem
# Key is saved at:         /etc/letsencrypt/live/exempel.se/privkey.pem
# This certificate expires on 2026-12-01.

Notera datumet i utskriften. Ett standardcertifikat från Let’s Encrypt gäller i 90 dagar, och organisationen rekommenderar att förnyelse sker var 60:e dag, alltså med god marginal innan utgång. Den principen bygger på ett medvetet designval snarare än en teknisk begränsning. Let’s Encrypt skrev redan i sitt ursprungliga blogginlägg om kortlivade certifikat att “om vi ska flytta hela webben till HTTPS kan vi inte fortsätta förvänta oss att systemadministratörer manuellt hanterar förnyelser” (Let’s Encrypt, blogginlägg 2015), en logik som fortfarande styr produktens utveckling elva år senare.

Steg 5: Låt Certbot konfigurera Nginx automatiskt

Om du körde kommandot i steg 4 med --nginx-flaggan har Certbot redan skrivit om din serverkonfiguration åt dig, lagt till en listen 443 ssl-sektion och en omdirigering från HTTP till HTTPS. Granska alltid resultatet innan du går vidare.

sudo nginx -t
sudo cat /etc/nginx/sites-available/exempel.se | grep -A2 "listen 443"
sudo systemctl reload nginx

nginx -t testar konfigurationssyntaxen utan att faktiskt ladda om servern, vilket gör att du fångar fel innan de orsakar driftstopp. Kör alltid det kommandot före reload, särskilt om du har redigerat filerna manuellt efter att Certbot körts.

Steg 6: Konfigurera Apache som alternativ

Kör du Apache HTTP Server 2.4.68 i stället är processen nästan identisk, men pluginet heter apache och kräver att modulen mod_ssl är aktiverad.

sudo a2enmod ssl
sudo apt install python3-certbot-apache -y
sudo certbot --apache -d exempel.se -d www.exempel.se \
  --email [email protected] --agree-tos --no-eff-email
sudo apachectl configtest
sudo systemctl reload apache2

Apache-pluginet skriver certifikatsökvägarna direkt in i din VirtualHost-konfiguration under /etc/apache2/sites-available/. Precis som med Nginx bör du köra configtest innan omladdning, eftersom ett felaktigt certifikatsökväg-fel annars stoppar hela Apache-processen vid omstart, inte bara den enskilda webbplatsen.

Steg 7: Sätt upp DNS-01 för wildcardcertifikat

Vill du säkra *.exempel.se med ett enda certifikat måste du använda DNS-01-validering, eftersom HTTP-01 inte kan bevisa kontroll över en hel wildcard-domän. Certbot har officiella DNS-plugins för de flesta stora DNS-leverantörer, inklusive Cloudflare.

# Skapa en Cloudflare API-token med behörigheten Zone:DNS:Edit
sudo nano /etc/letsencrypt/cloudflare.ini
# Innehåll: dns_cloudflare_api_token = din_token_har
sudo chmod 600 /etc/letsencrypt/cloudflare.ini

sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d exempel.se -d "*.exempel.se"

Filrättigheten 600 på ini-filen är inte kosmetisk. Ligger API-token läsbar för andra användare på servern har vem som helst med ett lokalt skal möjlighet att skapa och radera DNS-poster i din zon, vilket i praktiken ger dem full kontroll över domänen.

Steg 8: Automatisera förnyelse med systemd timer

Snap-installationen av Certbot sätter normalt upp en systemd-timer automatiskt, men det är värt att verifiera den manuellt i stället för att lita blint på förvalet.

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

# Förväntad utskrift:
# Congratulations, all simulated renewals succeeded:
#   /etc/letsencrypt/live/exempel.se/fullchain.pem (success)

Timern kör normalt kommandot certbot renew två gånger per dygn men förnyar bara certifikat som är inom 30 dagar från utgång, så dubbelkörningarna orsakar inte onödiga anrop mot Let’s Encrypts API. Saknas timern helt, till exempel för att du installerade via ett äldre apt-paket, lägg till den manuellt via cron i stället.

echo "0 3,15 * * * root certbot renew --quiet --deploy-hook 'systemctl reload nginx'" | sudo tee /etc/cron.d/certbot-renew

Flaggan --deploy-hook är central. Utan den byts certifikatfilerna ut på disk, men den redan körande Nginx-processen fortsätter använda det gamla certifikatet i minnet tills en manuell omladdning sker, vilket gör att du fortfarande drabbas av ett utgånget certifikat trots att förnyelsen “lyckades”.

Steg 9: Testa TLS-konfigurationen med SSL Labs

Ett giltigt certifikat garanterar inte en säker TLS-konfiguration. Föråldrade chiffersviter, saknad HSTS-header eller kvarvarande stöd för TLS 1.0 sänker fortfarande betyget. Kör din domän genom Qualys SSL Labs-test efter varje större konfigurationsändring.

curl -sI https://exempel.se | grep -i strict-transport
openssl s_client -connect exempel.se:443 -servername exempel.se /dev/null | openssl x509 -noout -dates

Det andra kommandot skriver ut certifikatets giltighetsperiod direkt i terminalen utan att öppna en webbläsare, praktiskt för att snabbt bekräfta att förnyelsen faktiskt applicerades efter en cron-körning.

Certbot bakom lastbalanserare och i molnmiljöer

Kör ni infrastruktur i AWS, Azure eller GCP bakom en lastbalanserare blir bilden lite mer komplicerad, eftersom Let’s Encrypts valideringstrafik måste nå fram till exakt den server som begär certifikatet. Med HTTP-01 innebär det att lastbalanseraren måste rikta förfrågningar på sökvägen /.well-known/acme-challenge/ till rätt bakomliggande instans, vilket i praktiken oftast löses genom att köra certifikatutfärdandet centraliserat på en enda “certifikat-nod” och sedan distribuera resultatet, eller genom att låta lastbalanseraren själv hantera TLS-terminering (till exempel en AWS Application Load Balancer med ACM, eller Azure Front Door). Har ni redan följt vår guide för att härda Azure IAM och Storage känner ni igen samma princip: centralisera känsliga hemligheter, i det här fallet privata nycklar, till så få platser som möjligt i stället för att sprida ut dem på varje enskild nod.

Ett vanligt mönster i containermiljöer är att lägga certifikathanteringen i en separat sidecar eller init-container som delar en volym med webbservern, så att själva applikationscontainern aldrig behöver root-rättigheter eller nätverksåtkomst till port 80. Kör ni Kubernetes fullt ut byter de flesta ut Certbot mot cert-manager, som gör samma sak deklarativt via Kubernetes-resurser i stället för cron-jobb, men den underliggande ACME-logiken, HTTP-01 eller DNS-01, är identisk med vad vi gått igenom här.

Steg 10: Bygg ett komplett projekt – flerdomänserver med autoförnyelse

Nu sätter vi ihop allt till ett fungerande projekt: en Nginx-server som hanterar tre olika domäner, var och en med eget certifikat, plus ett övervakningsskript som larmar om något går fel. Strukturen nedan är tänkt att klonas rakt av till en produktionsserver.

#!/bin/bash
# fil: /opt/ssl-projekt/setup-domaner.sh
set -euo pipefail

DOMANER=("exempel.se" "app.exempel.se" "api.exempel.se")
EMAIL="[email protected]"

for DOMAN in "${DOMANER[@]}"; do
  echo "Bearbetar $DOMAN..."
  sudo certbot --nginx -d "$DOMAN" \
    --email "$EMAIL" --agree-tos --no-eff-email \
    --non-interactive --redirect
done

sudo nginx -t && sudo systemctl reload nginx
echo "Klart. Kör 'certbot certificates' for att se status."

Flaggan --redirect tvingar all HTTP-trafik till HTTPS automatiskt, medan --non-interactive gör att skriptet kan köras obevakat, exempelvis från en provisioneringsprocess i Ansible eller som en del av en ny servers cloud-init. Kör skriptet en gång per ny domän du lägger till i arrayen, så byggs certifikatlagret upp domän för domän utan manuella steg.

Lägg därefter till ett litet larmskript som körs varje morgon och mejlar dig om något certifikat har färre än 14 dagar kvar, vilket fångar upp fall där den automatiska förnyelsen av någon anledning har misslyckats tyst.

#!/bin/bash
# fil: /opt/ssl-projekt/kontrollera-utgang.sh
for CERT in /etc/letsencrypt/live/*/fullchain.pem; do
  DOMAN=$(basename "$(dirname "$CERT")")
  UTGANGSDATUM=$(openssl x509 -enddate -noout -in "$CERT" | cut -d= -f2)
  KVAR=$(( ($(date -d "$UTGANGSDATUM" +%s) - $(date +%s)) / 86400 ))
  if [ "$KVAR" -lt 14 ]; then
    echo "VARNING: $DOMAN har bara $KVAR dagar kvar" | \
      mail -s "SSL-varning: $DOMAN" [email protected]
  fi
done

Lägg detta skript i samma cron-post som körs dagligen. Nu har du ett komplett, självförnyande system: certifikat hämtas, installeras, förnyas automatiskt och övervakas, allt utan att någon behöver logga in manuellt så länge DNS och portar förblir korrekt konfigurerade.

Steg 11: Övervaka certifikat och sätt upp varningar

Utöver mejlvarningen i föregående steg bör du koppla certifikatstatus till din befintliga övervakningsstack. Har ni redan Wazuh SIEM uppsatt för att upptäcka dataintrång kan samma agent enkelt utökas med en fil-integritetskontroll på katalogen /etc/letsencrypt/live/, vilket ger er en logghändelse varje gång ett certifikat faktiskt byts ut, användbart för att bekräfta att förnyelser sker enligt schema och inte bara att de “borde” göra det.

certbot certificates
# Utskrift visar: Domains, Expiry Date, Certificate Path, Renewal Date

Kör detta kommando som en del av er standardiserade veckovisa driftgenomgång. Det är den snabbaste vägen att se status för samtliga certifikat på en server i en enda utskrift, utan att behöva öppna varje certifikatfil manuellt.

Steg 12: Hantera 6-dagars kortlivade certifikat och IP-certifikat

Den 15 januari 2026 gjorde Let’s Encrypt sina kortlivade certifikat, giltiga i 160 timmar (drygt sex dygn), samt IP-adresscertifikat allmänt tillgängliga. Standardcertifikat på 90 dagar är fortfarande det som de flesta använder, men den nya profilen shortlived är byggd för miljöer med extremt hög automationsgrad, till exempel Kubernetes-kluster där certifikat roteras via en operator snarare än en människa. IP-certifikat, definierade i RFC 8738, gör det möjligt att säkra en ren IP-adress utan associerat domännamn, men de måste enligt Let’s Encrypts dokumentation alltid använda den kortlivade profilen och kan bara valideras via HTTP-01 eller TLS-ALPN-01, inte DNS-01.

sudo certbot certonly --standalone --preferred-profile shortlived \
  -d api.exempel.se --email [email protected] --agree-tos

Använder du kortlivade certifikat måste förnyelsecykeln vara betydligt tätare. Let’s Encrypts egen rekommendation är att förnya var tredje dag för sexdagarscertifikat, jämfört med var 60:e dag för standardcertifikat. Justera din systemd-timer eller cron-frekvens därefter, annars hinner certifikatet gå ut mellan körningarna.

Steg 13: Håll ACME-klienten säker mot kända sårbarheter

Inga Certbot-specifika sårbarheter har publicerats under 2025–2026, men det gäller inte hela ACME-klientekosystemet. Go-biblioteket lego, som ligger under flera alternativa klienter och integrationer, hade CVE-2026-40611: en path traversal-brist i webroot-providern för HTTP-01-utmaningar där en illasinnad ACME-server kunde skicka manipulerade utmaningstoken för att skriva eller radera godtyckliga filer. Felet fixades i lego 4.34.0. Ett tidigare fel, CVE-2025-54799, innebar att lego-versioner 4.25.1 och äldre inte tvingade fram HTTPS för ACME-katalog- och order-URL:er, vilket kunde tillåta ACME-anrop över oskyddad HTTP vid felkonfiguration; det åtgärdades i 4.25.2. Kör du någon integration byggd på lego, kontrollera versionen explicit.

# Om ni kör lego direkt (t.ex. via QNAP eller egen integration):
lego --version
# Bör visa v5.0.4 eller senare

Har ni tidigare byggt en mTLS-lösning med Nginx för att säkra interna API:er, notera att Let’s Encrypt den 8 juli 2026 permanent avvecklade sin tlsclient-profil som tidigare stödde klientautentisering (clientAuth). Standardprofilen classic tappade redan clientAuth-stödet den 11 februari 2026. Behöver ni fortfarande publika certifikat för klientautentisering måste ni använda en privat CA i stället, exakt det upplägg vår mTLS-guide beskriver.

Steg 14: Förbered dig för kortare certifikatlivslängder 2027-2029

CA/Browser Forum, branschorganet som sätter reglerna för publika certifikat, har lagt fast en tidslinje som gradvis krymper hur länge ett TLS-certifikat får vara giltigt. Maxlivslängden sänktes från 398 till 200 dagar den 15 mars 2026. Nästa sänkning, till 100 dagar, sker den 15 mars 2027, och den sista sänkningen landar på 47 dagar i mars 2029. Let’s Encrypts satsning på sex- och fyrtiofem-dagarsprofiler ligger alltså före kurvan snarare än att vara en udda avvikelse: hela branschen rör sig mot samma mål, kortare livslängd för att minska skadan av läckta nycklar och tvinga fram fungerande automatisering hos alla aktörer, inte bara de mest avancerade.

Datum	Maximal certifikatlivslängd	Vad ni bör göra nu
15 mars 2026 (gällande)	200 dagar	Verifiera att förnyelseautomationen redan körs, inte manuellt
15 mars 2027	100 dagar	Testa förnyelsefrekvens och deploy-hooks i god tid
Mars 2029	47 dagar	Utvärdera kortlivade profiler (6 dagar) som standard

Om er organisation fortfarande förnyar certifikat manuellt via ett formulär hos leverantören är det här den tydligaste anledningen att migrera till Certbot eller en likvärdig ACME-klient nu, inte om ett år. Fönstret för att missa en förnyelse krymper i takt med att maxlivslängden gör det.

Certbot mot andra ACME-klienter: vilken passar er miljö

Certbot är standardvalet på Linux-servrar, men det finns situationer där en alternativ klient passar bättre, till exempel på Windows-servrar eller i extremt resursbegränsade containrar.

Klient	Aktuell version (2026)	Bäst för	Språk/beroenden
Certbot	5.8.0	Linux-servrar med Nginx/Apache, officiellt Let’s Encrypt-verktyg	Python, snap
acme.sh	3.1.4	Minimala servrar, skriptbara pipelines utan Python-beroende	Ren shell/bash
lego	v5.0.4	Go-baserade integrationer, inbäddad i andra verktyg (t.ex. Traefik)	Go, enskild binär
win-acme	v2.2.9.x	Windows Server med IIS	.NET

För de flesta svenska driftmiljöer med Nginx eller Apache på Linux är Certbot fortfarande rätt förstahandsval eftersom det är officiellt underhållet av Let’s Encrypt-teamet, har flest plugins och den mest aktiva dokumentationen. Kör ni redan container-baserad infrastruktur och behöver certifikatutfärdande direkt inbyggt i en reverse proxy, till exempel Traefik eller Caddy, hanteras det oftast redan internt via lego eller en egen ACME-implementation, och då behöver ni sällan installera Certbot separat alls.

5 vanliga fallgropar när du automatiserar SSL

De flesta problem med Let’s Encrypt-automation dyker inte upp under det första testet, utan veckor eller månader senare, när något i miljön runtomkring har förändrats. Nedan är de fem misstag vi ser återkommande hos team som satt upp automationen korrekt från början men missat en detalj som senare orsakar ett produktionsavbrott.

Glömd deploy-hook. Certifikatfilen uppdateras på disk, men webbservern laddas aldrig om, så den gamla, snart utgångna nyckeln fortsätter användas i produktion tills nästa manuella omstart.
Brandvägg som blockerar port 80 permanent. Många team stänger port 80 helt av säkerhetsskäl efter att HTTPS satts upp, vilket bryter framtida HTTP-01-förnyelser eftersom valideringen kräver att porten är öppen, inte bara vid första utfärdandet.
Rate limits underskattade vid testning. Let’s Encrypt begränsar hur många certifikat som kan utfärdas per registrerad domän per vecka. Testar ni upprepade gånger mot produktionsmiljön i stället för stagingservern --test-cert riskerar ni att låsas ute i flera dagar.
Felaktiga filrättigheter på privata nycklar. Certbot sätter normalt strikta rättigheter automatiskt, men egna skript som kopierar privkey.pem till andra kataloger glömmer ofta att återställa behörigheten, vilket exponerar nyckeln för andra lokala användare.
DNS-01-autentisering med för breda API-rättigheter. En Cloudflare-token med full kontoåtkomst i stället för begränsad Zone:DNS:Edit-behörighet blir ett enormt attackyta om servern komprometteras, eftersom angriparen då kan ändra samtliga DNS-zoner på kontot, inte bara den aktuella domänen.

Felsökning: 8 vanliga problem och lösningar

När något går fel är felmeddelandet från Certbot ofta tydligare än man förväntar sig, men det kräver att man vet vilken av flera möjliga orsaker som ligger bakom en given textrad. Här är de åtta felen vi stöter på oftast, med den konkreta åtgärden för varje.

“Timeout during connect” vid HTTP-01. Kontrollera att port 80 verkligen är öppen utåt med curl -I http://din-domän.se från en extern server, inte bara lokalt på maskinen.
“DNS problem: NXDOMAIN looking up A record”. Domänen finns inte i publik DNS ännu, eller propageringen har inte hunnit slå igenom. Vänta och kontrollera med dig mot flera olika DNS-servrar, till exempel 1.1.1.1 och 8.8.8.8.
“too many certificates already issued”. Ni har träffat rate limit-gränsen. Vänta ut den angivna tidsperioden i felmeddelandet eller kör om mot stagingmiljön med --test-cert under felsökning.
Nginx laddar inte om efter förnyelse. Verifiera att deploy-hooken faktiskt är kopplad med certbot renew --dry-run -v och läs igenom loggen för att se om hooken kördes eller hoppades över.
“unable to get local issuer certificate” i klientprogram. Webbservern serverar bara cert.pem i stället för hela kedjan i fullchain.pem. Peka konfigurationen om till rätt fil.
Certbot hittar inte pluginet för webbservern. Kör certbot plugins för att se installerade plugins; saknas nginx- eller apache-pluginet, installera det separat enligt steg 3.
Snap-versionen av Certbot uppdateras inte automatiskt. Snap uppdaterar normalt sig själv, men kontrollera manuellt med sudo snap refresh certbot om ni misstänker att ni kör en föråldrad version.
Wildcardcertifikat fungerar inte trots giltig DNS-post. DNS-01-TXT-posten måste hinna propagera globalt innan Let’s Encrypt validerar den. Certbots DNS-plugins har oftast en inbyggd väntetid, men vid egna skript, lägg in en manuell paus på minst 30–60 sekunder innan valideringssteget körs.

Avancerade tips för produktionsmiljöer

När grundautomationen fungerar finns det flera lager du kan lägga på för att göra driften mer robust. Först, kör certbot renew med --deploy-hook snarare än separata pre-hook/post-hook-flaggor när ni bara behöver ladda om en enskild tjänst, eftersom deploy-hooken bara körs om ett certifikat faktiskt förnyades, vilket sparar onödiga omladdningar. För flerserverinstallationer bakom en lastbalanserare, centralisera certifikatutfärdandet till en enda nod med DNS-01-validering och synkronisera sedan certifikatfilerna till övriga noder via ett verktyg som rsync eller en delad volym, i stället för att låta varje nod göra egen HTTP-01-validering, vilket annars snabbt kolliderar med rate limits.

Överväg också OCSP-häftning (OCSP stapling) i er Nginx- eller Apache-konfiguration för att minska latensen klienter upplever vid återkallelsekontroll, och sätt alltid en explicit Strict-Transport-Security-header med en lång max-age så snart certifikatet är verifierat stabilt, inte redan under den första testperioden då ni fortfarande kan behöva rulla tillbaka till HTTP. Slutligen, om er organisation omfattas av NIS2 och cybersäkerhetslagen, dokumentera certifikatautomationen som en del av er tekniska säkerhetsdokumentation. Ett utgånget certifikat som orsakar ett tjänsteavbrott räknas i många fall som en rapporteringspliktig incident om tjänsten är samhällsviktig.

Ett annat lager värt att bygga in tidigt är Certificate Transparency-loggövervakning. Varje certifikat som Let’s Encrypt utfärdar publiceras offentligt i CT-loggar, vilket är bra för öppenhet men också innebär att vem som helst kan se exakt vilka subdomäner ni har certifikat för. Prenumerera på CT-loggar för er egen domän, till exempel via en tjänst som crt.sh, så upptäcker ni om ett certifikat utfärdas för en subdomän ni inte kände till, ett tecken på antingen ett glömt testsystem eller ett tecken på att någon annan lyckats validera kontroll över en del av er DNS-zon. Testa också alltid nya konfigurationsändringar mot Let’s Encrypts staging-miljö med flaggan --test-cert innan ni kör mot produktions-API:et. Staging-certifikat är inte webbläsarbetrodda, men de räknas inte mot de skarpa rate limits, vilket gör att ni kan iterera fritt under felsökning utan att riskera att låsas ute från riktiga certifikat i flera dagar.

sudo certbot --nginx -d exempel.se --test-cert --dry-run
curl -s "https://crt.sh/?q=exempel.se&output=json" | python3 -m json.tool | head -20

Slutligen, håll koll på hur många domäner en enskild server hanterar. Let’s Encrypt sätter en gräns på 50 domännamn per certifikat, och organisationens rate limits (som förnyas veckovis) är satta per registrerad domän, inte per subdomän. Hanterar ni hundratals kundspecifika subdomäner på samma infrastruktur, till exempel i en multi-tenant SaaS-plattform, planera certifikatstrukturen så att ni antingen slår ihop flera värdnamn i samma certifikat via SAN-fältet (Subject Alternative Name) eller sprider ut utfärdandet över tid, i stället för att begära hundratals enskilda certifikat samma dag.

Checklista: har du täckt allt innan du går live

Innan ni pekar produktionstrafik mot den nya HTTPS-konfigurationen, gå igenom listan nedan en gång till. Den täcker de punkter där vi sett flest driftstopp hos svenska team som automatiserar Let’s Encrypt för första gången.

DNS-posten pekar mot rätt IP och är verifierad med dig från en extern plats, inte bara lokalt.
Port 80 och 443 är öppna både i serverns brandvägg och i molnleverantörens säkerhetsgrupp.
certbot renew --dry-run har körts och lyckats utan fel.
Deploy-hooken laddar faktiskt om webbservern, inte bara skriver nya filer till disk.
Ett larmskript eller motsvarande övervakning mejlar eller loggar om ett certifikat har färre än 14 dagar kvar.
Filrättigheterna på privata nycklar och API-tokens är begränsade till 600 eller striktare.
Domänen har testats mot SSL Labs och får minst betyg A.
Ni vet om er organisation omfattas av rapporteringskrav enligt NIS2 om ett certifikatrelaterat avbrott skulle inträffa.

Har ni redan hårdnat API-lagret enligt OWASP Top 10:2025-guiden eller satt upp rutiner enligt vår CISA KEV-patchhantering, passar certifikatautomationen naturligt in som ytterligare ett lager i samma driftdisciplin: minska antalet manuella steg som en människa kan glömma bort, och låt system larma innan något faktiskt går sönder. Fler grundläggande resurser om nätsäkerhet, lösenord och kryptering hittar du på vår säkerhetsöversikt.

Vanliga frågor

Är Let’s Encrypt verkligen säkert nog för produktion, eller bara för testmiljöer?
Ja. Let’s Encrypt är en fullvärdig, webbläsarbetrodd certifikatutfärdare som används av över 700 miljoner webbplatser globalt, inklusive stora produktionsmiljöer. Certifikaten har samma kryptografiska styrka som betalda alternativ; skillnaden ligger i valideringsnivå (DV, domänvalidering) snarare än säkerhet.

Kan jag använda Let’s Encrypt för interna servrar utan publik DNS?
Endast om servern går att nå för DNS-01-validering via en publik DNS-zon. Rent interna nätverk utan någon publik DNS-koppling kan inte få certifikat från Let’s Encrypt och behöver i stället en privat certifikatutfärdare.

Vad händer om Certbot-förnyelsen misslyckas och certifikatet går ut?
Besökare möter en varningssida i webbläsaren och de flesta API-klienter vägrar ansluta. Därför är övervakningsskriptet i steg 11 lika viktigt som själva automationen; ett larm 14 dagar i förväg ger tid att felsöka innan certifikatet faktiskt går ut.

Behöver jag betala något för Let’s Encrypt-certifikat?
Nej, certifikaten är helt gratis och finansieras av ISRG genom sponsorer. Det enda ni betalar för är er egen infrastruktur, DNS-hosting och eventuell driftstid för att sköta automationen.

Fungerar Certbot med Kubernetes eller containermiljöer?
Certbot i sig är byggt för traditionella servrar. I Kubernetes använder de flesta i stället cert-manager, som pratar direkt med ACME-protokollet och hanterar certifikat som Kubernetes-resurser, men grundprinciperna för validering (HTTP-01/DNS-01) är desamma som i den här guiden.

Vad är skillnaden mellan ett wildcardcertifikat och flera enskilda certifikat?
Ett wildcardcertifikat (*.exempel.se) täcker alla subdomäner med ett enda certifikat men kräver DNS-01-validering. Flera enskilda certifikat ger mer detaljerad kontroll och kan hanteras helt separat, men kräver fler valideringar och fler filer att hålla reda på.

Hur påverkar de kortare certifikatlivslängderna 2027–2029 min befintliga automation?
Om er nuvarande setup redan förnyar automatiskt via cron eller systemd-timer utan mänsklig inblandning påverkas ni knappast alls; timern kör oftare men logiken är identisk. Problem uppstår bara för organisationer som fortfarande hanterar förnyelse manuellt.

Kan jag migrera från ett kommersiellt certifikat till Let’s Encrypt utan driftstopp?
Ja. Installera Certbot, hämta det nya certifikatet parallellt med det gamla, testa med nginx -t, och byt sedan aktivt certifikat med en enda omladdning. Hela bytet tar normalt under en minut av faktisk konfigurationsändring.

Let’s Encrypt & Certbot: HTTPS i 14 Steg, 60 Min [2026]