Gratis SSL-certifikat: 12 trin med Certbot [2026]

Et SSL certifikat er ikke længere noget, du sætter op én gang og glemmer. I 2026 er TLS blevet en automatiseret, kortlivet og uafladelig del af enhver server. Let’s Encrypt udsteder nu certifikater med blot 90 dages standardgyldighed, og siden 15. januar 2026 kan du vælge kortlivede certifikater på kun 160 timer (lidt over seks dage). Samtidig har CA/Browser Forum besluttet at skære den maksimale levetid for et SSL certifikat helt ned til 47 dage frem mod 2029. Manuel håndtering er død. Automatisering er det eneste, der virker.

Denne vejledning tager dig gennem 12 konkrete trin, hvor du udsteder, installerer, hærder og automatisk fornyer et gratis TLS-certifikat med Let’s Encrypt og Certbot 5.6.0 på Nginx. Du får fungerende kode, output-eksempler, otte fejlfindingspunkter og et komplet projekt med Docker. Når du er færdig, har din server et grønt hængelås-ikon, en A-karakter på SSL Labs og en fornyelse, der kører helt af sig selv. Sæt cirka 30 minutter af.

Derfor skal du automatisere dit TLS-certifikat i 2026

Reglerne for et SSL certifikat ændrer sig hurtigere end nogensinde. Den 11. april 2025 godkendte CA/Browser Forum afstemningen SC-081v3, som trinvist barberer den maksimale levetid for et offentligt betroet TLS-certifikat ned. Indtil videre har de fleste certifikater haft op til 398 dages levetid. Det stopper nu. Fra 15. marts 2026 falder loftet til 200 dage, fra 15. marts 2027 til 100 dage, og fra 15. marts 2029 til blot 47 dage. Samtidig forkortes perioden, hvor en domænevalidering kan genbruges, tilsvarende.

For Let’s Encrypt er det ikke noget problem, for de har altid presset på for korte levetider og automatisering. Et standardcertifikat fra Let’s Encrypt varer 90 dage, og Certbot fornyer det automatisk, når der er 30 dage tilbage. I 2026 gik Let’s Encrypt endnu videre med kortlivede certifikater på 160 timer, generelt tilgængelige fra 15. januar 2026. De er designet til miljøer, hvor revokering er upraktisk, fordi et kompromitteret certifikat alligevel udløber inden for en uge.

Konsekvensen er klar. Hvis du fornyer dit SSL certifikat i hånden, vil du før eller siden glemme det, og din side går ned med en advarsel, der skræmmer hver eneste besøgende væk. Den eneste holdbare strategi er fuld automatisering med ACME-protokollen, som er standardiseret i RFC 8555. Resten af denne vejledning bygger netop sådan en opsætning, hvor dit certifikat fornyer sig selv, uanset om grænsen er 90 dage eller 47.

Dato	Maksimal certifikatlevetid	Genbrug af domænevalidering
I dag (2026)	200 dage (Let’s Encrypt: 90 dage)	200 dage
15. marts 2026	200 dage	200 dage
15. marts 2027	100 dage	100 dage
15. marts 2029	47 dage	10 dage

Kilde: CA/Browser Forum afstemning SC-081v3, godkendt 11. april 2025.

Forudsætninger: versioner og adgang

Før du udsteder dit første TLS-certifikat, skal nogle ting være på plads. Vejledningen er testet på Ubuntu 24.04 LTS, men kommandoerne virker stort set ens på Debian 12 og nyere. Det vigtigste krav er, at port 80 er åben udadtil, for Let’s Encrypt skal kunne nå din server for at validere, at du faktisk kontrollerer domænet.

Komponent	Anbefalet version	Kontrolkommando
Operativsystem	Ubuntu 24.04 LTS / Debian 12	lsb_release -a
Nginx	1.24 eller nyere	nginx -v
Certbot	5.6.0 (maj 2026)	certbot –version
snapd	2.61 eller nyere	snap version
OpenSSL	3.0 eller nyere	openssl version

Versioner verificeret mod Certbot 5.6.0, udgivet på PyPI 11. maj 2026.

Du skal desuden have: et registreret domæne, du kontrollerer (eksemplet bruger eksempel.dk), root- eller sudo-adgang til serveren, en offentlig IP-adresse, og en e-mailadresse til udløbsvarsler. Hvis du vil udstede et wildcard-certifikat senere i trin 9, skal du også have API-adgang til din DNS-udbyder. Har du styr på grundbegreberne bag hængelåsen, kan du genopfriske dem i vores artikel om HTTPS og TLS forklaret, inden du går videre.

Sådan fungerer ACME, Let’s Encrypt og Certbot

Hele systemet hviler på ACME, Automatic Certificate Management Environment, standardiseret i RFC 8555. ACME lader en klient (Certbot) bevise over for en certifikatmyndighed (Let’s Encrypt), at du kontrollerer et domæne, uden at et menneske skal læse en e-mail og klikke på et link. Beviset leveres gennem en challenge, og der findes tre typer. Valget af challenge afgør, om du kan udstede et almindeligt eller et wildcard SSL certifikat.

Challenge-type	Sådan valideres	Wildcard?	Bedst til
HTTP-01	Certbot lægger en fil under /.well-known/acme-challenge/ på port 80	Nej	Almindelige enkeltdomæner
DNS-01	Certbot opretter en TXT-post i din DNS-zone	Ja	Wildcard og servere uden port 80
TLS-ALPN-01	Validering sker over port 443 med en særlig ALPN-udvidelse	Nej	Reverse proxies og load balancers

De tre ACME-challenges defineret i RFC 8555.

For de fleste websteder er HTTP-01 det rette valg, og det bruger vi i trin 5. Det kræver kun, at port 80 er åben. Vil du have et wildcard-certifikat, der dækker *.eksempel.dk, er du tvunget til at bruge DNS-01, fordi Let’s Encrypt nægter at udstede wildcards via HTTP-01. Husk her en vigtig detalje fra Let’s Encrypt selv: et wildcard for *.eksempel.dk dækker ikke det nøgne eksempel.dk, og det dækker kun ét niveau, så hej.farvel.eksempel.dk falder udenfor.

Trin 1: Peg dit domæne mod serveren med DNS

Et SSL certifikat kan kun udstedes, hvis domænet faktisk peger på din server. Opret en A-post (og en AAAA-post, hvis du bruger IPv6) hos din DNS-udbyder, der peger eksempel.dk og www.eksempel.dk mod serverens offentlige IP. DNS kan tage op til 24 timer om at sprede sig, men typisk sker det inden for få minutter. Verificér resultatet, før du går videre, ellers fejler HTTP-01-valideringen senere.

# Kontrollér at domænet peger på den rigtige IP
dig +short A eksempel.dk
dig +short A www.eksempel.dk

# Forventet output (din servers offentlige IP):
# 203.0.113.42
# 203.0.113.42

Hvis dig returnerer en tom linje eller en forkert IP, så ret DNS-posten og vent, til den er opdateret. Du kan tjekke spredningen globalt med dig @8.8.8.8 eksempel.dk, som spørger Googles offentlige resolver direkte. Først når begge navne peger korrekt, fortsætter du.

Trin 2: Installer og konfigurer Nginx

Certbot skal kunne læse din Nginx-konfiguration for automatisk at indsætte TLS-direktiverne. Installér Nginx, og opret et minimalt server-blok for dit domæne på port 80. Dette blok bruges både til selve siden og til at servere ACME-challenge-filen.

# Installér Nginx
sudo apt update
sudo apt install -y nginx

# Opret server-blok
sudo nano /etc/nginx/sites-available/eksempel.dk

Indsæt følgende konfiguration. Læg mærke til root-stien, for det er her, Certbot lægger sin challenge-fil under HTTP-01.

server {
    listen 80;
    listen [::]:80;
    server_name eksempel.dk www.eksempel.dk;

    root /var/www/eksempel.dk;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

# Aktivér sitet og genindlæs
sudo mkdir -p /var/www/eksempel.dk
echo "Hej fra eksempel.dk" | sudo tee /var/www/eksempel.dk/index.html
sudo ln -s /etc/nginx/sites-available/eksempel.dk /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Kommandoen nginx -t tester konfigurationen, før du genindlæser. Får du syntax is ok og test is successful, er du klar. Besøg http://eksempel.dk i en browser og bekræft, at du ser hilsenen, før du fortsætter til certifikatet.

Trin 3: Åbn port 80 og 443 i firewallen

Den hyppigste årsag til at en HTTP-01-validering fejler er en lukket port 80. Let’s Encrypt-serverne skal kunne nå din server udefra. Åbn både port 80 (HTTP, til validering) og port 443 (HTTPS, til det færdige TLS-certifikat) i din firewall.

# Med UFW (Ubuntu standard)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw reload
sudo ufw status

# Forventet output:
# 80/tcp                     ALLOW       Anywhere
# 443/tcp                    ALLOW       Anywhere

Husk også eventuelle firewalls i skyen. Bruger du AWS, Azure, Hetzner eller DigitalOcean, har du sandsynligvis en sikkerhedsgruppe eller cloud-firewall, der skal åbnes separat. En lokal UFW-regel hjælper ikke, hvis udbyderens firewall stadig blokerer port 80 udefra.

Trin 4: Installer Certbot via snap

Den officielt anbefalede installationsmetode til Certbot er snap. Apt-pakken halter ofte flere versioner bagud, og da reglerne for et SSL certifikat ændrer sig hurtigt i 2026, vil du have den nyeste klient. Snap-pakken opdaterer sig selv og giver dig Certbot 5.6.0.

# Fjern en eventuel gammel apt-version
sudo apt remove -y certbot

# Installér snapd og Certbot
sudo apt install -y snapd
sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot

# Gør certbot-kommandoen tilgængelig
sudo ln -s /snap/bin/certbot /usr/bin/certbot

# Bekræft versionen
certbot --version
# Forventet: certbot 5.6.0

Får du en ældre version, så kør sudo snap refresh certbot. Foretrækker du containere, findes Certbot også som OCI-image og kan installeres med pip, men snap er det mest gnidningsfrie valg på en almindelig server. Den fulde liste over metoder findes i Certbots officielle installationsdokumentation.

Trin 5: Udsted dit første certifikat med HTTP-01

Nu kommer det centrale øjeblik. Certbots Nginx-plugin udsteder dit TLS-certifikat, redigerer din Nginx-konfiguration automatisk og opsætter en omdirigering fra HTTP til HTTPS. Kør kommandoen med begge domænenavne.

sudo certbot --nginx \
  -d eksempel.dk -d www.eksempel.dk \
  --email [email protected] \
  --agree-tos \
  --no-eff-email \
  --redirect

Certbot gennemfører HTTP-01-challenge, henter certifikatet og skriver det til disk. Et vellykket forløb ser sådan ud:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/eksempel.dk/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/eksempel.dk/privkey.pem
This certificate expires on 2026-09-09.
These files will be updated when the certificate renews.
Deploying certificate
Successfully deployed certificate for eksempel.dk to /etc/nginx/sites-enabled/eksempel.dk
Congratulations! You have successfully enabled HTTPS on https://eksempel.dk and https://www.eksempel.dk

Bemærk udløbsdatoen 90 dage frem. Besøg nu https://eksempel.dk, og du ser hængelåsen. Certbot har samtidig tilføjet en 301-omdirigering, så al HTTP-trafik automatisk sendes videre til HTTPS. Dit gratis SSL certifikat er live.

Trin 6: Verificer TLS-konfigurationen med OpenSSL

Stol ikke blindt på hængelåsen. Verificér certifikatkæden, udløbsdatoen og den forhandlede protokol direkte fra kommandolinjen med OpenSSL. Det afslører problemer, en browser skjuler, for eksempel en manglende mellemcertifikat-kæde.

# Vis certifikatets udsteder, emne og gyldighed
echo | openssl s_client -connect eksempel.dk:443 -servername eksempel.dk 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

# Forventet output:
# issuer=C=US, O=Let's Encrypt, CN=R13
# subject=CN=eksempel.dk
# notBefore=Jun 11 09:00:00 2026 GMT
# notAfter=Sep  9 08:59:59 2026 GMT

For at bekræfte, at TLS 1.3 (RFC 8446) faktisk bruges, kan du tvinge protokollen. Et vellykket håndtryk bekræfter, at serveren forhandler den nyeste version af TLS.

echo | openssl s_client -connect eksempel.dk:443 -tls1_3 2>/dev/null \
  | grep -E "Protocol|Cipher"
# Forventet:
# Protocol  : TLSv1.3
# Cipher    : TLS_AES_256_GCM_SHA384

Vil du have en fuld karakter, så kør domænet gennem SSL Labs’ testværktøj. Efter trin 7 bør du ramme karakteren A eller A+. Et SSL certifikat alene giver ikke topkarakter; det afhænger af protokoller og cipher-konfiguration.

Trin 7: Hærd din Nginx SSL-konfiguration

Standardkonfigurationen fra Certbot er sikker, men du kan gøre den bedre. Slå gamle protokoller fra, aktivér kun stærke ciphers og tilføj HSTS, så browsere altid bruger HTTPS. Følgende blok afspejler Mozillas “Intermediate”-profil og giver topkarakter på de fleste testværktøjer.

# Redigér serverblokken, Certbot oprettede på port 443
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name eksempel.dk www.eksempel.dk;

    ssl_certificate     /etc/letsencrypt/live/eksempel.dk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/eksempel.dk/privkey.pem;

    # Kun moderne protokoller
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;

    # Session-cache for ydelse
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;
    ssl_session_tickets off;

    # HSTS, tving HTTPS i 2 aar
    add_header Strict-Transport-Security "max-age=63072000" always;

    root /var/www/eksempel.dk;
    index index.html;
}

Test og genindlæs altid efter ændringer med sudo nginx -t && sudo systemctl reload nginx. En vigtig detalje for 2026: Let’s Encrypt er begyndt at udfase OCSP til fordel for CRL’er, så fjern ssl_stapling on; fra ældre konfigurationer, da OCSP-stapling ikke længere giver mening. Du kan generere en skræddersyet konfiguration til netop din software i Mozillas SSL Configuration Generator.

Trin 8: Aktivér automatisk fornyelse

Dette er det vigtigste trin i hele vejledningen. Med 90-dages-certifikater i dag og 47-dages-certifikater på vej er manuel fornyelse umulig i praksis. Snap-installationen af Certbot opretter automatisk en systemd-timer, der fornyer dit TLS-certifikat to gange dagligt og kun udsteder nyt, når der er under 30 dage tilbage.

# Kontrollér at fornyelsestimeren er aktiv
sudo systemctl list-timers | grep certbot

# Forventet output:
# snap.certbot.renew.timer  ...  snap.certbot.renew.service

# Se selve timerens status
systemctl status snap.certbot.renew.timer

Hvis du af en eller anden grund ikke har timeren (for eksempel ved en pip-installation), kan du oprette en cron-opgave i stedet. Den følgende linje kører fornyelseskontrollen hver dag klokken 03:30 og genindlæser Nginx, hvis et nyt certifikat blev hentet.

# Redigér root's crontab
sudo crontab -e

# Tilfoej denne linje:
30 3 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

Argumentet --deploy-hook kører kun, når et certifikat faktisk blev fornyet, hvilket sparer unødvendige genindlæsninger. Det er bedre end den gamle --post-hook, der kørte hver gang.

Trin 9: Udsted et wildcard-certifikat med DNS-01

Har du mange underdomæner, vil du have et wildcard SSL certifikat, der dækker *.eksempel.dk i ét. Det kræver DNS-01-challenge, fordi Let’s Encrypt ikke udsteder wildcards via HTTP-01. Du skal bruge en DNS-plugin til din udbyder. Eksemplet bruger Cloudflare.

# Installér Cloudflare-pluginet
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

# Gem din API-token sikkert
sudo mkdir -p /root/.secrets
echo "dns_cloudflare_api_token = DIN_TOKEN_HER" | sudo tee /root/.secrets/cloudflare.ini
sudo chmod 600 /root/.secrets/cloudflare.ini

# Udsted wildcard-certifikatet
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d eksempel.dk -d "*.eksempel.dk" \
  --email [email protected] --agree-tos --no-eff-email

Husk at inkludere både eksempel.dk og *.eksempel.dk, fordi wildcard-delen ikke dækker det nøgne domæne. Rettighederne på cloudflare.ini skal være 600, så kun root kan læse din API-token. En lækket token giver en angriber kontrol over hele din DNS-zone.

Trin 10: Skift til ECDSA-nøgler for hurtigere håndtryk

Som standard udsteder Let’s Encrypt et RSA 2048-bit SSL certifikat, men ECDSA-nøgler giver mindre certifikater og hurtigere TLS-håndtryk med samme sikkerhed. En ECDSA P-256-nøgle svarer kryptografisk til en RSA 3072-bit-nøgle, men er en brøkdel af størrelsen. Vil du forstå matematikken bag, har vi en grundig gennemgang i artiklen om digitale signaturer forklaret.

# Udsted et nyt ECDSA-certifikat
sudo certbot certonly --nginx \
  -d eksempel.dk -d www.eksempel.dk \
  --key-type ecdsa \
  --elliptic-curve secp256r1 \
  --cert-name eksempel.dk-ecdsa

# Bekraeft noegletypen
sudo certbot certificates | grep -A1 eksempel.dk-ecdsa

For maksimal kompatibilitet kan du køre dobbelt udstedelse med både RSA og ECDSA, så ældre klienter får RSA, mens moderne browsere får det hurtigere ECDSA-certifikat. De fleste servere har dog ikke brug for det i 2026, da praktisk talt alle klienter understøtter ECDSA.

Trin 11: Test fornyelse og overvåg udløb

Stol aldrig på, at automatisk fornyelse virker, før du har testet den. Certbot har en tør-kørsel, der gennemfører hele fornyelsesforløbet mod Let’s Encrypts testmiljø uden at bruge af din kvote. Det er din forsikring mod en pinlig nedetid om 60 dage.

# Simulér en fornyelse uden at udstede et rigtigt certifikat
sudo certbot renew --dry-run

# Forventet output afsluttes med:
# Congratulations, all simulated renewals succeeded:
#   /etc/letsencrypt/live/eksempel.dk/fullchain.pem (success)

Ud over tør-kørslen bør du opsætte ekstern overvågning, så du får besked, hvis et certifikat alligevel nærmer sig udløb. En simpel cron-baseret kontrol med OpenSSL kan sende dig en advarsel, hvis der er under 14 dage tilbage.

# Skript der advarer hvis certifikatet udloeber inden for 14 dage
expiry=$(echo | openssl s_client -connect eksempel.dk:443 -servername eksempel.dk 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
expiry_epoch=$(date -d "$expiry" +%s)
now_epoch=$(date +%s)
days_left=$(( (expiry_epoch - now_epoch) / 86400 ))
echo "Dage tilbage: $days_left"
if [ "$days_left" -lt 14 ]; then
  echo "ADVARSEL: certifikatet udloeber snart!" | mail -s "TLS-advarsel" [email protected]
fi

Trin 12: Forbered dig på 47-dages og kortlivede certifikater

Det sidste trin handler om fremtiden. Med CA/Browser Forums plan om 47-dages-certifikater fra 2029 og Let’s Encrypts kortlivede certifikater på 160 timer (generelt tilgængelige siden 15. januar 2026) bliver fornyelseshyppigheden langt højere. En opsætning, der fornyer hver 60. dag, holder ikke, når certifikatet kun lever i seks dage. Heldigvis kræver det ingen ny kode, kun en justering af tankegangen.

For at opte ind på kortlivede certifikater i fremtiden tilknytter du en særlig ACME-profil. Certbots fornyelseslogik håndterer resten, fordi timeren allerede kører to gange dagligt og vil hente et nyt certifikat, så snart der er under en tredjedel af levetiden tilbage. Det vigtigste råd er derfor: lad være med at hardkode 90 dage nogen steder. Stol på Certbots egen logik, der tilpasser sig den faktiske udløbsdato.

# Tjek hvilke ACME-profiler din konto understoetter
sudo certbot certificates

# Naar kortlivede profiler er tilgaengelige paa din konto,
# kan du udstede med en profil-parameter (eksempel):
# sudo certbot certonly --nginx -d eksempel.dk \
#   --preferred-profile shortlived

Kortlivede certifikater reducerer risikoen ved et kompromitteret SSL certifikat dramatisk, fordi et stjålet certifikat alligevel udløber inden for en uge, uden at nogen behøver at revokere det. Det er en af grundene til, at hele branchen bevæger sig væk fra lange levetider. Du kan læse mere om de officielle grænser i Let’s Encrypts dokumentation om rate limits.

Komplet, fungerende projekt med Docker Compose

Vil du have hele opsætningen i én genskabelig pakke, er her et komplet projekt med Docker Compose. Det kører Nginx og Certbot i hver sin container, deler certifikat-volumen mellem dem og fornyer automatisk hvert 12. time. Det er ideelt til en ny server, hvor du vil have TLS op at køre på få minutter.

# docker-compose.yml
services:
  nginx:
    image: nginx:1.27
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./certbot/conf:/etc/letsencrypt
      - ./certbot/www:/var/www/certbot
    restart: unless-stopped

  certbot:
    image: certbot/certbot:latest
    volumes:
      - ./certbot/conf:/etc/letsencrypt
      - ./certbot/www:/var/www/certbot
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew --webroot -w /var/www/certbot; sleep 12h; done'"
    restart: unless-stopped

Den tilhørende Nginx-konfiguration serverer ACME-challenge fra webroot, så Certbot kan validere via HTTP-01 uden at røre Nginx-konfigurationen.

# nginx.conf
server {
    listen 80;
    server_name eksempel.dk;
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }
    location / {
        return 301 https://$host$request_uri;
    }
}
server {
    listen 443 ssl;
    server_name eksempel.dk;
    ssl_certificate     /etc/letsencrypt/live/eksempel.dk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/eksempel.dk/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    location / {
        root /usr/share/nginx/html;
    }
}

Første gang udsteder du certifikatet med en engangskommando: docker compose run --rm certbot certonly --webroot -w /var/www/certbot -d eksempel.dk --email [email protected] --agree-tos --no-eff-email. Derefter kører fornyelsen automatisk. Hele projektet ligger i tre filer og kan versioneres i Git.

8 almindelige faldgruber, du skal undgå

Selv en simpel SSL certifikat-opsætning kan gå galt på overraskende måder. Her er de otte hyppigste faldgruber og hvordan du undgår dem.

Lukket port 80. Den absolut hyppigste fejl. HTTP-01 kræver, at Let’s Encrypt kan nå port 80 udefra. Tjek både lokal firewall og cloud-firewall.
DNS peger forkert. Hvis A-posten ikke peger på serveren, fejler valideringen straks. Verificér altid med dig først.
Du rammer rate-limittet. Let’s Encrypt tillader 50 certifikater pr. registreret domæne pr. uge. Brug --dry-run under test, så du ikke spilder kvoten.
Wildcard via HTTP-01. Det virker aldrig. Wildcard kræver DNS-01, punktum.
Glemt fornyelse. Hvis du installerede via pip uden timer, fornyer intet sig selv. Bekræft altid med certbot renew --dry-run.
Forkerte filrettigheder på privatnøglen. privkey.pem skal kun kunne læses af root. Kopiér aldrig nøglen til et offentligt sted.
OCSP-stapling i konfigurationen. Da Let’s Encrypt udfaser OCSP i 2025, giver ssl_stapling on; nu fejl i loggen. Fjern direktivet.
Manglende mellemcertifikat. Brug altid fullchain.pem, ikke cert.pem, ellers mangler kæden, og nogle klienter afviser dit certifikat.

Fejlfinding: 8 konkrete fejlmeddelelser

Når noget går galt, returnerer Certbot en ret præcis fejl. Denne tabel oversætter de otte hyppigste meddelelser til årsag og løsning, så du hurtigt kommer videre med dit TLS-certifikat.

Fejlmeddelelse	Årsag	Løsning
Timeout during connect (HTTP-01)	Port 80 er lukket eller blokeret	Åbn port 80 i lokal og cloud-firewall
DNS problem: NXDOMAIN	Domænet har ingen A-post	Opret A-post og vent på DNS-spredning
too many certificates already issued	Rate-limit på 50 pr. uge ramt	Vent en uge eller brug –dry-run til test
Challenge failed for domain	Forkert webroot-sti til challenge-fil	Ret root-stien i Nginx-blokken
The nginx plugin is not working	Nginx-konfigurationen har syntaksfejl	Kør nginx -t og ret fejlen
could not bind to IPv4 or IPv6	Port 443 er optaget af en anden proces	Stop processen eller skift port
Account already exists	ACME-konto findes allerede	Ufarligt, Certbot bruger den eksisterende konto
certificate has expired	Automatisk fornyelse fejlede	Kør certbot renew og tjek timeren

De otte hyppigste Certbot-fejl og deres løsning.

Hvis du sidder fast, så læs Certbot-loggen i /var/log/letsencrypt/letsencrypt.log. Den indeholder den fulde fejl med flere detaljer end terminaloutputtet. Næsten alle problemer med et SSL certifikat handler om netværk, DNS eller filrettigheder.

Avancerede tips til produktion

Når grundopsætningen kører, er der flere måder at gøre dit TLS-setup endnu mere robust. Disse tips adskiller en hobbyserver fra en produktionsserver.

Brug DNS-01 selv for enkeltdomæner. Det fjerner afhængigheden af port 80 og virker bag load balancers, hvor HTTP-01 er besværlig.
Aktivér CAA-poster. En CAA-DNS-post, der kun tillader letsencrypt.org, forhindrer andre certifikatmyndigheder i at udstede for dit domæne.
Centralisér certifikater. I et cluster kan du udstede ét sted og distribuere via en hemmeligheds-manager frem for at køre Certbot på hver node.
Overvåg Certificate Transparency. Værktøjer som crt.sh viser hvert certifikat udstedt for dit domæne, så du opdager uautoriseret udstedelse.
Test mod staging først. Brug --test-cert mod Let’s Encrypts testmiljø, når du bygger nye automatiseringer, så du aldrig rammer rate-limittet.

Husk også, at et SSL certifikat kun beskytter transporten. Det krypterer trafikken mellem browser og server, men det beskytter ikke data i hvile på serveren. Til det skal du bruge kryptering på applikationsniveau, som vi gennemgår i vores guide til AES-256-kryptering i Node.js. Og når kvantecomputere modnes, ændrer billedet sig igen, hvilket vi dækker i artiklen om post-kvantekryptografi.

DV, OV og EV: hvilken type certifikat skal du vælge?

Ikke alle certifikater er ens. Der findes tre valideringsniveauer, og forskellen mellem dem er, hvor grundigt certifikatmyndigheden kontrollerer dig, før den udsteder dit TLS-certifikat. Det er vigtigt at forstå, fordi mange betaler for et niveau, de slet ikke har brug for.

Domain Validation (DV). Certifikatmyndigheden bekræfter kun, at du kontrollerer domænet. Det er præcis det, Let’s Encrypt udsteder, og det sker automatisk på sekunder. For et website, en API eller en webshop er DV alt, hvad du behøver. Browseren viser nøjagtig den samme hængelås som et dyrere certifikat.
Organization Validation (OV). Her kontrollerer myndigheden også, at organisationen bag domænet faktisk eksisterer. Det kræver manuel sagsbehandling, koster typisk penge og tager dage. Det giver ikke ekstra kryptografisk sikkerhed, kun en juridisk verificeret ejer i certifikatet.
Extended Validation (EV). Den grundigste, dyreste og langsomste form. Tidligere viste browsere et grønt firmanavn i adresselinjen ved EV, men den visuelle forskel er stort set fjernet i moderne browsere siden 2019. I praksis ser brugeren ingen forskel på et EV- og et DV-certifikat.

Konklusionen for de fleste i 2026 er enkel: vælg DV via Let’s Encrypt. Krypteringen er identisk, hængelåsen er identisk, og prisen er nul. Kun virksomheder med specifikke compliance-krav, for eksempel inden for finans, har et reelt behov for OV eller EV. For alt andet er et gratis DV-certifikat det rigtige valg, og det er netop det, denne vejledning bygger.

Certbot, acme.sh eller Caddy: hvilket værktøj passer dig?

Certbot er den officielle ACME-klient fra EFF, men det er ikke det eneste valg. Tre værktøjer dominerer feltet i 2026, og det rette afhænger af din opsætning. Alle tre taler med Let’s Encrypt via ACME-protokollen og giver det samme betroede TLS-certifikat.

Værktøj	Sprog	Bedst til	Automatisk fornyelse
Certbot	Python	Nginx og Apache på Linux-servere	systemd-timer
acme.sh	Ren shell	Minimale systemer uden Python	cron
Caddy	Go	Ny opsætning, indbygget webserver	Fuldt automatisk, indbygget
lego	Go	Egne automatiseringer og CI/CD	Manuel eller scriptet

Fire udbredte ACME-klienter og deres styrker.

Certbot er det sikreste valg, hvis du allerede kører Nginx eller Apache, fordi pluginnene redigerer konfigurationen for dig. Foretrækker du noget endnu lettere, er acme.sh skrevet i ren shell og kræver hverken Python eller snap. Bygger du en helt ny server fra bunden, er Caddy interessant, fordi webserveren selv henter og fornyer certifikatet uden et eneste ekstra værktøj. For pipelines og containere bruger mange lego, der er let at kalde fra et script. Uanset valget gælder den samme grundregel fra trin 8: fornyelsen skal være fuldautomatisk, ellers er det kun et spørgsmål om tid, før dit certifikat udløber.

Ofte stillede spørgsmål om SSL- og TLS-certifikater

Er et Let’s Encrypt SSL certifikat virkelig gratis?

Ja, helt gratis og uden skjulte gebyrer. Let’s Encrypt er en non-profit certifikatmyndighed drevet af Internet Security Research Group. Et TLS-certifikat herfra er teknisk fuldt ud lige så betroet som et betalt certifikat fra en kommerciel udsteder. Forskellen er, at Let’s Encrypt ikke tilbyder udvidet validering eller garantier, kun domænevalidering, hvilket er rigeligt for langt de fleste websteder.

Hvor ofte skal jeg forny mit certifikat?

Et standardcertifikat fra Let’s Encrypt udløber efter 90 dage, og Certbot fornyer det automatisk, når der er 30 dage tilbage. Du behøver derfor i praksis aldrig at gøre noget manuelt, så længe den automatiske timer kører. Med CA/Browser Forums plan om at sænke loftet til 47 dage frem mod 2029 bliver hyppigheden højere, men Certbots logik tilpasser sig den faktiske udløbsdato automatisk.

Hvad er forskellen på SSL og TLS?

SSL (Secure Sockets Layer) er den oprindelige protokol, som i dag er forældet og usikker. TLS (Transport Layer Security) er efterfølgeren, og den nyeste version er TLS 1.3, defineret i RFC 8446. Når folk siger “SSL certifikat”, mener de næsten altid et TLS-certifikat. Begreberne bruges i flæng, men teknisk er det TLS, der beskytter din forbindelse i dag.

Kan jeg bruge ét certifikat til flere domæner?

Ja. Du kan tilføje op til 100 domænenavne til ét certifikat med gentagne -d-argumenter, kaldet et SAN-certifikat. Alternativt dækker et wildcard-certifikat alle underdomæner på ét niveau med *.eksempel.dk. Husk dog, at et wildcard ikke dækker det nøgne domæne, så du skal tilføje eksempel.dk separat.

Hvad sker der, hvis mit certifikat udløber?

Browsere viser en fuldskærmsadvarsel om, at forbindelsen ikke er sikker, og de fleste besøgende forlader siden med det samme. Søgemaskiner kan også nedrangere siden. Derfor er den automatiske fornyelse i trin 8 så afgørende. Et udløbet SSL certifikat er en af de mest almindelige og mest undgåelige årsager til nedetid.

Hvad er Let’s Encrypts rate-limit?

Let’s Encrypt tillader 50 certifikater pr. registreret domæne pr. uge. For de fleste er det rigeligt, men hvis du automatiserer udstedelse på tværs af mange underdomæner, kan du ramme grænsen. Brug derfor altid --dry-run eller --test-cert under udvikling, så testkørsler ikke tæller med i din kvote.

Bør jeg vælge ECDSA eller RSA?

Vælg ECDSA, medmindre du har meget gamle klienter at understøtte. En ECDSA P-256-nøgle giver samme sikkerhed som en RSA 3072-bit-nøgle, men med mindre certifikater og hurtigere TLS-håndtryk. I 2026 understøtter praktisk talt alle browsere og operativsystemer ECDSA, så der er sjældent grund til at blive på RSA.

Hjælper en grøn hængelås mod hacking?

Hængelåsen betyder kun, at forbindelsen er krypteret, ikke at siden er sikker eller troværdig. Også phishing-sider har gyldige TLS-certifikater. Et certifikat beskytter mod aflytning undervejs, men ikke mod sårbarheder i din applikation eller mod ondsindede afsendere. Læs mere om, hvad hængelåsen faktisk garanterer, i vores artikel om HTTPS og TLS.

Relateret indhold

Du har nu et komplet, automatiseret og hærdet SSL certifikat på din server. Det fornyer sig selv, scorer topkarakter på SSL Labs og er forberedt på de kortere certifikatlevetider, der kommer frem mod 2029. Det vigtigste, du tager med: automatisering er ikke valgfri længere. Et TLS-certifikat, der ikke fornyer sig selv, er en nedetid, der bare venter på at ske.

Gratis SSL/TLS-certifikat: 12 trin med Certbot [2026]