SSL-certificaatmonitoring: een praktische gids voor 2026

Verlopen SSL-certificaten zijn de meest te voorkomen storing in de sector. Het certificaat was gisteren nog geldig, je monitoring bleef stil, en vanochtend toont elke browser de rode waarschuwingspagina. Automatische verlengingen mislukken vaker dan mensen toegeven, en een Letʼs Encrypt-certificaat van 90 dagen laat weinig marge voor een gemiste verlengingstaak. Deze gids behandelt hoe SSL-monitoring werkelijk werkt, waarop je moet alarmeren en hoe je voorkomt dat certificaten je in de staart bijten.

Waarom SSL-storingen blijven gebeuren in het tijdperk van automatische verlenging

Automatische verlenging heeft het verlopen van SSL niet opgelost. Het heeft alleen verplaatst waar de fout optreedt. De certbot- of acme.sh-taak draait, maar het nieuwe certificaat wordt nooit door nginx geladen omdat de reload-stap is uitgeschakeld. De Kubernetes-ingress verlengt, maar het secret wordt nooit doorgegeven aan een pod die nog het oude certificaat serveert. Een multi-domein-SAN-certificaat verlengt, maar een van de hostnames is uit het verzoek verwijderd en serveert nu een verlopen alternatief.

Externe monitoring vangt al deze gevallen op omdat ze je interne toestand niet vertrouwt. Ze ziet wat een echte browser ziet: het certificaat dat op de publieke hostname, op de publieke poort, in de live TLS-handshake wordt aangeboden. Als niet het juiste certificaat wordt geserveerd, weet de monitor dat, ongeacht wat je cronlogs zeggen.

Wat een SSL-monitor daadwerkelijk controleert

Een goed opgezette SSL-monitor doet zes dingen bij elke probe. De meeste tools tonen er een handvol van als alerts en verstoppen de rest.

• Dagen tot verloop, de hoofdmetriek, getoond met een instelbaar waarschuwingsvenster.
• Hostname-match, zodat een certificaat dat geldig is voor example.com maar geserveerd wordt op api.example.com onmiddellijk alarm geeft.
• Certificaatketenvalidatie, waarbij ontbrekende intermediates worden opgevangen die in sommige browsers werken maar op mobiel falen.
• Detectie van zelfondertekende en niet-vertrouwde uitgevers voor stagingomgevingen die per ongeluk een echt certificaat krijgen.
• TLS-versie, zodat verouderde protocollen (TLS 1.0, TLS 1.1) gemarkeerd worden voordat browsers ze volledig laten vallen.
• Lijst met subject alternative names, nuttig voor SAN-certificaten die tijdens een verlenging stilletjes een hostname verliezen.

Hoe je waarschuwingsvensters instelt die echt werken

Een waarschuwingsvenster van 7 dagen is te kort. Een venster van 90 dagen leidt tot alert-moeheid. De waarden die in de praktijk werken zijn 30 dagen voor de eerste waarschuwing en 7 dagen voor een escalatie.

30 dagen is voldoende tijd om te ontdekken dat je verlengingstaak al weken in stilte faalt, het onderliggende probleem te debuggen en een nieuw certificaat zonder paniek uit te rollen. 7 dagen is het moment waarop je on-call gepiept moet worden, ongeacht het tijdstip. Als je slechts één waarschuwing krijgt, is de late nuttiger, omdat de vroege vaak wordt bevestigd en vergeten.

Gangbare operationele gewoonten die SSL-storingen voorkomen

Drie gewoonten, in volgorde van prioriteit, houden SSL uit je incidentrapporten.

• Monitor elke publieke hostname afzonderlijk. Het wildcard-certificaat is geen vervanging voor het monitoren van elk subdomein dat het gebruikt, omdat alles wat het verkeerde certificaat serveert (een verkeerd geconfigureerde proxy, een verouderde CDN-cache) niet opduikt in een wildcard-check.
• Test het verlengingspad volgens een schema. Een maandelijkse dry-run die de verlenging in staging uitvoert is veel goedkoper dan na 90 dagen ontdekken dat de verlengingstaak is verrot.
• Verbind SSL-alerts met hetzelfde kanaal als deploymentmeldingen. SSL-bugs zijn vrijwel altijd terug te voeren op een deploy die het certificaatpad, het reload-commando of de secret-naam heeft gewijzigd.

Wanneer automatisering niet genoeg is

Drie situaties vereisen een mens in de lus en geen enkele mate van automatisering kan dat wegnemen.

Ten eerste een domeinoverdracht of registrarwissel. De verlengingstaak authenticeert bij de oude registrar, faalt in stilte, en het certificaat verloopt. Ten tweede een wissel van CDN-provider. De nieuwe CDN serveert een standaardcertificaat totdat je de jouwe uploadt. Ten derde multi-regio-opstellingen waarbij de verlengingstaak in één regio draait, maar het certificaat naar alle regioʼs moet worden uitgerold. SSL-monitoring vangt alle drie op symptoomniveau (verkeerd certificaat geserveerd) op vóór de klant het doet.

Alles samengevoegd

Voeg één SSL-monitor toe voor elke publieke hostname die je bezit. Stel de waarschuwing in op 30 dagen. Routeer de alert naar hetzelfde kanaal waar je deploymeldingen binnenkomen. Voeg een escalatie van 7 dagen toe die on-call piept. Voer maandelijks een dry-run van de verlenging uit. Met die vier dingen op hun plek houdt SSL op een terugkerend incidenttype te zijn.