SSL/TLS-certificaat verlopen: waarom websites er nog steeds door platgaan

Wanneer een TLS-certificaat verloopt, vertrouwen browsers de verbinding niet meer en tonen ze een paginagrote waarschuwing in plaats van uw website. API's, mobiele apps en koppelingen die met dezelfde host verbinden, falen meestal volledig, omdat hun clients een verlopen certificaat weigeren zonder iemand iets te vragen. De site zelf draait misschien perfect, maar voor bezoekers is ze onbereikbaar.

Vernieuwing is al jaren geautomatiseerd, dus waarom gebeurt dit nog? Omdat automatisering alleen werkt voor de certificaten die iemand ook echt heeft geautomatiseerd. Storingen door verlopen certificaten komen meestal van de vergeten exemplaren: een subdomein voor een campagne, een load balancer met een handmatig geüpload certificaat, een mailserver, of een vernieuwingstaak die al weken ongemerkt mislukt.

Bovendien wordt de geldigheid van certificaten korter, waardoor elk vernieuwingsproces vaker op de proef wordt gesteld.

De geldigheid van certificaten krimpt

Het CA/Browser Forum bepaalt de regels die algemeen vertrouwde certificaatautoriteiten volgen. In april 2025 nam het ballot SC-081v3 aan, en de huidige TLS Baseline Requirements (sectie 6.3.2) leggen dit schema vast voor de maximale geldigheid van een certificaat:

• uitgegeven vóór 15 maart 2026: maximaal 398 dagen,
• uitgegeven vanaf 15 maart 2026: maximaal 200 dagen,
• uitgegeven vanaf 15 maart 2027: maximaal 100 dagen,
• uitgegeven vanaf 15 maart 2029: maximaal 47 dagen.

In de praktijk betekent dit dat een handmatig vernieuwd certificaat tegen 2029 ongeveer elke 6 tot 7 weken vervangen moet worden. Elk certificaat dat nog met de hand wordt vernieuwd op basis van een agendaherinnering, wordt een terugkerend risico op uitval.

Ook op herinneringen van de certificaatautoriteit kunt u niet rekenen. Let's Encrypt bijvoorbeeld stopte op 4 juni 2025 met e-mails over verlopende certificaten.

Waarom vernieuwingen mislukken

De gebruikelijke oorzaken zijn alledaags:

• De validatie mislukt. HTTP-validatie breekt na een wijziging in redirects of firewall; DNS-validatie breekt na een wissel van DNS-provider of een verlopen API-token.
• De vernieuwing lukt, maar de dienst wordt niet herladen, waardoor de webserver het oude certificaat blijft serveren.
• Certificaten zijn met de hand gekopieerd naar een load balancer, CDN, appliance of mailserver die de automatisering niet bereikt.
• Niemand is eigenaar van de host. Stagingservers en oude marketingsubdomeinen hebben vaak certificaten maar geen eigenaar. Zie vergeten staging- en testservers.
• Het account of de betaling voor een commercieel certificaat is verlopen.
• De tussenliggende keten is onvolledig, wat sommige clients al vóór de vervaldatum weigeren.

Zo controleert u zelf de vervaldatum van een certificaat

Voor één host toont openssl de data die de server werkelijk presenteert:

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

Kijk naar notAfter. Controleer elke naam apart, ook www, API-hosts en mailhosts. Voor een mailserver met STARTTLS:

echo | openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null | openssl x509 -noout -enddate

Om hosts te vinden die u misschien vergeten bent, zoekt u in de Certificate Transparency-logs op crt.sh naar %.example.com. Elk certificaat dat voor uw domein is uitgegeven, staat daar, ook voor subdomeinen die niemand zich nog herinnert. Ons artikel over Certificate Transparency-logs legt uit hoe u de resultaten leest.

Zo voorkomt u dat certificaten verlopen

1. Automatiseer uitgifte en vernieuwing met ACME waar het kan, en laat de vernieuwingstaak de dienst daarna herladen.
2. Vernieuw ruim vóór de vervaldatum, vroeg genoeg om tijd te hebben voor het herstellen van een mislukte validatie.
3. Waarschuw bij mislukte vernieuwingen, niet alleen bij succes. Een cronjob die met een fout stopt en niemand iets laat weten, is de klassieke oorzaak.
4. Houd een inventaris bij van elke host met een certificaat, opgebouwd uit de resultaten van Certificate Transparency, niet uit het geheugen.
5. Monitor van buitenaf. Controleer het certificaat dat de server werkelijk presenteert, want dat is wat clients zien. Een interne notitie met "vernieuwd" is niet hetzelfde.
6. Verwijder wat u niet meer gebruikt. Een subdomein dat niets meer serveert, hoort zijn DNS-record en zijn certificaat kwijt te raken.

Als een certificaat al verlopen is

• Vernieuw het certificaat of laat het opnieuw uitgeven, rol het uit en herlaad de dienst.
• Bevestig met openssl s_client van buiten uw netwerk dat de nieuwe notAfter-datum wordt geserveerd.
• Controleer dat de volledige keten wordt geserveerd, niet alleen het eindcertificaat.
• Controleer afhankelijke clients: mobiele apps, koppelingen van partners en webhooks hebben mogelijk een nieuwe poging nodig.
• Zoek uit waarom de waarschuwing niet afging en los dat op.

Checklist

• Inventaris van alle hosts met certificaten, inclusief mail- en API-hosts.
• ACME-automatisering met herladen van de dienst.
• Waarschuwingen bij mislukte vernieuwingen.
• Externe controle van de vervaldatum op elke host.
• Voorbereid op een geldigheid van 100 en 47 dagen.

Hoe Datahorses helpt

Datahorses bewaakt uw bedrijf van buitenaf en controleert de certificaten die uw servers werkelijk presenteren, inclusief vervaldatum, gebroken ketens en zelfondertekende certificaten, met herinneringen 30, 14 en 3 dagen voordat een certificaat of domein verloopt. We gaan uw systemen niet binnen en hebben geen toegang nodig. Bekijk wat wij bewaken en het voorbeelddashboard om te zien hoe het eruitziet.