Let’s Encrypt utfärdar certifikat på nittio dagar och förnyar dem automatiskt, och därför slutar man tänka på dem en vecka efter uppsättningen. Problemet är att den automatiska förnyelsen går sönder tyst: ingen ser felen, och tre månader senare möts besökarna av en varning i webbläsaren. Sedan 2025 skickar Let’s Encrypt inte längre några påminnelser om utgång, så den sista yttre påminnelsen är också borta.

Nedan följer skälen till att förnyelsen slutar fungera, i fallande ordning efter hur vanliga de är.

1. Certifikatet förnyat men tjänsten laddade inte in det

Det vanligaste. certbot renew gick igenom, den nya filen ligger på disken, men nginx eller Apache håller fortfarande den gamla i minnet — och levererar den till besökarna tills konfigurationen laddas om. Formellt är allt i sin ordning, i praktiken har sajten ett utgånget certifikat.

Det botas med en hook som körs efter en lyckad förnyelse:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Det skrivs in en gång i förnyelsefilen (/etc/letsencrypt/renewal/example.com.conf, avsnittet [renewalparams], raden renew_hook) och fungerar sedan av sig självt.

2. Webbservern ändrades men valideringen blev kvar

HTTP-01-validering kräver att filen under /.well-known/acme-challenge/ levereras över vanlig HTTP. Det går vanligen sönder så här:

  • en villkorslös omdirigering från HTTP till HTTPS lades till i konfigurationen — valideringen hamnar i omdirigeringen och går inte igenom;
  • en regel location ~ /\. med deny all dök upp och stänger alla kataloger med punkt, däribland .well-known;
  • sajtens rotkatalog ändrades medan certbots inställningar har kvar gamla --webroot-path;
  • landsblockering eller basautentisering slogs på och råkade även träffa valideringsservern.

Rätt ordning i konfigurationen: först ett eget location för /.well-known/acme-challenge/, och först därefter den allmänna omdirigeringen.

3. Timern är avstängd

Förnyelsen startas av en systemd-timer eller ett cron-jobb, och båda går att stänga av av misstag vid felsökning eller tappa bort vid en serverflytt.

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

Det andra kommandot kör hela förnyelsecykeln i provläge utan att förbruka några kvoter. Det är den enda kontroll som svarar på frågan ”kommer den att förnyas om en månad” i förväg och inte i efterhand.

4. Domänen pekar inte hit längre

Certifikatet omfattar fem domäner, en av dem har flyttat till en annan hosting och DNS har ändrats. Valideringen av den domänen slutar gå igenom, och certbot förnyar inte hela certifikatet — tillsammans med de fyra fungerande domänerna. Överflödiga domäner ska tas bort ur certifikatet, inte ignoreras.

5. Kvoterna är nådda

Let’s Encrypt begränsar antalet certifikat per domän och vecka. Det beror vanligen på slingan ”det gick inte, jag provar igen” under felsökning. För experiment finns en testserver (--dry-run eller --test-cert), och den ska användas innan kvoten är förbrukad, inte efteråt.

Kontrollera det som levereras

Varje kontroll som utgår från filer har en brist: filen kan vara färsk medan besökaren ändå får det gamla certifikatet. Man måste titta från klientens håll:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

Flaggan -servername är obligatorisk: utan den får du på en server med flera sajter certifikatet för den första bästa virtuella värden och inte det du frågade efter. I utdatan är notAfter det verkliga utgångsdatumet.

Passa samtidigt på att kontrollera kedjan:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

Är certifikatet ett enda levereras inte mellancertifikatet. Webbläsare brukar förlåta den uppsättningen — de sluter kedjan själva — medan curl, mobilappar och Java-klienter kastar ett valideringsfel. Det är det klassiska ”hos mig öppnas allt, hos kunden fungerar det inte”.

Hur många dagar i förväg man ska varna

Trettio dagar är en rimlig första tröskel: exakt så lång tid återstår när certbot börjar sina förnyelseförsök, så har ingenting hänt till dess är mekanismen trasig. Fjorton dagar är den andra signalen och kräver åtgärd redan i dag. Sju är nödläge.

Det viktiga är att hålla koll på alla certifikat samtidigt, även de som inte kommer från Let’s Encrypt: de som köpts på ett år glöms säkrast av alla, eftersom alla under ett år hinner glömma både dem och vems adress påminnelserna går till. En sida med domänlista, datum och antal dagar kvar stänger frågan helt — som i demonstrationen nedan.