SSL-certificaat verlopen of vernieuwt niet
Een verlopen certificaat is de storing met de grootste impact per oorzaak: de site is onbruikbaar, browsers waarschuwen luid, en het is te voorkomen met één werkende cronjob. Meestal blijkt de vernieuwing al weken stil te falen.
Loop je hier nu tegenaan?
Bel en leg het voor. Vaak is in tien minuten duidelijk waar het aan ligt. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Herken je dit?
- Bezoekers zien een waarschuwing dat de verbinding niet privé is.
- Certbot meldt succes, maar de site gebruikt nog het oude certificaat.
- De vernieuwing faalt met een validatiefout.
- Alleen sommige subdomeinen geven een fout.
- Mailclients klagen over het certificaat terwijl de website goed werkt.
Waar het meestal aan ligt
In verreweg de meeste gevallen is het één van deze. Loop ze in deze volgorde na.
Vernieuwd maar niet herladen
Het nieuwe certificaat staat op schijf, maar nginx, Postfix of Dovecot draait nog met het oude in het geheugen. Zonder --deploy-hook of reload verandert er voor bezoekers niets.
HTTP-01-validatie die niet lukt
Een redirect naar HTTPS, een firewall die poort 80 blokkeert of een proxy die /.well-known/acme-challenge/ niet doorlaat. Dan kan Let's Encrypt niet valideren.
DNS-01 en wildcards
Voor wildcardcertificaten is DNS-validatie verplicht. Een API-token dat is verlopen of een DNS-provider die traag propageert, laat de vernieuwing stil falen.
De timer of cronjob draait niet
Na een migratie of upgrade is de systemd-timer niet meegekomen. Dat merk je precies 90 dagen later, wat het lastig te koppelen maakt aan de oorzaak.
Incomplete keten
Alleen het certificaat geïnstalleerd en niet de tussenliggende keten. Browsers vullen dat vaak zelf aan, maar mailservers en API-clients niet — vandaar klachten van alleen bepaalde clients.
Domein niet in het certificaat
Een subdomein dat later is toegevoegd, staat niet in de SAN-lijst. Dat geeft een fout op alleen dat subdomein, terwijl de rest werkt.
Wat ik als eerste check
Doe deze stappen zelf, of bel en dan lopen we ze samen door.
- 1
Kijk welk certificaat er daadwerkelijk wordt aangeboden
echo | openssl s_client -connect jouwdomein.nl:443 -servername jouwdomein.nl 2>/dev/null | openssl x509 -noout -dates -subject. Dat is de waarheid, in plaats van wat er op schijf staat. - 2
Test de vernieuwing droog
certbot renew --dry-runlaat zien of de validatie zou lukken zonder je rate limits te verbranden. Dit is het commando dat je één keer per kwartaal zou willen draaien. - 3
Controleer of de timer loopt
systemctl list-timers | grep -i certbotof de cron-entry. Geen timer betekent geen vernieuwing, ongeacht hoe goed de rest staat. - 4
Controleer de reload-hook
Zorg dat er na vernieuwing daadwerkelijk een
reloadvan nginx, Postfix en Dovecot volgt. Dit is de meest voorkomende oorzaak van "vernieuwd maar nog steeds verlopen". - 5
Test de keten van buitenaf
Een externe SSL-test laat zien of de keten compleet is en welke clients problemen zouden hebben. Handig juist omdat browsers een incomplete keten maskeren.
- 6
Zet monitoring op de expiratiedatum
Een melding bij 21 dagen resterend zet dit probleem definitief uit. Dit is tien minuten werk en voorkomt de dure variant van deze storing.
Bijna altijd de reload
Als iemand mij belt over een verlopen certificaat terwijl certbot succes meldt, is het in negen van de tien gevallen de reload. Certificaten worden netjes vernieuwd, alleen ziet niemand ze omdat de draaiende dienst het oude bestand nog in het geheugen heeft.
De tweede grote categorie is de timer die na een migratie niet is meegekomen. Dat is de vervelendste variant, omdat de storing pas negentig dagen na de eigenlijke fout toeslaat en niemand het verband meer legt.
Eén keer goed inrichten
Vernieuwing, reload-hooks voor web én mail, en een melding drie weken voor expiratie: dan is dit type storing voorbij. Bel of mail als je dat in één keer geregeld wil hebben, of als er nu een certificaat verlopen is.
Veelgestelde vragen
- Certbot zegt dat het certificaat is vernieuwd, maar de site geeft nog een fout.
- Dan wordt de dienst niet herladen. Het nieuwe certificaat staat op schijf, maar nginx houdt het oude in het geheugen tot een reload. Voeg een deploy-hook toe die de betrokken diensten herlaadt en het probleem is structureel weg.
- Waarom faalt de validatie terwijl mijn site prima werkt?
- Meestal doordat poort 80 dicht staat of alles naar HTTPS wordt geredirect inclusief het acme-challenge-pad. Let's Encrypt moet dat pad over HTTP kunnen bereiken. De uitzondering daarvoor instellen is een paar regels configuratie.
- Hoe lang duurt het voordat bezoekers de fout niet meer zien?
- Zodra het nieuwe certificaat is geïnstalleerd én de dienst is herladen, is het direct weg. Er is geen propagatietijd zoals bij DNS. Vandaar dat dit een storing is die je in minuten kunt oplossen, mits je weet waar je moet kijken.
- Kun je dit inrichten zodat het niet meer gebeurt?
- Ja: automatische vernieuwing met deploy-hooks voor alle betrokken diensten, plus monitoring op de expiratiedatum van al je domeinen. Dat is een korte opdracht en een van de meest rendabele dingen die je aan je infrastructuur kunt laten doen.
Verwante problemen
502 Bad Gateway bij nginx oplossen
502 Bad Gateway betekent dat nginx je applicatie niet kan bereiken of geen geldig antwoord krijgt. Dit zijn de oorzaken en de eerste checks.
[Mailserver]Mailserver werkt niet meer: Postfix, Dovecot en Mailcow
Mail blijft in de queue, TLS-fouten, volle schijf of een certificaat dat niet vernieuwt: de meest voorkomende storingen op een eigen mailserver.
[Docker]Docker-container start niet of crasht direct
Container die direct stopt, exit code 137 of 125, volumes die leeg zijn na een herstart en containers die elkaar niet vinden. Dit check ik als eerste.
Zelf geen tijd of geen zin om te blijven zoeken?
Ik kijk mee, zeg eerlijk wat er aan de hand is en los het op. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Terug naar Linux serverbeheer en troubleshooting