PKI in 2026: Hoe overleef je het tijdperk van het 47-daagse TLS-certificaat?

Het tijdperk van TLS-certificaten met een geldigheidsduur van 47 dagen is de gefaseerde verlaging van de maximale geldigheidsduur van openbare TLS-certificaten door het CA/Browser Forum, goedgekeurd als Ballot SC-081v3 op 11 april 2025. De limiet wordt verlaagd van 398 dagen naar 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029, waardoor certificaatvernieuwing verandert van een jaarlijkse taak naar een continue, geautomatiseerde taak. Gedurende het grootste deel van het afgelopen decennium was een openbaar TLS-certificaat iets dat je eenmalig instelde en waar je vervolgens een jaar of langer nauwelijks meer naar omkeek. Dat verandert snel. Het CA/Browser Forum heeft Ballot SC-081v3 goedgekeurd , een vast schema dat de maximale geldigheidsduur van een openbaar TLS-certificaat verkort van 398 dagen naar 47 dagen in 2029. De eerste verkorting is al van kracht: sinds 15 maart 2026 mag geen enkele openbare certificeringsinstantie (CA) een certificaat uitgeven dat langer dan 200 dagen geldig is.

Voor beveiligingsteams, PKI-engineers, CISO's, cloudarchitecten en DevSecOps-groepen is dit geen kleine beleidswijziging. Het transformeert certificaatlevenscyclusbeheer van een jaarlijkse taak naar een constante, geautomatiseerde taak. In deze blog bekijken we wat er is veranderd en waarom, waar uw certificaten zich daadwerkelijk bevinden, hoe de automatisering werkt en hoe dit alles samenhangt met de grotere verschuiving naar post-kwantumcryptografie.

Ga direct naar: Samenvatting | Snelle checklist | Actiematrix voor eigenaren | Beleidsbronnen | Wat te doen?

Samenvatting

Het voorstel SC-081v3 van het CA/Browser Forum, goedgekeurd op 11 april 2025, verkort de maximale geldigheidsduur van openbare TLS-certificaten van 398 dagen naar 200 dagen (van kracht vanaf 15 maart 2026, reeds van toepassing), 100 dagen (15 maart 2027) en 47 dagen (15 maart 2029). Het hergebruik van Domain Control Validation-certificaten wordt volgens hetzelfde schema teruggebracht tot slechts 10 dagen. 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 37.5% kon een storing herleiden tot een verlopen certificaat. De operationele risico's zijn dus al reëel voordat de kortste geldigheidsperioden zelfs maar verstrijken. Deze handleiding beschrijft de exacte data, de wijzigingen bij elke datum, wie erdoor wordt beïnvloed, een checklist voor gereedheid, een verantwoordelijkheids- en actiematrix voor PKI-, beveiligings-, platform- en compliance-teams, en een migratieplan om de kloof te dichten voordat handmatige certificaatregistratie wiskundig onmogelijk wordt.

Snelle checklist voor paraatheid in 47 dagen

Gebruik deze checklist om te bepalen hoe dicht uw organisatie bij de gereedheid voor een TLS-certificaat binnen 47 dagen is.

• Zorg ervoor dat u beschikt over één uniforme, continu bijgewerkte inventaris voor certificaatdetectie in on-premise, cloud- en hybride omgevingen.
• Controleer of voor elk certificaat een geregistreerde, verantwoordelijke eigenaar staat vermeld.
• Zorg ervoor dat de verlenging, uitgifte en intrekking van certificaten geautomatiseerd verlopen in plaats van handmatig te worden bijgehouden.
• Zorg ervoor dat uw ACME-klant ARI-compatibel is en vaker dan één keer per week controleert op verlengingsperiodes.
• Controleer of de DNSSEC- en CAA-records in orde zijn, aangezien SC-085v2 de automatische uitgifte kan blokkeren als dit niet het geval is.

Eigenaar- en actiematrix per team

Om de gereedheidskloof van 47 dagen te dichten, is duidelijke verantwoordelijkheid binnen vier teams essentieel. Hieronder wordt beschreven hoe de PKI-, beveiligings-, platform- en compliance-teams de verantwoordelijkheid zouden moeten verdelen.

Team	Primaire verantwoordelijkheid	Belangrijkste actie
PKI-team	Eigen beleid voor de uitgifte van certificaten en relaties met certificeringsinstanties	Test de ACME-automatisering nu en bevestig de failover naar een tweede CA vóór 2029.
Beveiligingsteam	Eigen sleutelbescherming en cryptografisch risico	Vereis HSM-ondersteunde sleutelgeneratie voor elke verlenging en controleer Certificate Transparency-logboeken op uitgiften die niet aan het beleid voldoen.
Platform- en DevOps-team	Eigen geautomatiseerde verlenging en implementatie	Verbind ARI-compatibele ACME-clients met loadbalancers, Kubernetes en CI/CD-pipelines.
Nalevingsteam	Eigen controlebewijs voor het certificatenbestand	Houd de automatiseringsdekking, de volledigheid van de inventaris en de naleving van het beleid bij voor auditors.

Bronnen van het beleid en ingangsdata

Elke deadline in deze handleiding is gebaseerd op een primaire beleidsbron, niet op een secundaire samenvatting. Het eigen stemverslag van het CA/Browser Forum is de gezaghebbende bron voor het schema van 47 dagen voor TLS-certificaten: Stemverslag SC-081v3 werd goedgekeurd op 11 april 2025 en is gepubliceerd op cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods . Een secundaire branchesamenvatting van hetzelfde schema is beschikbaar via Sectigo op sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days . De gerelateerde DNSSEC-validatievereiste is Stemverslag SC-085v2, dat op dezelfde datum als de overgang naar 200 dagen van kracht werd.

Updatelogboek: Oorspronkelijk gepubliceerd in mei 2026; meest recent bijgewerkt met statistieken over downtime, een uitgebreidere tijdlijn, een matrix met eigenaren en acties, een FAQ-blok en schema-opmaak, en om elke datum te bevestigen aan de hand van het primaire stemverslag van het CA/Browser Forum in plaats van een secundaire samenvatting. Dit bericht wordt elk kwartaal, of direct na elke nieuwe wijziging van het CA/Browser Forum, het browserrootprogramma of een product van Encryption Consulting die van invloed is op de geldigheid van certificaten, gecontroleerd aan de hand van het openbare stemverslag van het CA/Browser Forum.

Wat verandert er in 2026?

Ingangsdatum	eis	Wie wordt hierdoor getroffen?	Actie nodig	Bron
Tot 14 maart 2026	Maximale geldigheidsduur en hergebruik van DCV: 398 dagen	Alle houders van openbare TLS-certificaten	Basislijn; geen actie vereist naast standaard verlenging.	CA/Browser Forum Stembiljet SC-081v3
15 maart 2026 (van kracht)	Maximale geldigheidsduur en hergebruik van DCV beperkt tot 200 dagen.	Alle houders van openbare TLS-certificaten; OV/EV-houders zien ook dat de periode voor hergebruik van Subject Identity Information wordt verkort van 825 naar 398 dagen.	Bevestig dat automatische verlenging bestaat voor elk openbaar toegankelijk certificaat; voltooi de certificaatinventarisatie van het volledige certificaatbestand.	CA/Browser Forum Stembiljet SC-081v3
Maart 15 2027	Maximale geldigheidsduur en hergebruik van DCV beperkt tot 100 dagen.	Alle houders van openbare TLS-certificaten; teams die nog steeds afhankelijk zijn van handmatige uitgifte.	Elimineer handmatige uitgifte in productie; koppel automatisering aan load balancers, Kubernetes en CI/CD.	CA/Browser Forum Stembiljet SC-081v3
Maart 15 2029	Maximale geldigheidsduur verkort tot 47 dagen; hergebruik van DCV beperkt tot 10 dagen.	Alle houders van openbare TLS-certificaten	Voer volledig geautomatiseerde, herhaalbare verlengingsprocessen van begin tot eind uit; beschouw elke handmatige verlenging als een uitzondering.	CA/Browser Forum Stembiljet SC-081v3
15 maart 2026 (van kracht)	DNSSEC-handtekeningvalidatie is vereist tijdens CAA- en domeinvalidatie-opzoekingen.	Domeinen met DNSSEC geïmplementeerd	Controleer of de DNSSEC- en CAA-records in orde zijn voordat u vertrouwt op geautomatiseerde uitgifte.	CA/Browser Forum Stembiljet SC-085v2

Bronvermeldingen voor deze tijdlijn: CA/Browser Forum Ballot SC-081v3, goedgekeurd op 11 april 2025 ( cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods ); secundaire samenvatting via Sectigo ( sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days ).

Een paar punten worden vaak over het hoofd gezien. Ten eerste geldt dit alleen voor openbare CA's die door browsers worden vertrouwd. Uw eigen interne of private PKI is niet gebonden aan deze regels, maar het is toch verstandig om dezelfde aanpak te volgen, omdat handmatige handelingen die openbare verlengingen verstoren, ook interne verlengingen kunnen verstoren. Ten tweede zijn de cijfers in dit schema maximumwaarden, geen typische uitgiftetermijnen. CA's geven certificaten iets minder uit dan de maximumwaarde om een ​​veiligheidsmarge te behouden. Een certificaat dat zelfs maar één seconde te laat wordt uitgegeven, wordt beschouwd als onjuist uitgegeven en moet worden ingetrokken, dus geen enkele CA neemt een te krappe deadline.

Er is ook een gerelateerde wijziging die het vermelden waard is. Een aparte stemming van het CA/B Forum, SC-085v2, is op dezelfde dag van kracht geworden. Wanneer een domein DNSSEC (Domain Name System Security Extensions) gebruikt, moeten certificeringsinstanties (CA's) deze handtekeningen valideren tijdens de CAA- en domeinvalidatie-DNS-zoekopdrachten die ze uitvoeren vóór de uitgifte. Schone DNS- en CAA-records zijn daarom nu belangrijker dan ooit. Voordat we beslissen hoe we hierop moeten reageren, is het nuttig om te begrijpen waarom de branche voor deze aanpak heeft gekozen, omdat de reden wijst naar de juiste oplossing.

Waarom certificaten steeds korter worden

Het doel is om risico's te beperken voordat ze een probleem worden. Een certificaat is een momentopname van het vertrouwen op het moment dat het wordt uitgegeven. Hoe langer een certificaat geldig blijft, hoe groter de kans dat de informatie die erin staat, zoals wie de domeinnaam bezit of of de sleutel nog veilig is, niet meer overeenkomt met de werkelijkheid. Kortere geldigheidsduur zorgt ervoor dat die informatie actueel blijft en verkleint de periode waarin een verouderd of onjuist uitgegeven certificaat nog steeds betrouwbaar is.

Er is nog een tweede reden. Intrekking heeft op internetschaal nooit goed gewerkt. Intrekkingslijsten zijn lang, het statuscontroleprotocol ( OCSP ) zorgt voor vertraging en privacyproblemen, en browsers laten vaak een verbinding door wanneer een statuscontrole een time-out geeft. Een korte geldigheidsduur werkt als een intrekking die altijd slaagt, omdat een risicovol certificaat simpelweg binnen enkele weken verloopt. Kortere certificaten maken het ook veel gemakkelijker om zwakke algoritmes snel uit te faseren, wat van groot belang is voor de overgang naar post-kwantumcryptografie.

Dat zijn wel degelijk voordelen, maar ze leggen de verantwoordelijkheid wel bij degene die het certificaat bezit. Om te begrijpen waarom automatisering nu een noodzaak is, is het nuttig om het schema om te zetten naar de daadwerkelijke werklast die uw team zal moeten dragen.

Wat dit betekent voor uw werkdruk

De berekening is eenvoudig. Een certificaat dat voorheen eens per jaar na 398 dagen werd verlengd, moet nu ongeveer elke 47 dagen worden verlengd, oftewel ongeveer acht keer per jaar. Een kleine set van 100 openbare certificaten gaat van ongeveer 100 verlengingen per jaar naar ongeveer 800. Dat is een verachtvoudige toename, maar het grotere probleem is de verdwijnende marge voor fouten. Bij een jaarlijkse cyclus gaf een gemiste verlenging dagen of weken de tijd om de problemen op te lossen. Bij 47 dagen is die marge slechts enkele uren, en het DCV-venster van 10 dagen betekent dat je de domeincontrole bij bijna elke verlenging opnieuw moet bewijzen.

Teams die OV- of EV-certificaten gebruiken , hebben een extra last: SC-081v3 verkort ook de hergebruiksperiode voor Subject Identity Information (SII), de organisatorische identiteitsgegevens achter die certificaten, van 825 dagen naar 398 dagen, waardoor bedrijfsgegevens vaker opnieuw gevalideerd moeten worden.

De kosten van een fout op dit gebied zijn goed gedocumenteerd. In een onderzoek uit 2023 gaf 77% van de organisaties aan dat ze in de twee voorgaande jaren minstens twee grote storingen hadden ondervonden als gevolg van verlopen certificaten, en meer dan de helft zei dat deze storingen de klantgerichte diensten hadden getroffen. Meer recentelijk bleek uit de Trust Pulse Survey van DigiCert, gepubliceerd op 2 juli 2025, dat 45% van de organisaties in het afgelopen jaar te maken had gehad met downtime als gevolg van certificaten, en dat 37.5% een storing specifiek kon herleiden tot een verlopen certificaat. Bron: digicert.com/news/digicert-survey-finds-manual-processes-expose-organizations.

Dit zijn geen zeldzame gebeurtenissen. In februari 2020 lag Microsoft Teams wereldwijd plat na een verlopen certificaat. De gevolgen zijn echter niet altijd even zichtbaar. Tijdens het datalek bij Equifax in 2017 zorgde een verlopen certificaat ervoor dat een beveiligingsapparaat aanvallers lange tijd niet kon detecteren. Op jaarbasis waren dergelijke fouten zeldzaam genoeg om onopgemerkt te blijven. Bij een geldigheidsduur van 47 dagen wordt één gemiste handmatige verlenging een veel frequenter en zeer publiek risico.

Voordat je verlengingen kunt automatiseren, moet je eerst weten wat je precies verlengt. Het lastigste onderdeel van de voorbereiding is meestal niet de verlenging zelf, maar het vinden van alle certificaten die een verlenging nodig hebben.

Waar uw certificaten zich verstoppen

De meeste bedrijven hebben veel meer certificaten dan ze denken, en die lacune is niet zonder risico's. Je kunt niet vernieuwen wat je niet kunt zien, en een onbekend certificaat met een vervaldatum van 47 dagen is een potentiële bron van problemen. Certificaten stapelen zich op, niet alleen bij de voor de hand liggende webservers:

• Load balancers (F5 BIG-IP(NetScaler, HAProxy), waarbij een vernieuwd certificaat ook opnieuw aan de juiste virtuele server of het juiste profiel moet worden gekoppeld.
• Kubernetes en service meshes, waar ingress controllers en service-to-service mTLS continu certificaten uitgeven en vernieuwen.
• CI/CD-pipelines en geheime opslagplaatsen (Azure Key Vault, AWS-geheimenmanager), waar sleutels en certificaten in builds en apps worden opgenomen.
• Cloud-native en kortstondige workloads zoals containers en serverloze functies, waarvan de IP-adressen sneller veranderen dan een spreadsheet kan bijhouden.
• Apparaten en IoT, interne mTLS API's, e-mail (S/MIME) en systemen voor codeondertekening, elk met een eigen configuratie en eigenaar.

Een echte inventarisatie vereist meer dan een eenmalige scan. Goede CLM-platforms combineren verschillende detectiemethoden: netwerkscans zonder agent, scans op hosts met een agent, directe verbindingen met uw CA's en cloudproviders, en monitoring van Certificate Transparency (CT)-logboeken. De richtlijnen van NIST voor TLS-certificaatbeheer beschouwen dit soort altijd actuele inventarisatie, met een duidelijke eigenaar voor elk certificaat, als de eerste stap van elk beheerd programma.

Zodra je een compleet beeld hebt van je organisatie, is de volgende vraag hoe je die op grote schaal kunt beheren. Dat komt neer op drie onderling afhankelijke vaardigheden.

De drie pijlers van paraatheid

Voorbereiding draait minder om één hulpmiddel en meer om drie vaardigheden die samenwerken. Verzwak er één en de andere twee kunnen dat niet compenseren.

1. Ontdekking en inventarisatie

Continue ontdekking zorgt voor één centrale, overzichtelijke lijst waarin elk certificaat een bekende locatie, vervaldatum, sleuteltype, uitgevende CA en eigenaar heeft. Dit is de enige bron van waarheid waar alles van afhangt. Zonder deze lijst vernieuwt automatisering alleen de certificaten die u al kent, terwijl de onbekende certificaten stilletjes verlopen.

2. Bestuur en eigendom

Een goede inventaris is nutteloos als niemand de eigenaar is van elk certificaat. Dit is waar veel teams echt tekortschieten. Een onderzoek van Gartner uit 2024 onder 335 IAM-leiders wees uit dat identiteitsteams slechts verantwoordelijk zijn voor 44% van de machine-identiteiten binnen een organisatie. De rest ligt bij applicatieteams, DevOps of niemand. Governance lost dit op door duidelijke regels vast te stellen voor de uitgifte (goedgekeurde sleuteltypen en algoritmen, welke CA te gebruiken, maximale geldigheidsduur en naamgeving), deze regels af te dwingen tijdens het aanvraagproces, elk certificaat een eigenaar te geven en op rollen gebaseerde toegang en goedkeuringen door meerdere personen (M of N) te gebruiken voor gevoelige certificaten.

3. Automatisering

Automatisering is essentieel voor het voortbestaan ​​van het nieuwe tempo. Het ACME-protocol stelt software in staat certificaten aan te vragen, te valideren en te vernieuwen, terwijl de ACME-client de implementatie ervan op het doelsysteem afhandelt. Dankzij selfservice kunnen ontwikkelaars op aanvraag goedgekeurde certificaten verkrijgen zonder een ticket aan te hoeven maken. Maar met een doorlooptijd van 47 dagen is basisautomatisering noodzakelijk, maar niet voldoende, en de manier waarop deze is geïmplementeerd is van groot belang.

Dat bouwdetail is waar veel programma's stilletjes de mist in gaan, dus het is de moeite waard om de tools die ervoor zorgen dat automatisering in dit tempo betrouwbaar blijft, eens nader te bekijken.

Hoe een installatie eruitziet die klaar is voor gebruik binnen 47 dagen.

Een robuuste configuratie verbindt de drie pijlers tot één continue lus. Discovery zorgt ervoor dat de centrale inventaris actueel blijft. Een beleidscontrole beoordeelt elk verzoek aan de hand van uw regels voordat het certificaat wordt uitgegeven. Een ACME-client (of SCEP- en EST-client) genereert een nieuw sleutelpaar, idealiter met de privésleutel die intern wordt gegenereerd of beschermd door een HSM of cloud-sleutelopslag en nooit in platte tekst wordt gekopieerd. De CA geeft het certificaat vervolgens uit na automatische validatie. Het nieuwe certificaat en de nieuwe sleutel worden vervolgens op een herhaalbare manier geïmplementeerd op de gewenste locatie, of dat nu een load balancer-profiel, een ingress controller, een service mesh sidecar of een secret store is, en het oude materiaal wordt op een nette manier verwijderd.

Rondom die kern draaien continu twee processen. ACME Renewal Information (ARI, RFC 9773) stelt ACME-clients in staat om het door de CA voorgestelde verlengingsvenster op te vragen en vroegtijdig binnen dat venster te verlengen. Tegelijkertijd genereert CT-log monitoring waarschuwingen voor certificaten die buiten het organisatiebeleid zijn uitgegeven. Dashboards en ITSM-integraties (bijvoorbeeld ServiceNow) bieden certificaateigenaren inzicht en een volledig auditspoor. Een goede vuistregel is om de verlenging te starten wanneer het certificaat nog ongeveer een derde van zijn levensduur heeft, of wanneer ARI dit suggereert, zodat er ruimte is voor twee volledige verlengingspogingen voordat het verloopt. Deze ene gewoonte voorkomt de meeste mislukkingen op dezelfde dag.

Weten hoe de opstelling eruitziet is één ding. Weten wanneer je elk onderdeel moet doen is iets anders, en omdat de verandering in fases plaatsvindt, is het slim om het werk af te stemmen op de deadlines.

Een eenvoudig plan voor 2026 tot 2029

Elke fase elimineert een laag handmatige fouten, waardoor je focus bij elke mijlpaal verandert. Beschouw de data als deadlines voor het opbouwen van capaciteit, niet als louter afvinklijstjes.

Fase	Maximale geldigheidsduur	Waarop moet je je concentreren?
Nu tot 2027 maart	200 dagen	Voltooi de ontdekking en bouw de hoofdinventaris op, wijs eigenaren toe, test de ACME-automatisering op een drukbezocht domein en controleer de DNSSEC- en CAA-records.
Maart 2027	100 dagen	Schakel handmatige uitgifte uit de productieomgeving uit, implementeer ARI-compatibele clients, verbind het platform met load balancers, Kubernetes en CI/CD, en handhaaf beleid in de pipeline.
Maart 2029	47 dagen	Voer volledig geautomatiseerde, herhaalbare verlengingsprocessen van begin tot eind uit, bevestig failover naar een tweede CA, test urgente vervroegde verlenging via ARI en behandel elke handmatige verlenging als een uitzondering.

Een plan heeft pas zin als je kunt aantonen dat je er vooruitgang mee boekt, en dat is waar een paar simpele cijfers goede bedoelingen omzetten in bewijs.

Hoe meet je je vooruitgang?

Deze cijfers geven PKI- leiders een duidelijk beeld van hun huidige situatie en wat er vervolgens moet worden aangepakt:

• Automatiseringsgraad: het percentage certificaten dat zonder menselijke tussenkomst is vernieuwd. Dit is het belangrijkste cijfer en zou vóór 2029 bijna het totaal moeten bereiken.
• Volledigheid van de inventaris: bekende certificaten versus de certificaten die zijn gevonden via onderzoek en CT-logmonitoring. Het verschil daartussen is uw onbeheersbaar risico.
• Tijd om te vernieuwen of te vervangen: hoe snel u een certificaat opnieuw kunt uitgeven en implementeren, bepaalt uw worst-case scenario voor uitval en uw reactiesnelheid bij een gedwongen intrekking.
• Storingen en bijna-storingen als gevolg van verlopen contracten: het doel is nul, en bijna-storingen zijn een vroege waarschuwing.
• Naleving van het beleid: het percentage certificaten dat voldoet aan de goedgekeurde sleuteltypen, algoritmen en geldigheidsduur, plus het aantal certificaten dat buiten het beleid is uitgegeven.

Deze cijfers vervullen een dubbele functie, omdat ze precies het bewijsmateriaal vormen waar auditors om vragen, waardoor certificeringsprocessen rechtstreeks gekoppeld worden aan uw nalevingswerkzaamheden.

Hoe dit zich vertaalt naar naleving

Een programma van 47 dagen is gemakkelijker uit te leggen en te financieren als het aansluit op de standaarden die uw organisatie al hanteert. De links zijn direct:

Standaard	Waarom dit belangrijk is voor 47-daagse certificaten
NIST SP 1800-16	Bedrijfshandleiding voor TLS-certificaatbeheer: inventarisatie, eigendom, automatisering en snelle vervanging.
NIST FIPS 203/204/205	Post-kwantumstandaarden die u met dezelfde automatisering en crypto-flexibiliteit kunt implementeren.
PCI DSS v4.0.1	Vereist het gebruik van sterke cryptografie en degelijk cryptografisch sleutelbeheer.
IETF RFC 8555 en RFC 9773	De automatiserings- en vernieuwingstermijnnormen die ten grondslag liggen aan het gehele proces.

Zelfs met vastgestelde standaarden en meetmethoden struikelen de meeste teams nog steeds over dezelfde paar fouten. Door ze van tevoren te kennen, voorkom je onnodige schade.

Veel voorkomende fouten te vermijden

• Te laat verlengen. Door te streven naar de laatste paar dagen is er geen ruimte voor een mislukte controle of implementatie. Verleng vroegtijdig, ongeveer een derde van de geldigheidsduur van het certificaat.
• Behandel privésleutels als draagbaar. Maak voor elke verlenging een nieuwe sleutel aan en bescherm deze met een HSM of sleutelkluis. Het hergebruiken van één sleutel voor meerdere verlengingen maakt een eventueel lek veel schadelijker, terwijl frequente rotatie de risico's beperkt.
• Afhankelijk zijn van één enkele CA. Ondersteuning voor meerdere CA's beschermt u tegen een CA-storing of een gedwongen massale intrekking van certificaten.
• Certificaten die niet voor het web bestemd zijn, worden buiten beschouwing gelaten. Interne services, mTLS, apparaten en codeondertekening ondervinden dezelfde druk, zelfs waar de openbare regels niet van toepassing zijn.
• Gebruik ARI-compatibele clients die slechts wekelijks draaien. De frequentie waarmee de client draait, is de werkelijke vereiste, niet een kwestie van afvinken.
• DNSSEC- en CAA-hygiëne even vergeten, nu DNSSEC-controles verplicht zijn en automatische uitgifte kunnen blokkeren.

Het vermijden van deze fouten doet meer dan alleen storingen voorkomen. Het ontwikkelt precies de vaardigheid die nodig zal zijn voor de volgende grote cryptografische verandering.

Ook de voorbereiding op het post-kwantumtijdperk is in volle gang.

Kortere levensduur is een goede oefening voor een grotere verandering die eraan komt. In augustus 2024 publiceerde NIST zijn eerste post-kwantum cryptografiestandaarden, FIPS 203 (ML-KEM) , FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) , en spoort organisaties aan om nu al in actie te komen.

Het overzetten van een complete PKI naar kwantumveilige algoritmen betekent dat algoritmen voor duizenden certificaten binnen een bepaalde deadline moeten worden vervangen. Dat is precies wat de huidige 47-daagse certificaatautomatisering vereist. Een team dat elk certificaat elke zes weken kan vervangen, met een volledige inventaris en duidelijke regels, is een team dat een post-kwantummigratie kan uitvoeren. Cryptografische flexibiliteit , het vermogen om algoritmen snel en veilig te wijzigen, ondersteund door een cryptografische materiaallijst ( CBOM ) die vastlegt waar elk algoritme en elke sleutel zich bevindt, is de rode draad die de 47-daagse TLS-certificaatwijziging verbindt met een kwantumveilige toekomst. Ons artikel 'CBOM: van inventaris tot intelligentie ' legt uit hoe die inventaris een uitvoerbaar herstelplan wordt.

Om precies te bepalen waar uw organisatie staat, centraliseert ons PQC Center of Excellence onderzoek, tools en begeleiding voor de komende migratie. Onze PQC-gereedheidsbeoordeling brengt uw certificaat- en cryptografische infrastructuur in kaart ten opzichte van die transitie, zodat crypto-flexibiliteit is ingebouwd voordat de deadlines van 47 dagen en na de quantumovergang samenkomen.

Het opzetten van dit alles, van ontdekking en beheer tot automatisering, sleutelbescherming en een plan voor crypto-flexibiliteit, is een flinke klus, en dat is waar onze certificaatlevenscyclusbeheerder het meest van pas komt.

Hoe encryptieconsultancy kan helpen

CertSecure Manager van Encryption Consulting LLC is ontwikkeld om de uitdagingen aan te pakken die gepaard gaan met de overstap naar kortere certificaatlevensduren, zoals 47 dagen. Met deze veranderingen wordt automatisering essentieel voor een efficiënt beheer van de nieuwe certificaatomgeving.

1. Implementeer een CLM-oplossing

Een CLM-oplossing is essentieel voor het efficiënt beheren van interne en externe certificaten, het waarborgen van cryptografische compliance en het stroomlijnen van certificaatinventarisaties en -rapportages. CertSecure Manager biedt bijvoorbeeld een complete oplossing die de volledige certificaatlevenscyclus automatiseert, van ontdekking tot implementatie, verlenging en intrekking, waardoor de handmatige inspanningen voor certificaatbeheer tot een minimum worden beperkt.

Het systeem automatiseert ook nalevingscontroles om ervoor te zorgen dat alle certificaten voldoen aan industriestandaarden zoals PCI-DSS , GDPR en ISO. Er worden uitgebreide rapporten gegenereerd voor audits, waardoor nalevingsprocessen worden vereenvoudigd.

2. Geautomatiseerde certificaatdetectie en inventarisatie

CertSecure Manager detecteert automatisch alle certificaten in uw infrastructuur, of deze nu on-premises, in de cloud of in hybride omgevingen zijn. Het biedt een complete certificaatinventarisatie, zodat geen enkel certificaat onbeheerd blijft, inclusief zelfondertekende certificaten die een beveiligingsrisico kunnen vormen. Met deze gecentraliseerde inventarisatie kunt u snel certificaten identificeren die aan vernieuwing toe zijn, waardoor het risico dat verlopen certificaten problemen veroorzaken aanzienlijk wordt verkleind.

3. Geavanceerde ACME-protocolintegratie

Door gebruik te maken van het ACME-protocol automatiseert CertSecure Manager de uitgifte en verlenging van certificaten op een veilige en gestandaardiseerde manier. Dit elimineert handmatige tussenkomst en zorgt ervoor dat certificaten altijd op tijd worden verlengd, zelfs bij de frequente verlengingscycli die nodig zijn voor kortere geldigheidsperioden zoals 47 dagen.

4. Automatische verlenging, heruitgifte en intrekking

CertSecure Manager automatiseert het vernieuwen en opnieuw uitgeven van certificaten, zodat deze altijd up-to-date zijn. Het trekt ook gecompromitteerde of onnodige certificaten in, waardoor beveiligingsrisico's worden verminderd en compliance wordt gewaarborgd.

Deze automatisering zorgt voor ononderbroken bedrijfsvoering binnen een organisatie en verbetert de beveiliging door snel actie te ondernemen bij gecompromitteerde of overbodige certificaten. Het maakt het voldoen aan compliance-eisen eenvoudiger door certificaten tijdig te beheren, duidelijke gegevens bij te houden en de beveiliging te verbeteren, terwijl de werkdruk wordt verlaagd en het vertrouwen wordt versterkt.

5. Naleving en rapportage

CertSecure Manager automatiseert compliancecontroles en zorgt ervoor dat uw certificaten voldoen aan industriestandaarden zoals NIST, HIPAA en GDPR. Het genereert uitgebreide rapporten voor auditdoeleinden, waardoor het gemakkelijker wordt om aan wettelijke vereisten te voldoen. Deze rapporten helpen u ook bij het beoordelen van uw certificaatinfrastructuur en het identificeren van potentiële zwakke punten voordat ze problemen veroorzaken.

6. Naadloze integraties en verlengingsagenten voor verbeterd certificaatbeheer

CertSecure Manager integreert met diverse tools en platforms, waaronder Terraform, Ansible, Azure Key Vault en Splunk , voor een gestroomlijnd certificaatbeheer. Het automatiseert het aanmaken, vernieuwen en implementeren van certificaten binnen CI/CD-pipelines voor databases, webservers (Apache, IIS, NGINX) en meer. De vernieuwingsagents zijn aangepast aan deze services, waardoor certificaten consistent worden bijgewerkt en beveiligd.

Nu de sector overstapt op certificaatgeldigheidsperiodes van 47 dagen, helpen de integraties en geautomatiseerde processen van CertSecure Manager bij het handhaven van de beveiliging, naleving en uptime door verlengingen af ​​te handelen en certificaten in verschillende omgevingen te beheren met minimale handmatige inspanning.

Wat te doen Volgende

Het behalen van de 47-dagen TLS-certificaatgereedheid is een gezamenlijke inspanning van alle teams. Hieronder staat waar elk team zou moeten beginnen.

• PKI-team: Zorg ervoor dat certificaatdetectie alle cloud-, on-premise- en hybride omgevingen op gelijke wijze dekt, en test de ACME-automatisering nu al op een domein met een hoog transactievolume, vóór de overstap in maart 2027.
• Beveiligingsteam: Vereis dat bij elke verlenging een door HSM ondersteunde sleutel wordt gegenereerd, controleer de Certificate Transparency-logboeken op uitgiften die niet aan het beleid voldoen en bevestig dat failover naar een tweede CA is getest.
• Platform- en DevOps-team: Verplaats certificaatautomatisering naar ARI-compatibele ACME-clients en verbind deze met load balancers, Kubernetes ingress en CI/CD-pipelines voordat handmatige uitgifte onhoudbaar wordt bij een geldigheidsduur van 100 en 47 dagen.
• Nalevingsteam: Houd nu de automatiseringsdekking, de volledigheid van de inventaris en de naleving van het beleid bij, zodat er al bewijsmateriaal beschikbaar is voor de audit wanneer de deadline van 47 dagen in maart 2029 verstrijkt.

Conclusie

De overgang naar certificaten met een looptijd van 47 dagen is een feit, vindt gefaseerd plaats en is al in volle gang. De fase van 200 dagen is al begonnen, de fase van 100 dagen volgt in maart 2027 en de limiet van 47 dagen wordt in 2029 bereikt, samen met een DCV-venster van 10 dagen dat handmatig werk onmogelijk maakt.

De teams die dit goed aanpakken, beschouwen het als een ontwerpprobleem, niet als een verlengingsprobleem: bekijk elk certificaat, wijs aan elk certificaat een eigenaar toe, stel duidelijke regels op, automatiseer met ARI in gedachten, bescherm uw sleutels, volg het schema en houd uw voortgang bij met concrete cijfers. Bouw die basis nu, en dezelfde opzet brengt u naar het post-kwantumtijdperk. Als u een 47-dagen-klaar , crypto-flexibel PKI-systeem aan het ontwerpen bent, is het beste moment om te beginnen vóór de volgende fase aanbreekt.

Wat is de belangrijkste conclusie van PKI in 2026: Hoe overleef je het tijdperk van TLS-certificaten met een geldigheidsduur van 47 dagen? De geldigheidsduur van openbare TLS-certificaten is vastgelegd in een reeds actieve aftelling, bepaald door CA/Browser Forum Ballot SC-081v3: nu 200 dagen, 100 dagen in maart 2027 en 47 dagen in maart 2029. Om dit te overleven, is het essentieel om certificaten te behandelen als een continu, geautomatiseerd proces in plaats van een jaarlijkse vernieuwingstaak, gebaseerd op volledige certificaatdetectie, duidelijk eigenaarschap en certificaatautomatisering.

Waarom is dit belangrijk voor het beheer van de certificaatlevenscyclus binnen een onderneming? Omdat de vernieuwingsfrequentie ongeveer acht keer zo hoog wordt tussen de basisperiode van 398 dagen en de minimale periode van 47 dagen, leidt elke onderbreking in het overzicht of beheer tot een proportioneel groter risico op een storing, een mislukte audit of het missen van een domeincontrolevalidatie. Uit het Trust Pulse-onderzoek van DigiCert bleek dat 45% van de organisaties het afgelopen jaar al te maken heeft gehad met downtime als gevolg van certificaatproblemen, nog voordat de kortste validatieperiodes ingaan.

Welke teams zijn verantwoordelijk voor de uitvoering van deze richtlijnen? Vier teams delen de verantwoordelijkheid: het PKI-team, dat verantwoordelijk is voor het uitgiftebeleid en de relaties met certificeringsinstanties; het beveiligingsteam, dat verantwoordelijk is voor sleutelbescherming en cryptografische risico's; het platform- en DevOps-team, dat verantwoordelijk is voor geautomatiseerde verlenging en implementatie; en het compliance-team, dat verantwoordelijk is voor het auditbewijs voor het certificaatportfolio. De verantwoordelijkheids- en actiematrix in dit bericht beschrijft de specifieke verantwoordelijkheden van elk team.

Welke risico's nemen toe als dit onderwerp handmatig wordt afgehandeld? Handmatige certificaatverwerking verhoogt de kans op gemiste verlengingen die tot storingen leiden, omdat de foutmarge afneemt van dagen of weken bij een jaarlijkse cyclus tot uren bij een cyclus van 47 dagen. Bovendien betekent het hergebruikvenster van 10 dagen voor domeincontrolevalidatie dat domeincontrole vrijwel bij elke verlenging opnieuw moet worden bewezen. Het verhoogt ook de kans op hergebruikte privésleutels, afhankelijkheid van één enkele certificeringsinstantie (CA) en een verkeerde configuratie van DNSSEC of CAA die automatische uitgifte volledig blokkeert.

Hoe vermindert automatisering het risico op certificaatuitval? Certificaatautomatisering elimineert gemiste deadlines en handmatige fouten die de overgrote meerderheid van certificaatuitval veroorzaken. Dit gebeurt door de uitgifte, verlenging en intrekking af te handelen volgens een beleidsgestuurd schema, waarbij ACME Renewal Information (ARI) wordt gebruikt om vroegtijdig te verlengen binnen de door de CA voorgestelde periode. Het is tevens de enige praktische manier om gelijke tred te houden met de ongeveer achtvoudige toename van het verlengingsvolume die het 47-dagenschema met zich meebrengt.

Welke statistieken moeten teams bijhouden na de implementatie? Houd de automatiseringsdekking bij (het percentage certificaten dat zonder menselijke tussenkomst is vernieuwd, wat vóór 2029 bijna volledig zou moeten zijn), de volledigheid van de inventaris (bekende certificaten versus certificaten die zijn gevonden via ontdekking en monitoring van het Certificate Transparency-logboek), de tijd die nodig is om certificaten te vernieuwen of te vervangen, storingen en bijna-storingen als gevolg van het verlopen van certificaten, en de naleving van het beleid voor alle belangrijke typen, algoritmen en geldigheidsperioden.

Hoe sluit dit aan op de 47-daagse TLS-certificaatgereedheid? Deze hele handleiding is de routekaart voor de 47-daagse TLS-certificaatgereedheid: de stemming SC-081v3 van het CA/Browser Forum, goedgekeurd op 11 april 2025, stelt het vaste schema vast. Gereedheid betekent dat certificaatdetectie, -beheer en certificaatautomatisering volledig operationeel zijn vóór de 47-daagse, 10-daagse DCV-ondergrens in maart 2029, in plaats van dat u zich pas op het laatste moment hoeft te haasten.

Hoe moet dit worden aangepakt in multi-cloud- of hybride PKI-omgevingen? Multi-cloud- en hybride omgevingen vereisen één centraal, continu bijgewerkt certificaatoverzicht dat alle cloudproviders, on-premise systemen en hybride verbindingspunten omvat. Gefragmenteerde zichtbaarheid is immers de reden waarom certificaten na 47 dagen niet meer worden vernieuwd. Gecentraliseerde detectie, beleidshandhaving en ARI-bewuste automatisering in alle omgevingen, in plaats van oplossingen per cloudpunt, zorgen ervoor dat de vernieuwingstermijn en het eigenaarschap consistent blijven, ongeacht waar een certificaat zich bevindt.