47 dagen voor een SSL-certificaat: wanneer certificaatbeheer een infrastructuurprobleem wordt
Stel dat je vandaag verantwoordelijk bent voor 20 websites, enkele reverse proxies, VPN-portalen en andere publiek bereikbare diensten.
Je controleert de TLS-certificaten regelmatig. Sommige worden automatisch vernieuwd. Andere staan in een spreadsheet. Voor een paar systemen bestaat ergens een kalenderherinnering.
Dat kan vandaag nog werken.
De maximale geldigheidsduur van publiek vertrouwde TLS-certificaten wordt de komende jaren verder verkort. Sinds 15 maart 2026 bedraagt het maximum volgens de CA/Browser Forum-regels 200 dagen. Vanaf 15 maart 2027 wordt dat 100 dagen. Vanaf 15 maart 2029 wordt het 47 dagen.
DigiCert liep op deze eerste stap vooruit. Sinds 24 februari 2026 geeft DigiCert publieke TLS-certificaten uit met maximaal 199 dagen geldigheid.
Daarmee verandert certificaatbeheer van een periodieke administratieve taak in een proces dat steeds meer automatisering nodig heeft.
Waarom worden TLS-certificaten korter geldig?
Een TLS-certificaat koppelt een cryptografische sleutel aan een domeinnaam en ondersteunt de beveiliging van een versleutelde verbinding.
Wanneer een private key wordt gecompromitteerd, kan een aanvaller onder bepaalde omstandigheden misbruik maken van het bijbehorende certificaat zolang het geldig is.
Een kortere geldigheidsduur beperkt die periode.
De CA/Browser Forum heeft daarom een gefaseerde verlaging vastgelegd:
| Periode | Maximale geldigheidsduur |
|---|---|
| Tot 15 maart 2026 | 398 dagen |
| 15 maart 2026 tot 15 maart 2027 | 200 dagen |
| 15 maart 2027 tot 15 maart 2029 | 100 dagen |
| Vanaf 15 maart 2029 | 47 dagen |
Voor specifieke Certificate Authorities kunnen de praktische maxima één dag lager liggen. DigiCert hanteert bijvoorbeeld 199 dagen in de eerste fase en heeft aangekondigd uiteindelijk 46 dagen te hanteren.
Ook de hergebruikperiode van domeinvalidatie wordt korter
Er verandert meer dan alleen de geldigheidsduur van het certificaat.
Ook de periode waarin eerder uitgevoerde validatie opnieuw mag worden gebruikt, wordt verkort. Voor domein- en IP-validatie gaat de CA/Browser Forum-regelgeving uiteindelijk naar maximaal 10 dagen vanaf maart 2029.
DigiCert heeft de eerste stap al gezet. Sinds 24 februari 2026 is de maximale hergebruikperiode voor relevante domeinvalidatie bij DigiCert teruggebracht naar 199 dagen.
Voor organisaties betekent dit dat certificaatbeheer steeds meer een geautomatiseerd lifecycle-proces wordt.
47 dagen betekent niet dat je elke 47 dagen handmatig moet werken
Dit is voor mij het belangrijkste punt.
Een korte certificaatlevensduur hoeft geen administratieve last te worden wanneer de volledige lifecycle geautomatiseerd is.
Die lifecycle bestaat uit meerdere stappen:
- Certificaat aanvragen.
- Domeincontrole uitvoeren.
- Certificaat vernieuwen.
- Certificaat installeren.
- Diensten opnieuw laden wanneer dat nodig is.
- Controleren wanneer certificaten verlopen.
- Fouten signaleren.
- Vastleggen welk systeem en welke eigenaar bij het certificaat horen.
ACME, Automated Certificate Management Environment, is hiervoor een belangrijke standaard. ACME ondersteunt het geautomatiseerd aanvragen en vernieuwen van certificaten.
Ook Let’s Encrypt beweegt verder richting kortere certificaatlevensduur. Het heeft een gefaseerde overgang aangekondigd van 90 dagen naar 45 dagen. Vanaf februari 2027 wordt het standaardprofiel 64 dagen en vanaf februari 2028 45 dagen.
De richting is dus duidelijk: certificaatbeheer wordt steeds meer een softwareproces.
Het echte probleem zit vaak ergens anders
In veel IT-omgevingen is het certificaat zelf niet het grootste probleem.
Het probleem is dat niemand precies weet waar alle certificaten zich bevinden.
Een organisatie kan certificaten hebben op:
- een webserver
- een firewall
- een reverse proxy
- een load balancer
- een VPN-portaal
- een mailomgeving
- een API-endpoint
- een applicatieserver
- een containerplatform
Daar komt een tweede vraag bij:
Wie is verantwoordelijk voor elk certificaat?
Wanneer daarop geen duidelijk antwoord bestaat, wordt een korte certificaatlevensduur een operationeel risico.
Een Certificate Authority kan een nieuw certificaat correct uitgeven terwijl de productieomgeving nog steeds het oude certificaat gebruikt.
De aanvraag is dan succesvol verlopen.
De infrastructuur is ondertussen niet bijgewerkt.
Dat is een infrastructuurprobleem.
Een spreadsheet is geen certificaatbeheerplatform
Een spreadsheet kan nuttig zijn als inventaris.
Ik zou er geen volledige certificaat lifecycle aan toevertrouwen.
Stel dat je 50 certificaten beheert.
Bij een jaarlijkse cyclus moet je gemiddeld ongeveer 50 certificaatvernieuwingen per jaar opvolgen.
Bij een theoretische cyclus van 47 dagen kom je uit op ongeveer 388 uitgiftemomenten per jaar wanneer elk certificaat telkens opnieuw zijn volledige geldigheidsduur gebruikt.
Dat is bijna acht keer zoveel lifecycle-events.
Bij 200 certificaten loopt dat theoretisch op tot ongeveer 1.553 uitgiftemomenten per jaar.
De exacte frequentie hangt af van de gekozen vernieuwingsmomenten, de Certificate Authority en de gebruikte automatisering. Het voorbeeld maakt vooral zichtbaar hoeveel meer operationele gebeurtenissen ontstaan.
Daarom moet je niet alleen nadenken over certificaten.
Je moet nadenken over het proces waarmee certificaten worden beheerd.
Begin met een inventaris
Mijn eerste stap zou daarom niet zijn:
Welke certificaattool moeten we kopen?
Ik zou eerst een inventaris maken.
Voor ieder publiek TLS-certificaat wil ik minstens weten:
Domein
Voor welke hostname wordt het certificaat gebruikt?
Systeem
Waar wordt het certificaat geïnstalleerd?
Eigenaar
Wie is verantwoordelijk voor de dienst?
Certificate Authority
Wie heeft het certificaat uitgegeven?
Vervaldatum
Wanneer verloopt het huidige certificaat?
Vernieuwingsmethode
Handmatig, ACME of een andere automatisering?
Deployment
Hoe komt het vernieuwde certificaat op het systeem terecht?
Monitoring
Wie krijgt een waarschuwing wanneer de automatische vernieuwing mislukt?
Die laatste twee worden vaak vergeten.
Een certificaat automatisch aanvragen is slechts één deel van het proces.
Het nieuwe certificaat moet ook daadwerkelijk op het juiste systeem worden geïnstalleerd.
Automatisering moet de volledige keten volgen
Ik kijk bij infrastructuur graag naar het volledige proces.
Voor certificaatbeheer betekent dat ongeveer:
Detecteren → valideren → aanvragen → installeren → controleren → rapporteren
Een fout in één stap mag niet onzichtbaar blijven.
Stel dat de automatische vernieuwing succesvol is, maar de webserver blijft het oude certificaat aanbieden.
De Certificate Authority kent dan een nieuw, geldig certificaat toe.
De gebruiker krijgt ondertussen nog steeds het oude certificaat te zien.
Monitoring moet daarom controleren wat er daadwerkelijk vanaf de dienst wordt aangeboden.
Dat is een belangrijk verschil tussen:
“Het certificaat is vernieuwd.”
en:
“De dienst gebruikt het vernieuwde certificaat.”
Dit raakt ook je infrastructuurarchitectuur
De ontwikkeling naar kortere TLS-certificaten is voor mij daarom meer dan een wijziging in PKI-regels.
Het is een goede aanleiding om naar je infrastructuurarchitectuur te kijken.
Waar worden certificaten gebruikt?
Welke systemen zijn internet-facing?
Welke systemen ondersteunen ACME?
Welke systemen vereisen een andere deploymentmethode?
Welke certificaten worden nog handmatig geïnstalleerd?
Waar zitten afhankelijkheden?
Welke systemen moeten worden herladen nadat een certificaat is vervangen?
En vooral:
Wat gebeurt er wanneer de automatische vernieuwing mislukt?
Dat is een architectuurvraag.
Een goed ontworpen infrastructuur moet het normale proces kunnen uitvoeren en zichtbaar maken wanneer dat proces faalt.
Security en operations komen hier samen
De kortere certificaatlevensduur heeft een duidelijk securitydoel: de periode waarin een gecompromitteerde sleutel of verouderde certificaatinformatie bruikbaar kan blijven, wordt beperkt. De CA/Browser Forum heeft deze wijzigingen vastgelegd in Ballot SC081v3.
De securitywinst vraagt vervolgens om operationele aanpassingen.
Een certificaat dat automatisch wordt vernieuwd en correct wordt uitgerold vraagt weinig menselijke aandacht.
Een certificaat dat in een spreadsheet staat en door een medewerker op een firewall moet worden geïnstalleerd, vraagt bij iedere vernieuwing menselijke interventie.
Naarmate de geldigheidsduur korter wordt, neemt de hoeveelheid operationeel werk toe.
Daarom hoort certificaatbeheer thuis in je infrastructuurbeheer.
Wat zou ik vandaag bij een kmo controleren?
Ik zou vijf vragen stellen:
- Hebben we een volledige inventaris van publieke TLS-certificaten?
- Weten we voor elk certificaat wie eigenaar is?
- Welke certificaten worden vandaag nog handmatig vernieuwd?
- Kunnen onze systemen certificaten automatisch aanvragen én installeren?
- Controleren we of het vernieuwde certificaat daadwerkelijk actief is?
Als je op meerdere vragen “nee” moet antwoorden, is het verstandig om nu met de inventaris en automatisering te beginnen.
Je hoeft niet te wachten tot 2029.
De eerste stap is al gezet. Sinds 15 maart 2026 is het CA/Browser Forum-maximum voor publieke TLS-certificaten 200 dagen. DigiCert hanteert sinds 24 februari 2026 maximaal 199 dagen. In maart 2027 volgt de volgende CA/Browser Forum-stap naar 100 dagen.
Voor mij is dit precies het soort wijziging waarbij security en infrastructuur samenkomen.
De technische regel verandert.
De gevolgen verschijnen vervolgens in je processen, monitoring, documentatie en architectuur.
Wie certificaten vandaag nog als een jaarlijkse administratieve taak behandelt, krijgt de komende jaren steeds vaker met dezelfde operationele vraag te maken:
Hoe zorg ik ervoor dat het juiste certificaat automatisch op het juiste systeem terechtkomt en dat ik weet wanneer dat proces mislukt?
Dat is uiteindelijk de infrastructuurvraag achter de 47 dagen.
Ik ben een Systems Integrator en Infrastructure Architect met meer dan 28 jaar professionele ervaring. Mijn mening is mijn eigen mening en de visie van Peritus Consult, niet de mening van mijn werkgever Lab9 Pro.
