TLS/SSL certificaten krijgen kortere geldigheid

TLS/SSL certificaten krijgen kortere geldigheid – wat betekent dit voor bedrijven?

door: Dennis Kruyt

De wereld van TLS-certificaten staat aan de vooravond van een grote verandering. Het CA/Browser Forum – het samenwerkingsverband van browserleveranciers en certificaatautoriteiten – heeft met ballot SC-081v3 (aangenomen op 11 april 2025) besloten om de maximale geldigheid van publiek vertrouwde TLS-certificaten stapsgewijs terug te brengen naar uiteindelijk 47 dagen. Tot nu toe konden certificaten maximaal 398 dagen geldig zijn. Maar dat verandert snel. In deze blog lees je wat de planning is, waarom deze wijziging er komt, welk technisch detail vaak over het hoofd wordt gezien en waarom automatisering van certificaatbeheer onmisbaar wordt.

📌 TLS of SSL?

In de volksmond spreken we nog vaak over "SSL-certificaten", maar het SSL-protocol is al sinds 2015 officieel afgeschreven (de laatste versie, SSL 3.0, sneuvelde door de POODLE-aanval). Wat we vandaag de dag gebruiken is TLS (Transport Layer Security), inmiddels TLS 1.3. De certificaten zijn dezelfde X.509-certificaten; alleen de naam "SSL" is blijven hangen. In deze blog hanteren we daarom consequent de term TLS-certificaat.

Een grote verandering voor certificaatbeheer

Het CA/Browser Forum heeft besloten om de maximale geldigheid van publiek vertrouwde TLS-certificaten stapsgewijs te verkorten. Het huidige maximum van 398 dagen geldt overigens al sinds september 2020 – daarvóór waren certificaten van twee of zelfs drie jaar nog gangbaar. Die periode gaat de komende jaren verder omlaag.

De planning kent vier stappen:

  • Tot 15 maart 2026: maximaal 398 dagen
  • Vanaf 15 maart 2026: maximaal 200 dagen
  • Vanaf 15 maart 2027: maximaal 100 dagen
  • Vanaf 15 maart 2029: maximaal 47 dagen

Dit betekent dat certificaten steeds vaker vernieuwd moeten worden. Maar er zit een addertje onder het gras dat in veel berichtgeving onderbelicht blijft.

Het detail dat vaak wordt gemist: domeinvalidatie verkort mee

Voordat een certificaatautoriteit (CA) een certificaat uitgeeft, moet je aantonen dat je daadwerkelijk zeggenschap hebt over het domein. Dit heet Domain Control Validation (DCV) – bijvoorbeeld via een DNS-record, een bestand op je webserver of een e-mailbevestiging. Tot nu toe mag het bewijs van zo'n validatie 398 dagen hergebruikt worden voor nieuwe uitgiftes. Datzelfde ballot SC-081v3 verkort óók die hergebruiktermijn:

  • Vanaf 15 maart 2026: DCV-hergebruik maximaal 200 dagen
  • Vanaf 15 maart 2027: DCV-hergebruik maximaal 100 dagen
  • Vanaf 15 maart 2029: DCV-hergebruik maximaal 10 dagen

Dat laatste getal is veelzeggend. Met een certificaat dat 47 dagen geldig is en domeinvalidatie die nog maar 10 dagen meegaat, moet je bij praktisch elke vernieuwing opnieuw valideren. Het is technisch domweg niet vol te houden om dat met de hand te doen. Hiermee dwingt het CA/Browser Forum de facto end-to-end automatisering af – precies de bedoeling.

Meer veiligheid, maar ook meer werk

De reden achter deze wijziging is security. Kortere geldigheid betekent dat:

  • gecompromitteerde of foutief uitgegeven certificaten sneller uit roulatie zijn
  • cryptografische standaarden sneller kunnen worden vernieuwd
  • misconfiguraties minder lang een risico vormen

Het diepere argument zit in de zwakte van revocatie. In theorie kan een CA een gecompromitteerd certificaat intrekken via een Certificate Revocation List (CRL) of het Online Certificate Status Protocol (OCSP). In de praktijk werkt dat slecht: veel browsers controleren de revocatiestatus niet of doen "soft-fail" (bij twijfel toch doorlaten), zodat een ingetrokken certificaat alsnog vertrouwd wordt. OCSP voegde bovendien latency en privacyproblemen toe; Let's Encrypt is er in 2025 zelfs helemaal mee gestopt ten gunste van CRL's. Een korte levensduur is daarmee de meest betrouwbare "revocatie" die er is: een gelekt certificaat is simpelweg snel vanzelf verlopen.

Daarnaast is er crypto-agility. Naarmate we toewerken naar post-quantum cryptografie (PQC) en oudere algoritmes uitfaseren, helpt het enorm als de gehele certificaatketen zichzelf binnen weken ververst in plaats van jaren. Wie zijn vernieuwing al heeft geautomatiseerd, kan een algoritme-migratie straks grotendeels "vanzelf" laten meeliften.

Maar er is ook een duidelijke operationele impact voor bedrijven.

Wanneer certificaten korter geldig zijn, moeten ze veel vaker vernieuwd worden. Waar organisaties vroeger één keer per jaar een certificaat vervingen, kan dat straks meerdere keren per jaar zijn – en uiteindelijk zelfs maandelijks.

Voor organisaties met tientallen of honderden certificaten kan dat een flinke belasting worden voor IT-teams.

Het probleem: certificaatbeheer is vaak nog handmatig

In de praktijk zien we nog steeds dat veel organisaties hun TLS-certificaten handmatig beheren.

Dat betekent bijvoorbeeld:

  • handmatig CSR's genereren
  • handmatig aanvraagformulieren invullen bij een CA
  • handmatig installeren van certificaten op servers
  • handmatig bijhouden van vervaldatums

Met een geldigheid van een jaar was dit nog enigszins beheersbaar. Maar met certificaten van 200 dagen, 100 dagen of uiteindelijk 47 dagen wordt dit proces simpelweg niet schaalbaar.

Het bijhouden van vervaldatums is een typisch voorbeeld. Vandaag kun je de geldigheid van een certificaat nog snel met de hand opvragen, bijvoorbeeld met openssl:

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

Dat levert iets op als:

subject=CN=atcomputing.nl
notBefore=Apr 14 00:00:00 2026 GMT
notAfter=Oct 31 23:59:59 2026 GMT

Voor één domein is dit prima te doen. Maar zodra je dit voor tientallen hostnames in een spreadsheet moet bijhouden – en dat steeds vaker, omdat de marge tussen uitgifte en verloop krimpt – wordt het foutgevoelig handwerk. Een gemiste regel in een spreadsheet betekent zomaar een verlopen certificaat in productie.

⚠️ De risico's van handmatig beheer

Naarmate certificaten korter geldig zijn en het aantal vernieuwingen toeneemt, nemen ook de risico's van handmatig beheer toe. Denk aan:

  • verlopen certificaten
  • downtime van websites of API's
  • security-incidenten
  • veel operationele overhead

Automatisering wordt essentieel

De oplossing ligt in automatisering van certificaatbeheer. Met moderne tooling kunnen organisaties het volledige proces automatiseren:

  • certificaat aanvragen
  • validatie uitvoeren
  • certificaat installeren
  • renewals uitvoeren
  • certificaten distribueren naar systemen

Door certificaten onderdeel te maken van Infrastructure as Code, wordt het vernieuwen van certificaten een automatisch proces in plaats van handmatig werk. Hieronder lopen we de drie pijlers langs die je hierbij tegenkomt: ACME voor publieke certificaten, Vault voor je interne PKI en Ansible/cert-manager voor de distributie.

ACME: de standaard die korte certificaten mogelijk maakt

De motor achter geautomatiseerd certificaatbeheer is ACME (Automatic Certificate Management Environment, vastgelegd in RFC 8555). Dit protocol regelt het hele proces – domeinvalidatie, uitgifte en renewal – via een API in plaats van een webformulier. Niet toevallig pionierde Let's Encrypt al in 2015 met certificaten van slechts 90 dagen: juist díe korte levensduur dwong de hele markt om ACME te omarmen. De aankomende 47-daagse certificaten zijn in feite een voortzetting van diezelfde gedachte.

Met een ACME-client als certbot, acme.sh of lego is een renewal een kwestie van één commando, dat je vervolgens via een timer of cron periodiek laat draaien:

# vraag een certificaat aan en laat certbot de webserver-config bijwerken
certbot --nginx -d atcomputing.nl -d www.atcomputing.nl

# een renewal-check; vernieuwt alleen wat bijna verloopt
certbot renew --quiet

Webservers als Caddy hebben ACME zelfs volledig ingebouwd ("automatic HTTPS"), waardoor certificaatbeheer letterlijk geen handeling meer vereist.

HashiCorp Vault: korte certificaten voor je interne PKI

Belangrijk om te weten: de regels van het CA/Browser Forum gelden voor publiek vertrouwde certificaten. Voor interne verbindingen – denk aan service-to-service-verkeer (mTLS) binnen je eigen netwerk of cluster – ben je niet aan die termijnen gebonden. Maar de beste praktijk is dáár al langer dat certificaten extreem kort leven; soms maar enkele uren.

De PKI secrets engine van HashiCorp Vault is hiervoor gemaakt. Vault fungeert als interne CA en geeft on-demand kortlevende certificaten uit, met een TTL die je zelf bepaalt:

# een certificaat met een levensduur van 24 uur uitgeven
vault write pki/issue/internal-service \
  common_name="api.intern.atcomputing.nl" \
  ttl="24h"

Omdat zo'n certificaat na een dag vanzelf verloopt, is revocatie nauwelijks nog een zorg en blijft de aanvalsruimte bij een lek minimaal. Precies dezelfde filosofie als achter de 47-daagse publieke certificaten – alleen dan in het klein en volledig onder eigen beheer.

Distributie en orkestratie: Ansible en cert-manager

Een vernieuwd certificaat is pas waardevol als het ook op de juiste plek terechtkomt én de service ervan op de hoogte is. Met Ansible automatiseer je dat laatste stuk: het uitrollen van certificaten naar load balancers, webservers en appliances, gevolgd door een nette herstart of reload van de betreffende service. Zo wordt het distribueren van een nieuw certificaat over tien of honderd servers één idempotente playbook-run in plaats van tien keer hetzelfde handwerk.

Draai je op Kubernetes? Dan is cert-manager de de-facto standaard. Het praat zelf met een ACME-CA of met Vault, slaat het resultaat op in een Kubernetes Secret en vernieuwt certificaten automatisch ruim vóór hun vervaldatum – zonder dat een beheerder eraan te pas komt. Daarmee is de overgang naar 47-daagse certificaten op een goed ingericht cluster simpelweg een non-event.

Begin op tijd met voorbereiden

De eerste deadline – 200 dagen geldigheid in maart 2026 – komt snel dichterbij. Organisaties die nog handmatig certificaten beheren doen er goed aan om nu al na te denken over:

  • centralisatie van certificaatbeheer
  • inventarisatie van bestaande certificaten
  • implementatie van automatisering
  • integratie met CI/CD pipelines

Wat nu nog een jaarlijkse taak is, wordt straks een continu proces. En zonder automatisering wordt dat vrijwel onmogelijk om veilig te beheren.

TL;DR

De verkorting van de TLS-certificaatgeldigheid naar uiteindelijk 47 dagen – met domeinvalidatie die meekrimpt tot slechts 10 dagen – is een belangrijke securityverbetering voor het internet, vooral omdat het de zwakke revocatie-infrastructuur grotendeels overbodig maakt. Maar voor organisaties betekent het dat handmatig certificaatbeheer definitief niet langer houdbaar is. Automatisering via ACME, HashiCorp Vault, Ansible en (op Kubernetes) cert-manager is geen luxe meer maar een randvoorwaarde. Het goede nieuws: wie die basis nu op orde brengt, heeft straks van een continu proces geen omkijken meer – en is meteen klaar voor de volgende stap, zoals een post-quantum migratie.

Aan de slag met automatisering?

Wil je certificaatbeheer en infrastructuur reproduceerbaar en schaalbaar maken? Dan zijn deze twee cursussen een logische eerste stap. Met Ansible automatiseer je configuratiebeheer, deployments en de distributie van certificaten over je hele omgeving:

Ansible Fundamentals
https://www.vijfhart.nl/opleidingen/ansible-fundamentals/

Met HashiCorp Vault regel je secrets management én de uitgifte en renewal van certificaten centraal en geautomatiseerd:

Vault Fundamentals
https://www.vijfhart.nl/opleidingen/vault-fundamentals/

$ blog-details

  • $ categorie: Security & Automatisering
  • $ tools: TLS, ACME, certbot, OpenSSL, HashiCorp Vault, Ansible, cert-manager
  • $ date: 2026-06-17T12:00:00 CEST
  • $ cursussen:
    Ansible Fundamentals
    Vault Fundamentals

Dit vind je wellicht ook interessant...