{"id":53,"date":"2026-06-11T16:38:51","date_gmt":"2026-06-11T16:38:51","guid":{"rendered":"https:\/\/shattered.io\/dk\/2026\/06\/11\/ssl-tls-certifikat-certbot-2026\/"},"modified":"2026-06-11T16:38:51","modified_gmt":"2026-06-11T16:38:51","slug":"ssl-tls-certifikat-certbot-2026","status":"publish","type":"post","link":"https:\/\/shattered.io\/dk\/2026\/06\/11\/ssl-tls-certifikat-certbot-2026\/","title":{"rendered":"Gratis SSL\/TLS-certifikat: 12 trin med Certbot [2026]"},"content":{"rendered":"\n

Et SSL certifikat<\/strong> er ikke l\u00e6ngere noget, du s\u00e6tter op \u00e9n gang og glemmer. I 2026 er TLS<\/strong> 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\u00e6lge kortlivede certifikater p\u00e5 kun 160 timer (lidt over seks dage). Samtidig har CA\/Browser Forum besluttet at sk\u00e6re den maksimale levetid for et SSL certifikat<\/strong> helt ned til 47 dage frem mod 2029. Manuel h\u00e5ndtering er d\u00f8d. Automatisering er det eneste, der virker.<\/p>\n\n\n\n

Denne vejledning tager dig gennem 12 konkrete trin, hvor du udsteder, installerer, h\u00e6rder og automatisk fornyer et gratis TLS<\/strong>-certifikat med Let’s Encrypt og Certbot 5.6.0 p\u00e5 Nginx. Du f\u00e5r fungerende kode, output-eksempler, otte fejlfindingspunkter og et komplet projekt med Docker. N\u00e5r du er f\u00e6rdig, har din server et gr\u00f8nt h\u00e6ngel\u00e5s-ikon, en A-karakter p\u00e5 SSL Labs og en fornyelse, der k\u00f8rer helt af sig selv. S\u00e6t cirka 30 minutter af.<\/p>\n\n\n\n

Derfor skal du automatisere dit TLS-certifikat i 2026<\/h2>\n\n\n\n

Reglerne for et SSL certifikat<\/strong> \u00e6ndrer 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<\/strong>-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\u00e6nevalidering kan genbruges, tilsvarende.<\/p>\n\n\n\n

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

Konsekvensen er klar. Hvis du fornyer dit SSL certifikat<\/strong> i h\u00e5nden, vil du f\u00f8r eller siden glemme det, og din side g\u00e5r ned med en advarsel, der skr\u00e6mmer hver eneste bes\u00f8gende v\u00e6k. Den eneste holdbare strategi er fuld automatisering med ACME-protokollen, som er standardiseret i RFC 8555. Resten af denne vejledning bygger netop s\u00e5dan en ops\u00e6tning, hvor dit certifikat fornyer sig selv, uanset om gr\u00e6nsen er 90 dage eller 47.<\/p>\n\n\n\n

Dato<\/th>Maksimal certifikatlevetid<\/th>Genbrug af dom\u00e6nevalidering<\/th><\/tr><\/thead>
I dag (2026)<\/td>200 dage (Let’s Encrypt: 90 dage)<\/td>200 dage<\/td><\/tr>
15. marts 2026<\/td>200 dage<\/td>200 dage<\/td><\/tr>
15. marts 2027<\/td>100 dage<\/td>100 dage<\/td><\/tr>
15. marts 2029<\/td>47 dage<\/td>10 dage<\/td><\/tr><\/tbody><\/table>
Kilde: CA\/Browser Forum afstemning SC-081v3, godkendt 11. april 2025.<\/figcaption><\/figure>\n\n\n\n

Foruds\u00e6tninger: versioner og adgang<\/h2>\n\n\n\n

F\u00f8r du udsteder dit f\u00f8rste TLS<\/strong>-certifikat, skal nogle ting v\u00e6re p\u00e5 plads. Vejledningen er testet p\u00e5 Ubuntu 24.04 LTS, men kommandoerne virker stort set ens p\u00e5 Debian 12 og nyere. Det vigtigste krav er, at port 80 er \u00e5ben udadtil, for Let’s Encrypt skal kunne n\u00e5 din server for at validere, at du faktisk kontrollerer dom\u00e6net.<\/p>\n\n\n\n

Komponent<\/th>Anbefalet version<\/th>Kontrolkommando<\/th><\/tr><\/thead>
Operativsystem<\/td>Ubuntu 24.04 LTS \/ Debian 12<\/td>lsb_release -a<\/td><\/tr>
Nginx<\/td>1.24 eller nyere<\/td>nginx -v<\/td><\/tr>
Certbot<\/td>5.6.0 (maj 2026)<\/td>certbot –version<\/td><\/tr>
snapd<\/td>2.61 eller nyere<\/td>snap version<\/td><\/tr>
OpenSSL<\/td>3.0 eller nyere<\/td>openssl version<\/td><\/tr><\/tbody><\/table>
Versioner verificeret mod Certbot 5.6.0, udgivet p\u00e5 PyPI 11. maj 2026.<\/figcaption><\/figure>\n\n\n\n

Du skal desuden have: et registreret dom\u00e6ne, du kontrollerer (eksemplet bruger eksempel.dk<\/code>), root- eller sudo-adgang til serveren, en offentlig IP-adresse, og en e-mailadresse til udl\u00f8bsvarsler. Hvis du vil udstede et wildcard-certifikat senere i trin 9, skal du ogs\u00e5 have API-adgang til din DNS-udbyder. Har du styr p\u00e5 grundbegreberne bag h\u00e6ngel\u00e5sen, kan du genopfriske dem i vores artikel om HTTPS og TLS forklaret<\/a>, inden du g\u00e5r videre.<\/p>\n\n\n\n

S\u00e5dan fungerer ACME, Let’s Encrypt og Certbot<\/h2>\n\n\n\n

Hele systemet hviler p\u00e5 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\u00e6ne, uden at et menneske skal l\u00e6se en e-mail og klikke p\u00e5 et link. Beviset leveres gennem en challenge<\/em>, og der findes tre typer. Valget af challenge afg\u00f8r, om du kan udstede et almindeligt eller et wildcard SSL certifikat<\/strong>.<\/p>\n\n\n\n

Challenge-type<\/th>S\u00e5dan valideres<\/th>Wildcard?<\/th>Bedst til<\/th><\/tr><\/thead>
HTTP-01<\/td>Certbot l\u00e6gger en fil under \/.well-known\/acme-challenge\/ p\u00e5 port 80<\/td>Nej<\/td>Almindelige enkeltdom\u00e6ner<\/td><\/tr>
DNS-01<\/td>Certbot opretter en TXT-post i din DNS-zone<\/td>Ja<\/td>Wildcard og servere uden port 80<\/td><\/tr>
TLS-ALPN-01<\/td>Validering sker over port 443 med en s\u00e6rlig ALPN-udvidelse<\/td>Nej<\/td>Reverse proxies og load balancers<\/td><\/tr><\/tbody><\/table>
De tre ACME-challenges defineret i RFC 8555.<\/figcaption><\/figure>\n\n\n\n

For de fleste websteder er HTTP-01 det rette valg, og det bruger vi i trin 5. Det kr\u00e6ver kun, at port 80 er \u00e5ben. Vil du have et wildcard-certifikat, der d\u00e6kker *.eksempel.dk<\/code>, er du tvunget til at bruge DNS-01, fordi Let’s Encrypt n\u00e6gter at udstede wildcards via HTTP-01. Husk her en vigtig detalje fra Let’s Encrypt selv: et wildcard for *.eksempel.dk<\/code> d\u00e6kker ikke<\/strong> det n\u00f8gne eksempel.dk<\/code>, og det d\u00e6kker kun \u00e9t niveau, s\u00e5 hej.farvel.eksempel.dk<\/code> falder udenfor.<\/p>\n\n\n\n

Trin 1: Peg dit dom\u00e6ne mod serveren med DNS<\/h2>\n\n\n\n

Et SSL certifikat<\/strong> kan kun udstedes, hvis dom\u00e6net faktisk peger p\u00e5 din server. Opret en A-post (og en AAAA-post, hvis du bruger IPv6) hos din DNS-udbyder, der peger eksempel.dk<\/code> og www.eksempel.dk<\/code> mod serverens offentlige IP. DNS kan tage op til 24 timer om at sprede sig, men typisk sker det inden for f\u00e5 minutter. Verific\u00e9r resultatet, f\u00f8r du g\u00e5r videre, ellers fejler HTTP-01-valideringen senere.<\/p>\n\n\n\n

# Kontroll\u00e9r at dom\u00e6net peger p\u00e5 den rigtige IP\ndig +short A eksempel.dk\ndig +short A www.eksempel.dk\n\n# Forventet output (din servers offentlige IP):\n# 203.0.113.42\n# 203.0.113.42<\/code><\/pre>\n\n\n\n
Hvis dig<\/code> returnerer en tom linje eller en forkert IP, s\u00e5 ret DNS-posten og vent, til den er opdateret. Du kan tjekke spredningen globalt med dig @8.8.8.8 eksempel.dk<\/code>, som sp\u00f8rger Googles offentlige resolver direkte. F\u00f8rst n\u00e5r begge navne peger korrekt, forts\u00e6tter du.<\/p>\n\n\n\n
Trin 2: Installer og konfigurer Nginx<\/h2>\n\n\n\n
Certbot skal kunne l\u00e6se din Nginx-konfiguration for automatisk at inds\u00e6tte TLS<\/strong>-direktiverne. Install\u00e9r Nginx, og opret et minimalt server-blok for dit dom\u00e6ne p\u00e5 port 80. Dette blok bruges b\u00e5de til selve siden og til at servere ACME-challenge-filen.<\/p>\n\n\n\n
# Install\u00e9r Nginx\nsudo apt update\nsudo apt install -y nginx\n\n# Opret server-blok\nsudo nano \/etc\/nginx\/sites-available\/eksempel.dk<\/code><\/pre>\n\n\n\n
Inds\u00e6t f\u00f8lgende konfiguration. L\u00e6g m\u00e6rke til root<\/code>-stien, for det er her, Certbot l\u00e6gger sin challenge-fil under HTTP-01.<\/p>\n\n\n\n
server {\n    listen 80;\n    listen [::]:80;\n    server_name eksempel.dk www.eksempel.dk;\n\n    root \/var\/www\/eksempel.dk;\n    index index.html;\n\n    location \/ {\n        try_files $uri $uri\/ =404;\n    }\n}<\/code><\/pre>\n\n\n\n
# Aktiv\u00e9r sitet og genindl\u00e6s\nsudo mkdir -p \/var\/www\/eksempel.dk\necho \"Hej fra eksempel.dk\" | sudo tee \/var\/www\/eksempel.dk\/index.html\nsudo ln -s \/etc\/nginx\/sites-available\/eksempel.dk \/etc\/nginx\/sites-enabled\/\nsudo nginx -t\nsudo systemctl reload nginx<\/code><\/pre>\n\n\n\n
Kommandoen nginx -t<\/code> tester konfigurationen, f\u00f8r du genindl\u00e6ser. F\u00e5r du syntax is ok<\/code> og test is successful<\/code>, er du klar. Bes\u00f8g http:\/\/eksempel.dk<\/code> i en browser og bekr\u00e6ft, at du ser hilsenen, f\u00f8r du forts\u00e6tter til certifikatet.<\/p>\n\n\n\n
Trin 3: \u00c5bn port 80 og 443 i firewallen<\/h2>\n\n\n\n
Den hyppigste \u00e5rsag til at en HTTP-01-validering fejler er en lukket port 80. Let’s Encrypt-serverne skal kunne n\u00e5 din server udefra. \u00c5bn b\u00e5de port 80 (HTTP, til validering) og port 443 (HTTPS, til det f\u00e6rdige TLS<\/strong>-certifikat) i din firewall.<\/p>\n\n\n\n
# Med UFW (Ubuntu standard)\nsudo ufw allow 80\/tcp\nsudo ufw allow 443\/tcp\nsudo ufw reload\nsudo ufw status\n\n# Forventet output:\n# 80\/tcp                     ALLOW       Anywhere\n# 443\/tcp                    ALLOW       Anywhere<\/code><\/pre>\n\n\n\n
Husk ogs\u00e5 eventuelle firewalls i skyen. Bruger du AWS, Azure, Hetzner eller DigitalOcean, har du sandsynligvis en sikkerhedsgruppe eller cloud-firewall, der skal \u00e5bnes separat. En lokal UFW-regel hj\u00e6lper ikke, hvis udbyderens firewall stadig blokerer port 80 udefra.<\/p>\n\n\n\n
Trin 4: Installer Certbot via snap<\/h2>\n\n\n\n
Den officielt anbefalede installationsmetode til Certbot er snap. Apt-pakken halter ofte flere versioner bagud, og da reglerne for et SSL certifikat<\/strong> \u00e6ndrer sig hurtigt i 2026, vil du have den nyeste klient. Snap-pakken opdaterer sig selv og giver dig Certbot 5.6.0.<\/p>\n\n\n\n
# Fjern en eventuel gammel apt-version\nsudo apt remove -y certbot\n\n# Install\u00e9r snapd og Certbot\nsudo apt install -y snapd\nsudo snap install core\nsudo snap refresh core\nsudo snap install --classic certbot\n\n# G\u00f8r certbot-kommandoen tilg\u00e6ngelig\nsudo ln -s \/snap\/bin\/certbot \/usr\/bin\/certbot\n\n# Bekr\u00e6ft versionen\ncertbot --version\n# Forventet: certbot 5.6.0<\/code><\/pre>\n\n\n\n
F\u00e5r du en \u00e6ldre version, s\u00e5 k\u00f8r sudo snap refresh certbot<\/code>. Foretr\u00e6kker du containere, findes Certbot ogs\u00e5 som OCI-image og kan installeres med pip, men snap er det mest gnidningsfrie valg p\u00e5 en almindelig server. Den fulde liste over metoder findes i Certbots officielle installationsdokumentation<\/a>.<\/p>\n\n\n\n
Trin 5: Udsted dit f\u00f8rste certifikat med HTTP-01<\/h2>\n\n\n\n
Nu kommer det centrale \u00f8jeblik. Certbots Nginx-plugin udsteder dit TLS<\/strong>-certifikat, redigerer din Nginx-konfiguration automatisk og ops\u00e6tter en omdirigering fra HTTP til HTTPS. K\u00f8r kommandoen med begge dom\u00e6nenavne.<\/p>\n\n\n\n
sudo certbot --nginx \\\n  -d eksempel.dk -d www.eksempel.dk \\\n  --email admin@eksempel.dk \\\n  --agree-tos \\\n  --no-eff-email \\\n  --redirect<\/code><\/pre>\n\n\n\n
Certbot gennemf\u00f8rer HTTP-01-challenge, henter certifikatet og skriver det til disk. Et vellykket forl\u00f8b ser s\u00e5dan ud:<\/p>\n\n\n\n
Successfully received certificate.\nCertificate is saved at: \/etc\/letsencrypt\/live\/eksempel.dk\/fullchain.pem\nKey is saved at:         \/etc\/letsencrypt\/live\/eksempel.dk\/privkey.pem\nThis certificate expires on 2026-09-09.\nThese files will be updated when the certificate renews.\nDeploying certificate\nSuccessfully deployed certificate for eksempel.dk to \/etc\/nginx\/sites-enabled\/eksempel.dk\nCongratulations! You have successfully enabled HTTPS on https:\/\/eksempel.dk and https:\/\/www.eksempel.dk<\/code><\/pre>\n\n\n\n
Bem\u00e6rk udl\u00f8bsdatoen 90 dage frem. Bes\u00f8g nu https:\/\/eksempel.dk<\/code>, og du ser h\u00e6ngel\u00e5sen. Certbot har samtidig tilf\u00f8jet en 301-omdirigering, s\u00e5 al HTTP-trafik automatisk sendes videre til HTTPS. Dit gratis SSL certifikat<\/strong> er live.<\/p>\n\n\n\n
Trin 6: Verificer TLS-konfigurationen med OpenSSL<\/h2>\n\n\n\n
Stol ikke blindt p\u00e5 h\u00e6ngel\u00e5sen. Verific\u00e9r certifikatk\u00e6den, udl\u00f8bsdatoen og den forhandlede protokol direkte fra kommandolinjen med OpenSSL. Det afsl\u00f8rer problemer, en browser skjuler, for eksempel en manglende mellemcertifikat-k\u00e6de.<\/p>\n\n\n\n
# Vis certifikatets udsteder, emne og gyldighed\necho | openssl s_client -connect eksempel.dk:443 -servername eksempel.dk 2>\/dev\/null \\\n  | openssl x509 -noout -issuer -subject -dates\n\n# Forventet output:\n# issuer=C=US, O=Let's Encrypt, CN=R13\n# subject=CN=eksempel.dk\n# notBefore=Jun 11 09:00:00 2026 GMT\n# notAfter=Sep  9 08:59:59 2026 GMT<\/code><\/pre>\n\n\n\n
For at bekr\u00e6fte, at TLS 1.3 (RFC 8446) faktisk bruges, kan du tvinge protokollen. Et vellykket h\u00e5ndtryk bekr\u00e6fter, at serveren forhandler den nyeste version af TLS<\/strong>.<\/p>\n\n\n\n
echo | openssl s_client -connect eksempel.dk:443 -tls1_3 2>\/dev\/null \\\n  | grep -E \"Protocol|Cipher\"\n# Forventet:\n# Protocol  : TLSv1.3\n# Cipher    : TLS_AES_256_GCM_SHA384<\/code><\/pre>\n\n\n\n
Vil du have en fuld karakter, s\u00e5 k\u00f8r dom\u00e6net gennem SSL Labs’ testv\u00e6rkt\u00f8j. Efter trin 7 b\u00f8r du ramme karakteren A eller A+. Et SSL certifikat<\/strong> alene giver ikke topkarakter; det afh\u00e6nger af protokoller og cipher-konfiguration.<\/p>\n\n\n\n
Trin 7: H\u00e6rd din Nginx SSL-konfiguration<\/h2>\n\n\n\n
Standardkonfigurationen fra Certbot er sikker, men du kan g\u00f8re den bedre. Sl\u00e5 gamle protokoller fra, aktiv\u00e9r kun st\u00e6rke ciphers og tilf\u00f8j HSTS, s\u00e5 browsere altid bruger HTTPS. F\u00f8lgende blok afspejler Mozillas “Intermediate”-profil og giver topkarakter p\u00e5 de fleste testv\u00e6rkt\u00f8jer.<\/p>\n\n\n\n
# Redig\u00e9r serverblokken, Certbot oprettede p\u00e5 port 443\nserver {\n    listen 443 ssl;\n    listen [::]:443 ssl;\n    http2 on;\n    server_name eksempel.dk www.eksempel.dk;\n\n    ssl_certificate     \/etc\/letsencrypt\/live\/eksempel.dk\/fullchain.pem;\n    ssl_certificate_key \/etc\/letsencrypt\/live\/eksempel.dk\/privkey.pem;\n\n    # Kun moderne protokoller\n    ssl_protocols TLSv1.2 TLSv1.3;\n    ssl_prefer_server_ciphers off;\n    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;\n\n    # Session-cache for ydelse\n    ssl_session_timeout 1d;\n    ssl_session_cache shared:MozSSL:10m;\n    ssl_session_tickets off;\n\n    # HSTS, tving HTTPS i 2 aar\n    add_header Strict-Transport-Security \"max-age=63072000\" always;\n\n    root \/var\/www\/eksempel.dk;\n    index index.html;\n}<\/code><\/pre>\n\n\n\n
Test og genindl\u00e6s altid efter \u00e6ndringer med sudo nginx -t && sudo systemctl reload nginx<\/code>. En vigtig detalje for 2026: Let’s Encrypt er begyndt at udfase OCSP til fordel for CRL’er, s\u00e5 fjern ssl_stapling on;<\/code> fra \u00e6ldre konfigurationer, da OCSP-stapling ikke l\u00e6ngere giver mening. Du kan generere en skr\u00e6ddersyet konfiguration til netop din software i Mozillas SSL Configuration Generator<\/a>.<\/p>\n\n\n\n
Trin 8: Aktiv\u00e9r automatisk fornyelse<\/h2>\n\n\n\n
Dette er det vigtigste trin i hele vejledningen. Med 90-dages-certifikater i dag og 47-dages-certifikater p\u00e5 vej er manuel fornyelse umulig i praksis. Snap-installationen af Certbot opretter automatisk en systemd-timer, der fornyer dit TLS<\/strong>-certifikat to gange dagligt og kun udsteder nyt, n\u00e5r der er under 30 dage tilbage.<\/p>\n\n\n\n
# Kontroll\u00e9r at fornyelsestimeren er aktiv\nsudo systemctl list-timers | grep certbot\n\n# Forventet output:\n# snap.certbot.renew.timer  ...  snap.certbot.renew.service\n\n# Se selve timerens status\nsystemctl status snap.certbot.renew.timer<\/code><\/pre>\n\n\n\n
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\u00f8lgende linje k\u00f8rer fornyelseskontrollen hver dag klokken 03:30 og genindl\u00e6ser Nginx, hvis et nyt certifikat blev hentet.<\/p>\n\n\n\n
# Redig\u00e9r root's crontab\nsudo crontab -e\n\n# Tilfoej denne linje:\n30 3 * * * certbot renew --quiet --deploy-hook \"systemctl reload nginx\"<\/code><\/pre>\n\n\n\n
Argumentet --deploy-hook<\/code> k\u00f8rer kun, n\u00e5r et certifikat faktisk blev fornyet, hvilket sparer un\u00f8dvendige genindl\u00e6sninger. Det er bedre end den gamle --post-hook<\/code>, der k\u00f8rte hver gang.<\/p>\n\n\n\n
Trin 9: Udsted et wildcard-certifikat med DNS-01<\/h2>\n\n\n\n
Har du mange underdom\u00e6ner, vil du have et wildcard SSL certifikat<\/strong>, der d\u00e6kker *.eksempel.dk<\/code> i \u00e9t. Det kr\u00e6ver 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.<\/p>\n\n\n\n
# Install\u00e9r Cloudflare-pluginet\nsudo snap set certbot trust-plugin-with-root=ok\nsudo snap install certbot-dns-cloudflare\n\n# Gem din API-token sikkert\nsudo mkdir -p \/root\/.secrets\necho \"dns_cloudflare_api_token = DIN_TOKEN_HER\" | sudo tee \/root\/.secrets\/cloudflare.ini\nsudo chmod 600 \/root\/.secrets\/cloudflare.ini\n\n# Udsted wildcard-certifikatet\nsudo certbot certonly \\\n  --dns-cloudflare \\\n  --dns-cloudflare-credentials \/root\/.secrets\/cloudflare.ini \\\n  -d eksempel.dk -d \"*.eksempel.dk\" \\\n  --email admin@eksempel.dk --agree-tos --no-eff-email<\/code><\/pre>\n\n\n\n
Husk at inkludere b\u00e5de eksempel.dk<\/code> og *.eksempel.dk<\/code>, fordi wildcard-delen ikke d\u00e6kker det n\u00f8gne dom\u00e6ne. Rettighederne p\u00e5 cloudflare.ini<\/code> skal v\u00e6re 600, s\u00e5 kun root kan l\u00e6se din API-token. En l\u00e6kket token giver en angriber kontrol over hele din DNS-zone.<\/p>\n\n\n\n
Trin 10: Skift til ECDSA-n\u00f8gler for hurtigere h\u00e5ndtryk<\/h2>\n\n\n\n
Som standard udsteder Let’s Encrypt et RSA 2048-bit SSL certifikat<\/strong>, men ECDSA-n\u00f8gler giver mindre certifikater og hurtigere TLS-h\u00e5ndtryk med samme sikkerhed. En ECDSA P-256-n\u00f8gle svarer kryptografisk til en RSA 3072-bit-n\u00f8gle, men er en br\u00f8kdel af st\u00f8rrelsen. Vil du forst\u00e5 matematikken bag, har vi en grundig gennemgang i artiklen om digitale signaturer forklaret<\/a>.<\/p>\n\n\n\n
# Udsted et nyt ECDSA-certifikat\nsudo certbot certonly --nginx \\\n  -d eksempel.dk -d www.eksempel.dk \\\n  --key-type ecdsa \\\n  --elliptic-curve secp256r1 \\\n  --cert-name eksempel.dk-ecdsa\n\n# Bekraeft noegletypen\nsudo certbot certificates | grep -A1 eksempel.dk-ecdsa<\/code><\/pre>\n\n\n\n
For maksimal kompatibilitet kan du k\u00f8re dobbelt udstedelse med b\u00e5de RSA og ECDSA, s\u00e5 \u00e6ldre klienter f\u00e5r RSA, mens moderne browsere f\u00e5r det hurtigere ECDSA-certifikat. De fleste servere har dog ikke brug for det i 2026, da praktisk talt alle klienter underst\u00f8tter ECDSA.<\/p>\n\n\n\n
Trin 11: Test fornyelse og overv\u00e5g udl\u00f8b<\/h2>\n\n\n\n
Stol aldrig p\u00e5, at automatisk fornyelse virker, f\u00f8r du har testet den. Certbot har en t\u00f8r-k\u00f8rsel, der gennemf\u00f8rer hele fornyelsesforl\u00f8bet mod Let’s Encrypts testmilj\u00f8 uden at bruge af din kvote. Det er din forsikring mod en pinlig nedetid om 60 dage.<\/p>\n\n\n\n
# Simul\u00e9r en fornyelse uden at udstede et rigtigt certifikat\nsudo certbot renew --dry-run\n\n# Forventet output afsluttes med:\n# Congratulations, all simulated renewals succeeded:\n#   \/etc\/letsencrypt\/live\/eksempel.dk\/fullchain.pem (success)<\/code><\/pre>\n\n\n\n
Ud over t\u00f8r-k\u00f8rslen b\u00f8r du ops\u00e6tte ekstern overv\u00e5gning, s\u00e5 du f\u00e5r besked, hvis et certifikat alligevel n\u00e6rmer sig udl\u00f8b. En simpel cron-baseret kontrol med OpenSSL kan sende dig en advarsel, hvis der er under 14 dage tilbage.<\/p>\n\n\n\n
# Skript der advarer hvis certifikatet udloeber inden for 14 dage\nexpiry=$(echo | openssl s_client -connect eksempel.dk:443 -servername eksempel.dk 2>\/dev\/null \\\n  | openssl x509 -noout -enddate | cut -d= -f2)\nexpiry_epoch=$(date -d \"$expiry\" +%s)\nnow_epoch=$(date +%s)\ndays_left=$(( (expiry_epoch - now_epoch) \/ 86400 ))\necho \"Dage tilbage: $days_left\"\nif [ \"$days_left\" -lt 14 ]; then\n  echo \"ADVARSEL: certifikatet udloeber snart!\" | mail -s \"TLS-advarsel\" admin@eksempel.dk\nfi<\/code><\/pre>\n\n\n\n
Trin 12: Forbered dig p\u00e5 47-dages og kortlivede certifikater<\/h2>\n\n\n\n
Det sidste trin handler om fremtiden. Med CA\/Browser Forums plan om 47-dages-certifikater fra 2029 og Let’s Encrypts kortlivede certifikater p\u00e5 160 timer (generelt tilg\u00e6ngelige siden 15. januar 2026) bliver fornyelseshyppigheden langt h\u00f8jere. En ops\u00e6tning, der fornyer hver 60. dag, holder ikke, n\u00e5r certifikatet kun lever i seks dage. Heldigvis kr\u00e6ver det ingen ny kode, kun en justering af tankegangen.<\/p>\n\n\n\n
For at opte ind p\u00e5 kortlivede certifikater i fremtiden tilknytter du en s\u00e6rlig ACME-profil. Certbots fornyelseslogik h\u00e5ndterer resten, fordi timeren allerede k\u00f8rer to gange dagligt og vil hente et nyt certifikat, s\u00e5 snart der er under en tredjedel af levetiden tilbage. Det vigtigste r\u00e5d er derfor: lad v\u00e6re med at hardkode 90 dage nogen steder. Stol p\u00e5 Certbots egen logik, der tilpasser sig den faktiske udl\u00f8bsdato.<\/p>\n\n\n\n
# Tjek hvilke ACME-profiler din konto understoetter\nsudo certbot certificates\n\n# Naar kortlivede profiler er tilgaengelige paa din konto,\n# kan du udstede med en profil-parameter (eksempel):\n# sudo certbot certonly --nginx -d eksempel.dk \\\n#   --preferred-profile shortlived<\/code><\/pre>\n\n\n\n
Kortlivede certifikater reducerer risikoen ved et kompromitteret SSL certifikat<\/strong> dramatisk, fordi et stj\u00e5let certifikat alligevel udl\u00f8ber inden for en uge, uden at nogen beh\u00f8ver at revokere det. Det er en af grundene til, at hele branchen bev\u00e6ger sig v\u00e6k fra lange levetider. Du kan l\u00e6se mere om de officielle gr\u00e6nser i Let’s Encrypts dokumentation om rate limits<\/a>.<\/p>\n\n\n\n
Komplet, fungerende projekt med Docker Compose<\/h2>\n\n\n\n
Vil du have hele ops\u00e6tningen i \u00e9n genskabelig pakke, er her et komplet projekt med Docker Compose. Det k\u00f8rer 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<\/strong> op at k\u00f8re p\u00e5 f\u00e5 minutter.<\/p>\n\n\n\n
# docker-compose.yml\nservices:\n  nginx:\n    image: nginx:1.27\n    ports:\n      - \"80:80\"\n      - \"443:443\"\n    volumes:\n      - .\/nginx.conf:\/etc\/nginx\/conf.d\/default.conf\n      - .\/certbot\/conf:\/etc\/letsencrypt\n      - .\/certbot\/www:\/var\/www\/certbot\n    restart: unless-stopped\n\n  certbot:\n    image: certbot\/certbot:latest\n    volumes:\n      - .\/certbot\/conf:\/etc\/letsencrypt\n      - .\/certbot\/www:\/var\/www\/certbot\n    entrypoint: \"\/bin\/sh -c 'trap exit TERM; while :; do certbot renew --webroot -w \/var\/www\/certbot; sleep 12h; done'\"\n    restart: unless-stopped<\/code><\/pre>\n\n\n\n
Den tilh\u00f8rende Nginx-konfiguration serverer ACME-challenge fra webroot, s\u00e5 Certbot kan validere via HTTP-01 uden at r\u00f8re Nginx-konfigurationen.<\/p>\n\n\n\n
# nginx.conf\nserver {\n    listen 80;\n    server_name eksempel.dk;\n    location \/.well-known\/acme-challenge\/ {\n        root \/var\/www\/certbot;\n    }\n    location \/ {\n        return 301 https:\/\/$host$request_uri;\n    }\n}\nserver {\n    listen 443 ssl;\n    server_name eksempel.dk;\n    ssl_certificate     \/etc\/letsencrypt\/live\/eksempel.dk\/fullchain.pem;\n    ssl_certificate_key \/etc\/letsencrypt\/live\/eksempel.dk\/privkey.pem;\n    ssl_protocols TLSv1.2 TLSv1.3;\n    location \/ {\n        root \/usr\/share\/nginx\/html;\n    }\n}<\/code><\/pre>\n\n\n\n
F\u00f8rste gang udsteder du certifikatet med en engangskommando: docker compose run --rm certbot certonly --webroot -w \/var\/www\/certbot -d eksempel.dk --email admin@eksempel.dk --agree-tos --no-eff-email<\/code>. Derefter k\u00f8rer fornyelsen automatisk. Hele projektet ligger i tre filer og kan versioneres i Git.<\/p>\n\n\n\n
8 almindelige faldgruber, du skal undg\u00e5<\/h2>\n\n\n\n
Selv en simpel SSL certifikat<\/strong>-ops\u00e6tning kan g\u00e5 galt p\u00e5 overraskende m\u00e5der. Her er de otte hyppigste faldgruber og hvordan du undg\u00e5r dem.<\/p>\n\n\n\n