Waarom de wijzigingen van Let's Encrypt op 13 mei belangrijk zijn

Op 13 mei 2026 voerde Let's Encrypt drie productiewijzigingen tegelijk door: het opt-in tlsserver-profiel begon met het uitgeven van certificaten met een geldigheidsduur van 45 dagen, het tlsclient-profiel werd geleidelijk afgebouwd in aanloop naar de deadline van 8 juli 2026, en het standaardprofiel schakelde over op Generation Y-tussenliggende certificaten, vijf dagen na een uitgiftestop van tweeënhalf uur.

Afzonderlijk is elke wijziging beheersbaar. Gezamenlijk, en met name in de context van het incident met de uitgifte dat vijf dagen eerder plaatsvond, geven ze een duidelijke boodschap aan iedereen die verantwoordelijk is voor certificaten: het tijdperk waarin certificaatbeheer als incidenteel papierwerk werd beschouwd, loopt ten einde. Certificaatbeheer wordt infrastructuur en de organisaties die deze verschuiving niet hebben gemaakt, zullen elke toekomstige wijziging als een hectische aangelegenheid ervaren.

Deze blog legt uit wat er veranderd is, waarom een ​​korte storing een paar dagen eerder belangrijker is dan de korte duur doet vermoeden, en wat deze gebeurtenissen ons vertellen over de richting waarin certificaatbeheer zich in de hele branche ontwikkelt.

Key Takeaways

• Op 13 mei 2026 is het tlsserver-profiel van Let's Encrypt teruggegaan naar certificaten met een geldigheidsduur van 45 dagen, is het tlsclient-profiel afgebouwd tot 8 juli 2026, en is het standaardprofiel overgestapt op Generation Y-tussenliggende certificaten.
• Deze wijzigingen volgden op een uitgiftestop op 8 mei 2026, veroorzaakt door ontbrekende velden voor uitgebreid sleutelgebruik op nieuw uitgegeven, onderling ondertekende tussenproducten. Dit probleem werd in ongeveer tweeënhalf uur opgelost met behulp van ACME Renewal Information (ARI).
• Het CA/Browser Forum-voorstel SC-081v3 wijzigt de maximale geldigheidsduur van openbare TLS-certificaten van 200 dagen (maart 2026) naar 100 dagen (maart 2027) naar 47 dagen (maart 2029), waardoor het profiel van 45 dagen van Let's Encrypt een voorproefje is en geen uitzondering.
• Uit de Trust Pulse Survey van DigiCert bleek dat 45% van de organisaties het afgelopen jaar te maken heeft gehad met uitval als gevolg van certificaatproblemen, en dat 37.5% de oorzaak van een storing specifiek kon herleiden tot een verlopen certificaat.
• De PKI-, beveiligings-, platform- en compliance-teams hebben elk een eigen actiepunt vóór de stopzetting van tlsclient op 8 juli 2026; de onderstaande matrix met verantwoordelijkheden en acties en de bijbehorende tijdlijn geven precies aan wat en wie verantwoordelijk is.

Ga naar: Samenvatting | Checklist voor paraatheid | Het incident van 8 mei | De drie veranderingen | Tijdlijn | Verantwoordelijkheids-/actiematrix | Wat te doen? | Veelgestelde vragen

Samenvatting voor de teams PKI, Beveiliging, Platform en Compliance

Als u een van deze functies leidt, vindt u hier de beslissing die in dit artikel wordt ondersteund en de bijbehorende beknopte actiehandleiding.

• PKI-teams: Bevestig dat de vastgezette root- en tussenliggende lijsten de huidige Generation Y-keten bevatten en test de automatische verlenging grondig aan de hand van het optionele tlsserver-profiel van 45 dagen voordat een kortere geldigheidsduur branchebreed verplicht wordt.
• Beveiligingsteams: Ontdek alle certificaten die gebruikmaken van het tlsclient (clientauthenticatie) Extended Key Usage vóór de deadline van 8 juli 2026 en plan de migratie naar een private PKI of commerciële CA.
• Platform-/DevSecOps-teams: Vervang de verlengingstriggers met een vast aantal dagen door ARI-gestuurde logica of logica gebaseerd op een fractie van de levensduur, zodat een certificaat van 45 dagen niet verloopt zonder te worden verlengd.
• Nalevingsteams: Bevestig dat de verificatie van de certificaatketen en de bewaking van de vervaldatum continu plaatsvinden en niet als een eenmalige instelstap, en documenteer hoe wijzigingen in de root en het profiel door het beleid worden verwerkt.

Snelle gereedheidschecklist

Gebruik deze checklist om te beoordelen hoe goed uw certificaatverwerking is voorbereid op de gebeurtenissen van 8 en 13 mei 2026, en op de kortere geldigheidsperioden die nog voor de deur staan.

• Controleer of uw ACME-klant ACME Renewal Information (ARI) ondersteunt voor CA-gestuurde verlengingstermijnen.
• De geverifieerde verlengingscriteria zijn gebaseerd op een fractie van de geldigheidsduur van het certificaat, en niet op een vast aantal dagen dat uitgaat van een certificaat met een geldigheidsduur van 90 dagen.
• Voer certificaatdetectie uit die kan filteren op uitgebreid sleutelgebruik om alle certificaten te vinden die tlsclient-authenticatie gebruiken.
• Er is een migratiepad vastgesteld, ofwel een private PKI of een commerciële CA, voor alle clientauthenticatiecertificaten die vóór 8 juli 2026 zijn gevonden.
• Bevestigde, vastgezette wortels of tussenliggende schakels in uw eigen infrastructuur omvatten de huidige keten van Generatie Y.
• De automatische verlenging is getest met een certificaatlevensduur van 45 dagen, niet alleen met een levensduur van 90 dagen.

Een korte samenvatting: Het incident van 8 mei

Vijf dagen voor de geplande wijzigingen stopte Let's Encrypt met het uitgeven van alle certificaten. De pauze duurde ongeveer tweeënhalf uur voordat de uitgifte werd hervat. De oorzaak bleek een configuratieprobleem te zijn in nieuw uitgegeven, kruisondertekende tussenliggende certificaten: de vereiste velden voor uitgebreid sleutelgebruik ontbraken. De oplossing was om de betreffende tussenliggende certificaten in te trekken en opnieuw uit te geven met de correcte velden. Belangrijk is dat er geen eindgebruikerscertificaten, de certificaten die op servers zijn geïmplementeerd, werden ingetrokken, omdat deze zelfstandig aan de vereisten bleven voldoen.

Om de resulterende golf van verlengingen soepel af te handelen, maakte Let's Encrypt gebruik van ACME Renewal Information (ARI), een protocoluitbreiding waarmee een certificeringsinstantie ACME -clients kan laten weten wanneer ze moeten verlengen. In plaats van dat alle betrokken clients tegelijkertijd verlengden en het systeem overbelastten, spreidde ARI de verlengingen over een gecontroleerd tijdsvenster. Voor clients die ARI ondersteunen, werd de gecorrigeerde keten automatisch opgepakt bij de volgende geplande uitvoering, zonder dat handmatige tussenkomst nodig was.

Het incident werd netjes opgelost, maar het leverde een waardevolle les op: certificaatketenverificatie is niet langer een eenmalige insteltaak. Rootcertificaten veranderen, kruisondertekening wordt hersteld en vertrouwensarchieven worden volgens hun eigen schema bijgewerkt. Het controleren of uw certificaatketen correct is, moet een continu, gelogd onderdeel van uw vernieuwingsproces zijn, en geen controle die jaren geleden in een implementatiehandleiding is opgenomen.

De drie veranderingen op 13 mei

1. Het tlsserver-profiel is teruggezet naar certificaten met een geldigheidsduur van 45 dagen.

Het opt-in tlsserver-profiel begon met het uitgeven van certificaten met een geldigheidsduur van slechts 45 dagen. Dit profiel is bedoeld voor early adopters die hun automatisering willen testen met een korte vernieuwingstermijn voordat dit onvermijdelijk wordt. Het is de voorhoede van een veel grotere trend in de branche naar TLS-certificaten met een geldigheidsduur van 47 dagen , waardoor het een nuttig testterrein is. Als uw automatisering vandaag de dag een certificaat van 45 dagen aankan , zal het ook de komende ontwikkeling voor iedereen aankunnen.

Het operationele probleem is subtiel maar ernstig. Veel ACME-clients zijn geconfigureerd om een ​​vast aantal dagen voor de vervaldatum te verlengen, vaak 30 dagen. Voor een certificaat met een geldigheidsduur van 90 dagen is verlenging 30 dagen voor de vervaldatum prima, omdat dit ongeveer twee derde van de levensduur van het certificaat betreft. Deze termijn van 90 dagen loopt echter al achter op het schema van de CA/Browser Forum, dat de geldigheidsduur van publieke TLS-certificaten vanaf maart 2026 beperkt tot 200 dagen en deze termijn verder verkort. Dit moet dus als verouderd worden beschouwd, niet als actueel. Voor een certificaat met een geldigheidsduur van 45 dagen zou dezelfde vaste instelling een verlenging proberen na slechts 15 dagen in gebruik, wat door automatisering als een fout kan worden geïnterpreteerd en overgeslagen, soms zonder dat dit gebeurt. Het certificaat verloopt dan zonder verlenging. De juiste aanpak is een verlengingslogica gebaseerd op een fractie van de levensduur van het certificaat, of beter nog, gestuurd door de ARI (Application Information Reference) zodat de CA zelf het juiste verlengingsvenster aangeeft.

2. Het tlsclient-profiel is begonnen met afsluiten.

Het tlsclient-profiel, dat werd gebruikt om certificaten uit te geven voor TLS-clientauthenticatie, werd op 13 mei geblokkeerd. Bestaande accounts die het profiel al gebruikten, konden het tijdelijk blijven gebruiken, maar nieuwe accounts kregen geen toegang meer. Er werd een harde deadline vastgesteld voor 8 juli 2026, waarna het profiel volledig verdwijnt.

Deze wijziging is geen eigenaardigheid van Let's Encrypt. Het komt voort uit een bredere, fundamentele programmavereiste, ingegeven door grote leveranciers van browsers en besturingssystemen, die voorschrijft dat TLS- clientauthenticatie en TLS-serverauthenticatie gescheiden moeten worden in afzonderlijke publieke sleutelinfrastructuren. De praktische consequentie is aanzienlijk: elk systeem dat afhankelijk was van een Let's Encrypt-certificaat voor de authenticatie van een client bij een server, zoals interne wederzijdse TLS, bepaalde XMPP-services of applicaties die beveiligd zijn met clientauthenticatie, zal niet meer werken zodra het profiel is verwijderd.

Het lastige is zelden de migratie zelf. Het is vooral het vinden van de locatie van deze certificaten. Clientauthenticatiecertificaten worden vaak door individuele applicatieteams ingezet voor specifieke integraties en duiken nooit op in centrale PKI- inventarissen. Om ze te vinden is certificaatdetectie nodig die kan filteren op Extended Key Usage, waardoor certificaten worden weergegeven op basis van hun daadwerkelijke configuratie in plaats van hun hostnaam, in cloud-, on-premises- en containeromgevingen. Eenmaal gevonden, migreren interne use cases doorgaans naar een private PKI, terwijl externe cases die daadwerkelijk clientauthenticatie vereisen, overstappen naar een commerciële CA. Onze handleiding voor het bouwen van een private PKI voor mTLS beschrijft dit migratiepad in detail.

3. Het klassieke profiel is verschoven naar de tussenliggende generatie Y.

Het standaard klassieke ACME-profiel, dat door de meeste Let's Encrypt-abonnees zonder expliciete configuratie wordt gebruikt, is overgegaan op de nieuwe Generation Y-tussenliggende certificaten. Voor de meeste geautomatiseerde configuraties is deze overgang transparant, maar het bevestigt de les van het incident van 8 mei: vertrouwensketens veranderen onder je voeten, en de enige veilige aanname is dat dit zo zal blijven. Organisaties die specifieke root- of tussenliggende certificaten in hun eigen infrastructuur hebben vastgelegd, moeten controleren of hun cross-signed tussenliggende certificaten actueel zijn, anders lopen ze het risico op validatiefouten in de keten die moeilijk te diagnosticeren zijn.

Tijdschema: ingangsdata, vereisten en bronnen

Gebruik deze tabel als referentie voor wat er precies is veranderd, wanneer het is ingegaan, wie erdoor wordt getroffen en wat u eraan kunt doen, met verwijzing naar de oorspronkelijke beleidsbron.

Ingangsdatum	Vereiste / Wijziging	Wie wordt hierdoor getroffen?	Actie nodig	Bron
May 8, 2026	Let's Encrypt heeft de uitgifte ongeveer 2.5 uur stilgelegd nadat er ontbrekende velden voor uitgebreid sleutelgebruik werden aangetroffen in nieuw uitgegeven, onderling ondertekende tussenliggende certificaten.	Alle Let's Encrypt-abonnees die afhankelijk zijn van de getroffen tussenliggende servers.	Bevestig dat ARI-gebaseerde clients de gecorrigeerde keten automatisch hebben overgenomen; verifieer dat de ketenvalidatie continu wordt uitgevoerd.	Let's Encrypt-incident openbaar gemaakt
May 13, 2026	Het opt-in tlsserver-profiel begint met het uitgeven van certificaten met een geldigheidsduur van 45 dagen.	Pioniers testen automatisering grondig voordat de sectorbrede verschuiving plaatsvindt.	Vervang vaste verlengingstriggers van 30 dagen door logica gebaseerd op een levensduurfractie of ARI (Annual Retirement Incentive).	Let's Encrypt-profieldocumentatie
13 mei 2026 (bevroren); 8 juli 2026 (gesloten)	Het tlsclient-profiel is bevroren voor nieuwe accounts en vervolgens volledig uitgeschakeld voor alle accounts.	Systemen die Let's Encrypt-certificaten gebruiken voor interne mTLS-, XMPP- of client-authenticatie-beveiligde applicaties.	Ontdek nu client-authenticatie-EKU-certificaten en migreer vóór 8 juli 2026 naar een private PKI of commerciële CA.	Vereiste scheiding tussen clientAuth en serverAuth in het rootprogramma
May 13, 2026	Standaard klassiek profiel schakelt over naar tussenliggende generatie Y-profielen	De meerderheid van de Let's Encrypt-abonnees, met name degenen die specifieke root- of tussenliggende certificaten vastzetten,	Controleer of de vastgezette root-/tussenlijsten de huidige Generation Y-keten bevatten.	Tussentijdse aankondiging van Let's Encrypt Generatie Y
15 maart 2026 → 15 maart 2027 → 15 maart 2029	De maximale geldigheidsduur van openbare TLS-certificaten is geleidelijk verlengd van 200 dagen naar 100 dagen en vervolgens naar 47 dagen.	Alle houders van openbare TLS-certificaten, veel meer dan het aantal abonnees van Let's Encrypt.	Stap af van de verouderde verlengingstermijnen van 90 dagen of langer en ga over op continu, geautomatiseerd lifecyclemanagement.	CA/Browser Forum Ballot SC-081v3; Sectigo, analyse van 14 april 2025

Deze ingangsdata worden ondersteund door gegevens over wat er gebeurt wanneer deze discipline wordt overgeslagen. Uit DigiCert's Trust Pulse Survey, gepubliceerd op 2 juli 2025, bleek dat 45% van de organisaties het afgelopen jaar te maken heeft gehad met downtime als gevolg van certificaatproblemen, en dat 37.5% een storing specifiek kon herleiden tot een verlopen certificaat . Dezelfde factoren liggen ten grondslag aan de bovenstaande profielwijzigingen: het voorstel SC-081v3 van het CA/Browser Forum, bevestigd door de analyse van Sectigo van 14 april 2025 , verlaagt de maximale geldigheidsduur van openbare TLS-certificaten naar 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029. Het optionele tlsserver-profiel van Let's Encrypt met een geldigheidsduur van 45 dagen is daarmee een voorproefje van de richting die elke openbare CA opgaat, en geen geïsoleerde beleidskeuze.

Het grotere plaatje: een sectorbrede verschuiving, geen evenement voor individuele leveranciers.

Het zou een vergissing zijn om deze wijzigingen te interpreteren als Let's Encrypt-specifieke aanpassingen. Ze geven een voorproefje van de richting waarin het gehele ecosysteem van openbare certificaten zich ontwikkelt. Het CA/Browser Forum heeft de geldigheidsduur van openbare TLS-certificaten vastgesteld op 47 dagen in 2029, met tussentijdse verkortingen. Browser-rootprogramma's stellen steeds strengere eisen aan het gebruik van certificaten. Intrekking verschuift van oudere mechanismen naar kortere levensduur, waardoor intrekking vrijwel overbodig wordt, aangezien een certificaat dat slechts enkele dagen of weken geldig is, in feite vanzelf verloopt.

Elke certificeringsinstantie ondergaat haar eigen versie van rootmigraties, profielwijzigingen en levensduurverkortingen. De volgende is altijd al ergens in gang gezet. Dit is de context die de wijzigingen van 13 mei belangrijk maakt, ver buiten de gebruikersgroep van Let's Encrypt.

De diepere vraag die deze gebeurtenissen oproepen, gaat over hoe een organisatie is ingericht om ze op te vangen. Teams die certificaatbeheer als infrastructuur beschouwen, behandelen elke wijziging als een configuratie-update, omdat hun verlengingen volledig geautomatiseerd zijn via certificaatautomatisering , hun inventaris realtime is en werkt met elke certificeringsinstantie die ze gebruiken, en hun crypto-flexibiliteit een ingebouwde eigenschap van hun platform is in plaats van een nevenproject. Teams die certificaten als papierwerk beschouwen, werken met spreadsheets, ticketwachtrijen en verouderde draaiboeken, en voor hen wordt elke CA-wijziging een wekenlange hectiek die met geen enkele hoeveelheid overuren te verkorten is.

De steeds korter wordende geldigheidsperiode is precies waar dit probleem zich verergert. Een verlengingsproces dat is ontworpen voor certificaten met een geldigheidsduur van 90 dagen, overleeft geen periode van 45 dagen, en de tijd die beschikbaar is om het te herzien is korter dan de deadline zelf. Organisaties die nu investeren in automatisering lossen niet alleen het probleem van vandaag op. Ze bouwen aan de capaciteit die hen door de kortere levensduur van certificaten in de toekomst en de daaropvolgende post-kwantummigratie heen zal helpen.

Eigenaar- en actiematrix per team

Team	Verantwoordelijkheid	Belangrijkste actie
PKI-team	Bezit de hoofdvaluta en de tussenliggende ketenvaluta.	Controleer of de vastgelegde wortels/tussenproducten de Generation Y-keten omvatten en modelleer het vernieuwingsvolume ten opzichte van het 45-dagenprofiel.
Beveiligingsteam	Verantwoordelijk voor het opsporen en migreren van authenticatiecertificaten van klanten.	Voer EKU-gebaseerde ontdekking uit in cloud-, on-premises- en containeromgevingen vóór 8 juli 2026.
Platform-/DevSecOps-team	Beschikt over geautomatiseerde, levenslange verlengingslogica.	Vervang verlengingstriggers met een vast aantal dagen door ARI-gestuurde of levenslange automatisering.
Complianceteam	Beschikt over bewijsmateriaal voor continue keten- en vervaldatumbewaking.	Bevestig dat de ketenverificatie en de vervaldatumbewaking continu worden geregistreerd en niet slechts eenmalig bij de implementatie worden gecontroleerd.

Wat te doen Volgende

• PKI-teams: Bevestig dat elke vastgezette root- en tussenliggende lijst voor de Generation Y-keten dit kwartaal is bijgewerkt.
• Beveiligingsteams: Zorg voor een volledige inventarisatie van tlsclient-/clientauthenticatiecertificaten en begin onmiddellijk met de migratieplanning, ruim vóór de sluiting op 8 juli 2026.
• Platformteams: Test de logica voor verlenging op basis van levenslange looptijd of ARI (Average Annual Interest) ten opzichte van het optionele 45-dagen tlsserver-profiel voordat dit de industriestandaard wordt.
• Nalevingsteams: Documenteer dat de ketenverificatie en de vervaldatumbewaking continu worden uitgevoerd, zodat het volgende CA-incident bewijs levert van een goed functionerende controle in plaats van een hiaat.

Hoe encryptieconsultancy kan helpen

De les van 13 mei is dat certificaatoperaties moeten functioneren als een veerkrachtige infrastructuur. Encryption Consulting levert de producten en expertise om precies dat te realiseren.

CertSecure Manager is onze oplossing voor certificaatlevenscyclusbeheer, speciaal ontworpen voor de wereld die deze veranderingen kenmerken. Het biedt continue, CA-onafhankelijke detectie in cloud-, on-premises- en Kubernetes-omgevingen, zodat u elk certificaat dat u bezit kunt vinden, inclusief de clientauthenticatiecertificaten die applicatieteams buiten de centrale PKI hebben geïmplementeerd en die niet in spreadsheets worden geregistreerd.

De volledig geautomatiseerde uitgifte, verlenging en intrekking van certificaten is ontworpen om certificaten met een korte geldigheidsduur en een hoge verlengingsfrequentie te verwerken, zonder de valkuilen van vaste intervallen die tot stille storingen leiden. Dankzij de gecentraliseerde beleidshandhaving en realtime inventarisatie wordt een root-migratie of profielwijziging een configuratie-update in plaats van een noodsituatie. Door ketenverificatie en vervalbewaking continu in plaats van eenmalig uit te voeren, maakt CertSecure Manager van de gebeurtenissen van 8 en 13 mei een non-event.

Om het overzicht over uw gehele cryptografische omgeving te vergroten, detecteert en inventariseert CBOM Secure de algoritmen, sleutels en protocollen in uw omgeving. Dit levert u een cryptografische materiaallijst op die zowel compliance als paraatheid voor de post-quantum transitie ondersteunt, die volgt op de overstap naar kortere levensduur van certificaten. Onze CBOM: van inventaris tot intelligentie- handleiding beschrijft hoe u deze inventaris kunt omzetten in een doorlopend programma voor cryptografische flexibiliteit. Ons PQC Center of Excellence en de 9-fasen PQC-gereedheidsroadmap helpen u bij het plannen van de post-quantum transitie die volgt op dit tijdperk van steeds kortere certificaatlevensduren.

Op het gebied van advies helpt ons PKI Services- team bij het ontwerpen en moderniseren van de PKI-omgevingen van bedrijven en Microsoft. Deze omgevingen moeten steeds vaker taken overnemen waar openbare certificeringsinstanties zich van terugtrekken, zoals de clientauthenticatiecertificaten die door deze veranderingen worden beïnvloed. Onze adviesdiensten op het gebied van encryptie helpen u bij het opzetten van een robuuste, op automatisering gerichte certificaatstrategie, en onze adviesdiensten op het gebied van compliance zorgen ervoor dat die strategie aansluit op de veranderende wettelijke en browserprogrammavereisten.

Of u nu haastig uw clientauthenticatiecertificaten inventariseert vóór de deadline in juli, of juist werkt aan een automatiseringssysteem voor de lange termijn dat de volgende reeks wijzigingen tot een routineklus maakt, Encryption Consulting kan u helpen. Neem contact met ons op om uw certificaatprocessen te laten beoordelen en u voor te bereiden op de toekomst.

Gerelateerde artikelen van Encryption Consulting

• Betere beveiliging met TLS-certificaten met een geldigheidsduur van 47 dagen vanaf 2029. Dit omvat het volledige validatietraject van CA/Browser Forum dat Let's Encrypt in het 45-dagenprofiel laat zien.
• Bouw een private PKI voor mTLS voordat publieke certificaten de clientAuth-functionaliteit laten vervallen. Dit document beschrijft precies het migratiepad dat teams nodig hebben vóór de sluiting van het tlsclient-profiel op 8 juli 2026.
• Wijzigingen in clientauthenticatiecertificaten: Chrome's mTLS-verschuiving in 2026 Dit beschrijft de vereiste voor het rootprogramma van de browser die de afsluiting van het tlsclient-profiel veroorzaakt.
• Certificaattransparantiemonitoring in het tijdperk van statische CT-scans Dit omvat de monitoringdiscipline die samengaat met continue ketenverificatie.

Conclusie

De wijzigingen die Let's Encrypt op 13 mei doorvoerde, en de korte storing die daaraan voorafging, zijn op zichzelf klein. Hun werkelijke betekenis schuilt echter in hun signaalwerking. De levensduur van certificaten wordt in de hele sector korter, vertrouwensketens veranderen vaker en de regels voor het gebruik van certificaten worden steeds strenger. En deze ontwikkelingen zullen niet afnemen.

De organisaties die deze veranderingen soepel doorstaan, zijn niet de organisaties die het hardst werken telkens wanneer een CA een wijziging aankondigt. Het zijn de organisaties die zijn gestopt met het behandelen van certificaten als papierwerk en hun certificaatprocessen hebben opgezet als een geautomatiseerde, observeerbare, CA-onafhankelijke infrastructuur. Die basis absorbeert een cyclus van 45 dagen, het uitfaseren van profielen en een rootmigratie als routinegebeurtenissen, en het is dezelfde basis die een organisatie door de post-quantum transitie zal loodsen die nog in het verschiet ligt.

De volgende wijziging is alweer onderweg, afkomstig van Let's Encrypt of een andere partij binnen het ecosysteem. De enige vraag is of uw certificaatbeheer klaar is om dit als een configuratie-update te beschouwen, of dat het als een nieuwe noodsituatie moet worden gezien.

Omdat dit bericht de uitrol van het beleid van een specifieke leverancier volgt, wordt het elk kwartaal herzien en onmiddellijk wanneer het CA/Browser Forum, een browserhoofdprogramma of Let's Encrypt zelf een nieuwe wijziging aankondigt.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit het artikel 'Waarom zijn de wijzigingen van Let's Encrypt op 13 mei belangrijk?'

De profielwijzigingen van Let's Encrypt op 13 mei 2026, na het incident met de uitgifte van certificaten op 8 mei, laten zien dat het beheer van de levenscyclus van certificaten verschuift van incidenteel onderhoud naar een continue, geautomatiseerde infrastructuur. Organisaties die nog steeds werken met vernieuwingen op vaste intervallen en spreadsheets, zullen elke toekomstige CA-wijziging als een noodsituatie ervaren, terwijl organisaties met ARI-gestuurde automatisering die rekening houdt met de levensduur van certificaten, dezelfde wijziging als routineconfiguratie zullen beschouwen.

Waarom is dit belangrijk voor het beheer van de levenscyclus van bedrijfscertificaten?

Uit de Trust Pulse Survey van DigiCert bleek dat 45% van de organisaties het afgelopen jaar te maken heeft gehad met uitval als gevolg van certificaatproblemen, en dat 37.5% een storing specifiek kon herleiden tot een verlopen certificaat. Het CA/Browser Forum heeft een schema opgesteld waarin de maximale geldigheidsduur van publieke TLS-certificaten wordt teruggebracht tot 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029. Het optionele tlsserver-profiel van Let's Encrypt met een geldigheidsduur van 45 dagen is het meest toonaangevende bewijs in de branche dat dit schema sneller wordt ingevoerd dan veel vernieuwingsprocessen zijn ontworpen.

Welke teams zijn verantwoordelijk voor de uitvoering van deze richtlijnen?

PKI-teams beheren de root- en intermediate-chainvaluta; beveiligingsteams beheren de detectie en migratie van clientauthenticatiecertificaten; platform- en DevSecOps-teams beheren de geautomatiseerde, levensduurgerichte vernieuwingslogica; en compliance-teams beheren het bewijsmateriaal voor continue keten- en vervalmonitoring. De bovenstaande matrix met verantwoordelijkheden en acties geeft een overzicht per team.

Welke risico's nemen toe als dit onderwerp handmatig wordt behandeld?

Handmatige afhandeling hiervan betekent dat de vernieuwingslogica met een vast aantal dagen stilzwijgend faalt bij kortdurende certificaten, omdat een trigger die na 30 dagen wordt geactiveerd voor een certificaat van 45 dagen, probeert te vernieuwen na slechts 15 dagen in gebruik en dit als een fout kan worden beschouwd. Het betekent ook dat clientauthenticatiecertificaten verborgen blijven buiten de centrale inventaris, dat vastgezette rootcertificaten stilzwijgend niet meer werken wanneer een CA migreert naar een nieuwe tussenliggende CA, en dat de deadline van 8 juli 2026 voor tlsclient volledig wordt gemist.

Hoe vermindert automatisering het risico op certificaatuitval?

Automatisering maakt een einde aan de aanname van vaste intervallen, die niet meer werkt bij kortstondige certificaten. Vernieuwing wordt namelijk geactiveerd op basis van ACME Renewal Information (ARI) of een fractie van de levensduur van het certificaat, in plaats van een vast aantal dagen. In combinatie met continue, CA-onafhankelijke detectie en continue ketenvalidatie, wordt een rootmigratie, het vervallen van een profiel of een uitgifteprobleem omgezet in een configuratie-update in plaats van een storing.

Welke statistieken moeten teams bijhouden na de implementatie?

Houd het percentage certificaten bij dat gebruikmaakt van ARI-gestuurde of levenslange vernieuwingslogica, het aantal tlsclient/client-authenticatiecertificaten dat vóór 8 juli 2026 is ontdekt en gemigreerd, ketenvalidatiefouten die vóór de vervaldatum zijn geconstateerd in plaats van erna, en alle incidenten die verband houden met een profiel-, root- of tussenliggende wijziging. Rapporteer deze gegevens elk kwartaal naarmate het geldigheidsschema van het CA/Browser Forum vordert.

Hoe hangt dit samen met de 47-daagse TLS-certificaatgereedheid?

Het 45-daagse tlsserver-profiel van Let's Encrypt, waarvoor je je kunt aanmelden, is expliciet bedoeld als testomgeving voor automatisering in aanloop naar het verplichte schema van de CA/Browser Forum, dat de geldigheidsduur van publieke TLS beperkt tot 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029. Automatisering die het huidige 45-dagenprofiel overleeft, zal ook de verplichte limiet van 47 dagen voor alle anderen later overleven.

Hoe moet dit worden aangepakt in multi-cloud- of hybride PKI-omgevingen?

Standaardiseer op CA-onafhankelijke certificaatdetectie en -automatisering die identiek werkt in cloud-, on-premises- en Kubernetes-omgevingen, zodat een Let's Encrypt-profielwijziging, een rootmigratie of een hybride PKI-implementatie allemaal via hetzelfde beleid, dezelfde vernieuwingslogica en hetzelfde auditspoor verlopen, in plaats van dat er per omgeving een aparte afhandeling nodig is.