Let’s Encrypt utsteder sertifikater på nitti dager og fornyer dem automatisk, og derfor slutter man å tenke på dem en uke etter oppsettet. Problemet er at den automatiske fornyelsen ryker stille: ingen ser feilene, og tre måneder senere møtes besøkende av en advarsel i nettleseren. Siden 2025 sender ikke Let’s Encrypt lenger påminnelser om utløp, så den siste ytre påminnelsen er også borte.

Nedenfor følger grunnene til at fornyelsen slutter å virke, i synkende rekkefølge etter hvor vanlige de er.

1. Sertifikatet er fornyet, men tjenesten lastet det ikke inn

Det vanligste. certbot renew gikk gjennom, den nye filen ligger på disken, men nginx eller Apache holder fortsatt den gamle i minnet — og leverer den til besøkende inntil konfigurasjonen lastes på nytt. Formelt er alt i orden, i praksis har nettstedet et utløpt sertifikat.

Det bøtes med en hook som kjøres etter en vellykket fornyelse:

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

Det skrives inn én gang i fornyelsesfilen (/etc/letsencrypt/renewal/example.com.conf, seksjonen [renewalparams], linjen renew_hook) og virker deretter av seg selv.

2. Webserveren ble endret, men valideringen ble stående

HTTP-01-validering krever at filen under /.well-known/acme-challenge/ leveres over vanlig HTTP. Det ryker som regel slik:

  • en betingelsesløs omdirigering fra HTTP til HTTPS ble lagt til i konfigurasjonen — valideringen havner i omdirigeringen og går ikke gjennom;
  • en regel location ~ /\. med deny all dukket opp og stenger alle kataloger med punktum, deriblant .well-known;
  • nettstedets rotkatalog ble endret, mens certbots innstillinger har den gamle --webroot-path;
  • landsblokkering eller basisautentisering ble slått på og traff også valideringsserveren.

Riktig rekkefølge i konfigurasjonen: først et eget location for /.well-known/acme-challenge/, og først deretter den generelle omdirigeringen.

3. Timeren er slått av

Fornyelsen startes av en systemd-timer eller en cron-jobb, og begge kan slås av ved et uhell under feilsøking eller mistes ved en serverflytting.

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

Den andre kommandoen kjører hele fornyelsessyklusen i prøvemodus uten å bruke av kvotene. Det er den eneste kontrollen som svarer på spørsmålet «blir den fornyet om en måned» på forhånd og ikke i etterkant.

4. Domenet peker ikke hit lenger

Sertifikatet omfatter fem domener, ett av dem har flyttet til en annen hosting, og DNS er endret. Valideringen av det domenet slutter å gå gjennom, og certbot fornyer ikke hele sertifikatet — sammen med de fire fungerende domenene. Overflødige domener skal fjernes fra sertifikatet, ikke ignoreres.

5. Kvotene er nådd

Let’s Encrypt begrenser antall sertifikater per domene per uke. Det skyldes som regel sløyfen «det gikk ikke, jeg prøver igjen» under feilsøking. Til eksperimenter finnes en testserver (--dry-run eller --test-cert), og den skal brukes før kvoten er brukt opp, ikke etterpå.

Kontroller det som leveres

Enhver kontroll som tar utgangspunkt i filer, har én svakhet: filen kan være fersk, mens besøkende likevel får det gamle sertifikatet. Man må se fra klientens side:

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

Flagget -servername er obligatorisk: uten det får du på en server med flere nettsteder sertifikatet til den første beste virtuelle verten og ikke det du spurte om. I utdataene er notAfter den virkelige utløpsdatoen.

Benytt samtidig anledningen til å kontrollere kjeden:

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

Er sertifikatet ett eneste, leveres ikke mellomsertifikatet. Nettlesere pleier å tilgi det oppsettet — de slutter kjeden selv — mens curl, mobilapper og Java-klienter kaster en valideringsfeil. Det er det klassiske «hos meg åpnes alt, hos kunden virker det ikke».

Hvor mange dager på forhånd man skal varsle

Tretti dager er en fornuftig første terskel: nøyaktig så lang tid gjenstår når certbot begynner fornyelsesforsøkene sine, så har ingenting skjedd innen da, er mekanismen ødelagt. Fjorten dager er det andre signalet og krever handling allerede i dag. Sju er nødsituasjon.

Det viktige er å holde oversikt over alle sertifikater samtidig, også dem som ikke kommer fra Let’s Encrypt: de som er kjøpt for ett år, glemmes sikrest av alle, siden alle i løpet av et år rekker å glemme både dem og hvem sin adresse påminnelsene går til. Én side med domeneliste, datoer og antall dager igjen lukker saken helt — som i demonstrasjonen nedenfor.