Verbeterde beveiliging met TLS-certificaten met een geldigheidsduur van 47 dagen, uiterlijk in 2029.

Als uw organisatie momenteel openbare TLS-certificaten beheert en nog steeds afhankelijk is van handmatige verlengingsworkflows, agendaherinneringen of andere processen waarbij een mens een naderende vervaldatum moet signaleren en actie moet ondernemen, zullen de komende drie jaar een behoorlijke omwenteling betekenen.

Op 11 april 2025 keurde het CA/Browser Forum voorstel SC-081v3 goed , officieel getiteld "Introduceer een schema voor het verkorten van de geldigheidsduur en de periode voor hergebruik van gegevens". De stemming was eenduidig: 25 certificeringsinstanties stemden voor, nul tegen, en alle vier de grote browserleveranciers, Apple, Google, Microsoft en Mozilla, stemden voor. Het resultaat is een vast, gefaseerd schema dat de maximale geldigheidsduur van alle publiekelijk vertrouwde TLS-certificaten verkort van 398 dagen nu naar 47 dagen op 15 maart 2029.

In deze blog bespreken we precies wat SC-081v3 vereist, waarom het CA/Browser Forum deze beslissing heeft genomen, wat de operationele gevolgen zijn voor teams die TLS-certificaten beheren , en wat uw organisatie nu al moet doen om elke fase voor te blijven.

TL; DR

• Het voorstel SC-081v3 van het CA/Browser Forum verkort de maximale geldigheidsduur van publiekelijk vertrouwde TLS-certificaten van 398 dagen naar 47 dagen in drie fasen: 200 dagen vanaf 15 maart 2026, 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029.
• De hergebruiksperioden voor domeincontrolevalidatie (DCV) worden volgens hetzelfde schema steeds korter, tot slechts 10 dagen in 2029, waardoor geautomatiseerde, op ACME gebaseerde validatie een vereiste wordt in plaats van een luxe.
• Volgens het onderstaande brancheonderzoek uit 2025 en 2026 meldt 72% van de organisaties al minstens één storing met betrekking tot certificaten in het afgelopen jaar, en slechts 34% zegt een volledig en actueel overzicht van hun eigen certificaten te hebben.
• Handmatige verlenging en agendaherinneringen zijn niet geschikt voor certificaten met een geldigheidsduur van 47 dagen. ACME-gebaseerde automatisering, implementatieverificatie en een centrale certificaatinventaris zijn nu basisvereisten en geen optimalisaties meer.

Wat is er veranderd en wanneer?

Het voorstel SC-081v3 werd oorspronkelijk in januari 2025 door Apple ingediend en de beoordelingsperiode voor de intellectuele eigendomsrechten werd op 13 mei 2025 afgesloten zonder bezwaren, waardoor het voorstel vanaf die datum volledig van kracht is.

Het voorstel wijzigt twee onderdelen van de TLS-basisvereisten:

• sectie 6.3.2: stelt het gefaseerde schema in voor het verkorten van de maximale geldigheidsperiode van TLS-certificaten.
• sectie 4.2.1: stelt het parallelle schema in voor het verkorten van de periode waarin bewijsmateriaal voor domeincontrolevalidatie (DCV) opnieuw kan worden gebruikt tussen certificaatuitgiften.

Beide wijzigingen worden in dezelfde drie fasen doorgevoerd, telkens op 15 maart van elk jaar:

Fase	Ingangsdatum	Maximale geldigheidsduur van het TLS-certificaat	DCV Hergebruikperiode
Fase 1	15 maart 2026	200 dagen	200 dagen
Fase 2	15 maart 2027	100 dagen	100 dagen
Fase 3	15 maart 2029	47 dagen	10 dagen

Voordat een certificeringsinstantie (CA) een TLS-certificaat voor een domein kan uitgeven, moet deze eerst verifiëren of de aanvrager daadwerkelijk de controle over dat domein heeft. Dit wordt domeincontrolevalidatie genoemd. In de praktijk vereist een CA dat de aanvrager een uitdaging voltooit, meestal door een specifiek bestand op een bekende URL van het domein te plaatsen (HTTP-01), een specifiek DNS TXT-record toe te voegen (DNS-01) of te reageren op een validatiemail die naar een geregistreerd contactadres voor het domein is gestuurd. Zodra de CA bevestigt dat aan de uitdaging is voldaan, beschouwt zij het domein als gevalideerd. Historisch gezien kon dit validatiebewijs tot 398 dagen worden hergebruikt, wat betekende dat een CA gedurende meer dan een jaar certificaten voor hetzelfde domein kon uitgeven zonder nieuw bewijs te hoeven overleggen.

SC-081v3 verkort deze hergebruiksperiode in lijn met de geldigheidsduur van het certificaat, waardoor deze uiteindelijk in maart 2029 wordt teruggebracht tot slechts 10 dagen. Op dat moment moet het domeineigendom bij vrijwel elke certificaatvernieuwing opnieuw worden geverifieerd, waardoor geautomatiseerde DCV via het challenge-response-protocol van ACME een harde operationele vereiste wordt in plaats van een optimalisatie. Voor een diepere analyse van het automatiseren van de domeinvalidatiestap zelf, zie de handleiding van Encryption Consulting over persistente DCV en DNS-connectoren.

Vanaf vandaag is fase 1 van kracht. Elk nieuw uitgegeven TLS-certificaat heeft een maximale geldigheidsduur van 200 dagen. Certificaten die vóór de deadline van elke fase zijn uitgegeven, blijven geldig voor de oorspronkelijke periode. Elk certificaat dat op of na de deadline is uitgegeven, moet voldoen aan de nieuwe maximale geldigheidsduur voor die fase, aangezien er geen respijtperiode is voor nieuw uitgegeven certificaten.

Waarom het CA/Browser Forum deze beslissing heeft genomen

De trend naar kortere geldigheidsduur van certificaten is al jaren gaande. TLS-certificaten waren tot 2015 maximaal vijf jaar geldig, totdat het CA/Browser Forum die termijn verkortte tot drie jaar. In 2018 daalde de maximale geldigheidsduur naar twee jaar. In 2020 beperkte Apple eenzijdig de geldigheidsduur van nieuwe certificaten in Safari tot 398 dagen, waardoor de hele branche gedwongen werd deze limiet over te nemen.

• Het beperken van de explosieradius: Wanneer een privésleutel wordt gestolen, een certificaat frauduleus wordt uitgegeven of een ondertekeningsalgoritme zwak blijkt te zijn, is de potentiële schade rechtstreeks evenredig met de resterende geldigheidsduur van het certificaat. Een certificaat met een resterende geldigheidsduur van 47 dagen biedt een veel kleinere kans op misbruik dan een certificaat met een geldigheidsduur van 398 dagen.
• Het intrekken van de overeenkomst: Certificaatintrekking werkt in de praktijk grotendeels niet. Het Online Certificate Status Protocol (OCSP) werkt in de meeste browsers op basis van een 'soft fail', wat betekent dat browsers doorgaans doorgaan met de verbinding in plaats van deze te blokkeren als de OCSP-responder onbereikbaar is. Lijsten met ingetrokken certificaten (CRL's) worden zelden bijgewerkt en inconsistent gecontroleerd. Let's Encrypt is in 2024 begonnen met het volledig uitfaseren van OCSP en heeft die overgang in 2025 voltooid, vanwege de ineffectiviteit ervan.
• Sterkere cryptografische praktijken: Certificaten met een lange geldigheidsduur stellen organisaties in staat om algoritmemigraties uit te stellen. Een certificaat dat in 2023 is uitgegeven met een zwakke sleutelgrootte of een verouderd algoritme, kan in 2026 nog steeds in gebruik zijn als de geldigheidsduur zo lang is. Kortere geldigheidsperioden dwingen tot frequentere uitgifte, wat betekent dat er vaker mogelijkheden zijn om de huidige algoritme- en sleutelstandaarden toe te passen.
• Vereiste automatisering: Het CA/Browser Forum heeft expliciet verklaard dat een van de doelen van SC-081v3 is om de invoering van geautomatiseerd certificaatlevenscyclusbeheer te stimuleren. Een certificaat met een geldigheidsduur van 47 dagen dat elke zes weken wordt vernieuwd, is niet compatibel met handmatige processen, omdat de operationele overhead simpelweg te hoog is. Dit maakt het proces betrouwbaarder, beter controleerbaar en robuuster dan elk proces dat afhankelijk is van menselijke tussenkomst.

De omvang van het probleem: wat de gegevens aantonen

De hierboven beschreven verstoring is niet hypothetisch. Recent brancheonderzoek naar certificaat- en machine-identiteitsbeheer onderbouwt dit met concrete cijfers:

• Volgens CyberArk heeft 72% van de organisaties de afgelopen 12 maanden minstens één storing ondervonden die verband hield met certificaten, en 45% gaf aan dat er wekelijks storingen plaatsvonden, een stijging ten opzichte van slechts 12% per week in 2022. Rapport over de stand van zaken rond machine-identiteitsbeveiliging in 2025.
• Volgens DigiCert heeft slechts 34% van de organisaties een volledig en actueel overzicht van hun eigen digitale certificaten, en bijna driekwart is zeer of extreem bezorgd over storingen die worden veroorzaakt door verlopen certificaten. Wereldwijd PKI-onderzoeksrapport 2026, gepubliceerd op 2 juni 2026 en gebaseerd op een enquête onder meer dan 400 senior IT- en beveiligingsleiders.
• Het aantal machine-identiteiten is nu naar schatting 82 keer zo groot als het aantal menselijke identiteiten, en 79% van de beveiligingsdeskundigen verwacht dat dit aantal het komende jaar nog verder zal groeien, met wel 150%, aldus onderzoek van CyberArk dat in hun rapport wordt aangehaald. Update van het machine-identiteitsbeveiligingsportfolio in oktober 2025.

Deze cijfers beschrijven een sector die al onder grote druk stond met een geldigheidsduur van 398 dagen. Het comprimeren van dezelfde werklast tot cycli van 47 dagen, met veel minder ruimte voor een gemiste verlenging of een niet-geverifieerd domein, is iets wat handmatige processen niet aankunnen. Voor meer informatie over hoe de groei van machine-identiteiten dit probleem specifiek voor PKI-teams verergert, zie de Machine Identity Guide for PKI Teams van Encryption Consulting.

Wat 47-dagencertificaten operationeel betekenen

De operationele gevolgen van SC-081v3 variëren aanzienlijk, afhankelijk van de omvang en complexiteit van uw certificaatconfiguratie en de huidige stand van uw certificaatbeheerpraktijken.

Inzicht in certificaatinventaris

U kunt het verlengen van certificaten waarvan u het bestaan ​​niet kent, niet beheren. Een wildgroei aan certificaten, waarbij certificaten worden uitgegeven aan meerdere teams, cloudomgevingen, Kubernetes- clusters, CDN-configuraties en legacy-servers zonder centrale tracking, is de meest voorkomende oorzaak van storingen in de certificaatvervaldatum. Bij jaarlijkse verlengingscycli kan een niet-gedetecteerd certificaat maandenlang onopgemerkt blijven voordat het verloopt. Bij cycli van 47 dagen verloopt een niet-geregistreerd certificaat binnen enkele weken na uitgifte.

Het creëren van een volledig inzicht in de certificaatinventaris, in alle omgevingen, inclusief interne services, infrastructuur die niet direct met klanten te maken heeft en certificaten die worden beheerd door externe teams of diensten van derden, is de fundamentele vereiste voor deze update van de geldigheidsduur van certificaten.

CI/CD- en implementatie-integratie

Een van de meest voorkomende fouten in geautomatiseerde certificaatomgevingen is de "vernieuwings-implementatiekloof", waarbij de ACME-client met succes een nieuw certificaat verkrijgt, maar de implementatiestap die het op de betreffende server, load balancer of Kubernetes-ingang installeert, stilzwijgend mislukt. Het vernieuwde certificaat blijft in een bestandssysteem of geheimenopslag staan, terwijl het oude certificaat verkeer blijft afhandelen totdat het verloopt.

Bij een geldigheidsduur van 47 dagen is de implementatiekloof een kritieke foutbron. Certificaatvernieuwing moet worden geïntegreerd met de implementatie en het nieuwe certificaat moet worden geverifieerd als zijnde geïmplementeerd en geschikt voor het verwerken van verkeer voordat de vernieuwing als voltooid wordt beschouwd.

Verouderde infrastructuur en certificaatpinning

Verouderde applicaties met hardgecodeerde certificaten, IoT-apparaten met in de firmware ingebouwde CA's, systemen die gebruikmaken van certificaatpinning en omgevingen met handmatige implementatieprocessen zijn allemaal voorbeelden waarbij certificaten met een geldigheidsduur van 47 dagen echte uitdagingen vormen die niet alleen door automatisering kunnen worden opgelost.

Certificaatpinning, waarbij een client zo is geconfigureerd dat deze alleen een specifiek certificaat of een specifieke publieke sleutel vertrouwt in plaats van elk certificaat van een vertrouwde certificeringsinstantie (CA), is fundamenteel onverenigbaar met een geldigheidsduur van 47 dagen. Als het gepinde certificaat elke zes weken moet worden vervangen, moet de clientconfiguratie met dezelfde frequentie worden bijgewerkt. De enige haalbare aanpak voor omgevingen met certificaatpinning is om volledig over te stappen van certificaatpinning naar standaard CA-gebaseerde vertrouwensverificatie voordat de 47-dagenverplichting ingaat.

Handmatig versus geautomatiseerd certificaatbeheer: welke aanpak houdt stand na 47 dagen?

Voordat we het onderstaande zevenstappenplan voor paraatheid doornemen, is het nuttig om de twee operationele modellen naast elkaar te bekijken.

Vereiste geldigheidsduur van 47 dagen	Handmatig / kalendergestuurd	Geautomatiseerd CLM (ACME + CertSecure Manager)
Verlengingen per certificaat per jaar	1 vandaag, oplopend tot 8+ in 2029	Hetzelfde volume, geen extra personeel.
Domeinvalidatie (hergebruik van DCV gedurende 10 dagen tegen 2029)	Bij elke vernieuwing handmatig opnieuw uitvoeren.	Machine-naar-machine uitdaging-antwoord via ACME
Certificaatinventaris	Spreadsheets en tribale kennis	Continue detectie in de cloud, on-premise en Kubernetes.
kloof tussen vernieuwing en implementatie	Het komt vaak voor dat vernieuwde certificaten ongebruikt blijven liggen terwijl de oude verlopen.	De implementatie wordt automatisch geverifieerd voordat de verlenging als voltooid wordt gemarkeerd.
Risico op stroomuitval	Hoog, in lijn met het hierboven genoemde uitvalpercentage van 72% in de sector.	Lager; verlenging wordt geactiveerd op basis van de vervaldatum, niet via een kalenderherinnering.
Audit- en compliance-rapportage	Handmatig loggen, inconsistent	Gecentraliseerde, exporteerbare verlengings- en uitgiftegeschiedenis

Handmatige processen stonden al onder druk bij een geldigheidsduur van 398 dagen. Bij 47 dagen, waarbij domeinvalidatie bijna net zo vaak plaatsvindt als de uitgifte zelf, zijn ze geen haalbare optie meer voor organisaties die meer dan een handvol openbare certificaten beheren.

Bereid je voor op de kortere geldigheidsduur van het TLS-certificaat.

Nu fase 1 al van kracht is en fase 2 in maart 2027 begint, is er niet oneindig veel tijd om de infrastructuur voor het 47-dagen-tijdperk op te bouwen. Hier volgt een praktisch stappenplan voor het creëren van paraatheid:

Stap 1: Stel een complete inventaris van certificaten samen.

Ontdek alle openbare TLS-certificaten die uw organisatie heeft uitgegeven, in alle omgevingen en teams. Gebruik Certificate Transparency (CT)-logmonitoring, API's van cloudproviders, netwerkscans en integraties met de beheerconsole van uw CA om een ​​gecentraliseerde inventaris op te bouwen. CBOM Secure van Encryption Consulting is speciaal hiervoor ontwikkeld. Het voert continu cryptografische detectie uit in uw gehele omgeving, waardoor u een compleet beeld krijgt van elk cryptografisch object voordat u begint met automatiseren. Dit is de fundamentele stap, aangezien alles afhangt van de kennis van wat u in uw omgeving hebt.

Stap 2: Stel verlengingsmeldingen in met passende termijnen.

De waarschuwingsdrempels moeten in elke fase opnieuw worden geconfigureerd. Bij een geldigheidsduur van minder dan 200 dagen (Fase 1) moeten de verlengingswaarschuwingen 60 dagen voor de vervaldatum worden ingesteld. Bij een geldigheidsduur van minder dan 100 dagen (Fase 2) moeten de waarschuwingen 30 dagen voor de vervaldatum worden ingesteld. Bij een geldigheidsduur van minder dan 47 dagen moeten waarschuwingen 25-30 dagen voor de vervaldatum worden geactiveerd, met escalerende waarschuwingen na 14 en 7 dagen.

Stap 3: Standaardiseer ACME voor de afgifte van certificaten.

ACME (Automated Certificate Management Environment) is het protocol dat specifiek is ontworpen voor geautomatiseerde certificaatuitgifte en -vernieuwing. CertSecure Manager van Encryption Consulting ondersteunt ACME native, naast de SCEP- en EST-protocollen, waardoor het het juiste platform is om te standaardiseren voor geautomatiseerde certificaatuitgifte en -vernieuwing op elke schaal. Het integreert direct met zowel publieke als private CA's, zodat uw op ACME gebaseerde vernieuwingsworkflows volledig compatibel zijn met de CA die uw organisatie gebruikt. Voor een diepere kijk op het automatiseren van de domeinvalidatiestap zelf, inclusief persistente DCV- en DNS-connectoren, raadpleegt u de handleiding van Encryption Consulting over het automatiseren van DNS-validatie met CertSecure Manager.

Stap 4: Elimineer vastgelegde vernieuwingsintervallen

Controleer alle scripts, cronjobs en automatiseringsconfiguraties die de certificaatvernieuwing beheren. Elke configuratie met een vastgelegd vernieuwingsinterval, zoals 'vernieuw elke 60 dagen' of 'vernieuw elke 90 dagen', zal niet meer werken naarmate de levensduur van certificaten korter wordt. Vervang dit door dynamische vernieuwingslogica op basis van de vervaldatum van certificaten of ACME ARI-signalen.

Stap 5: Overbrug de kloof tussen vernieuwing en implementatie.

Controleer voor elk certificaat in uw inventaris of het verlengingsproces een implementatiestap en een verificatiestap na de implementatie omvat, waarmee wordt bevestigd dat het verlengde certificaat daadwerkelijk aan clients wordt aangeboden. Dit is met name belangrijk in omgevingen waar verlenging en implementatie door aparte systemen of teams worden afgehandeld.

Stap 6: Pak de verouderde infrastructuur aan

Identificeer alle systemen die niet kunnen deelnemen aan geautomatiseerde verlenging, waaronder verouderde servers, in firmware ingebedde certificaten en vastgezette configuraties. Definieer voor elk systeem een ​​migratieplan voordat fase 2 dit noodzakelijk maakt. Dit zijn doorgaans de meest tijdrovende en resource-intensieve wijzigingen, en deze moeten ruim vóór de uiteindelijke deadline worden gestart.

Stap 7: Zorg voor gecentraliseerd inzicht en beheer.

Ga over op een centraal platform voor certificaatlevenscyclusbeheer (CLM), zoals onze CertSecure Manager, dat een uniforme inventaris, automatische verlenging, implementatieorkestratie en compliance-rapportage biedt voor alle omgevingen. De operationele complexiteit van het 47-dagen-tijdperk is niet compatibel met gefragmenteerd certificaatbeheer per omgeving.

Hoe encryptieconsultancy kan helpen

Bij Encryption Consulting hebben we een portfolio van producten en diensten ontwikkeld die specifiek zijn ontworpen om organisaties te helpen bij de overgang naar 47-daagse certificaten, van geautomatiseerd lifecyclemanagement en cryptografische ontdekking tot volledig beheerde PKI en paraatheid na de kwantumcrisis.

CertSecure Manager is het speciale platform van Encryption Consulting voor het beheer van de levenscyclus van certificaten en het meest directe antwoord op de eisen van de 47-dagenverplichting. Het automatiseert de uitgifte, verlenging en implementatie van certificaten op grote schaal met behulp van de ACME-, SCEP- en EST-protocollen en is specifiek ontworpen voor frequente verlengingscycli waarbij handmatige processen simpelweg niet kunnen meekomen.

Het platform automatiseert de inschrijving en verlenging van certificaten op webservers zoals Apache, Tomcat en IIS, en met loadbalancers zoals F5 BIG-IP. Het integreert met openbare, vertrouwde certificeringsinstanties zoals DigiCert en Entrust, en met private, vertrouwde certificeringsinstanties zoals Microsoft PKI, AWS Private CA en HashiCorp CA. Verlengingen worden dynamisch geactiveerd op basis van de vervaldatum van certificaten, niet op basis van vastgelegde intervallen, waardoor het inherent compatibel is met elke nieuwe fase van het SC-081v3-schema.

Het platform is ontwikkeld met cryptografische flexibiliteit als kernprincipe. Naarmate de definitieve PQC-standaarden van NIST de vereisten voor browsers en rootprogramma's beginnen te beïnvloeden, helpt het organisaties hun huidige cryptografische status te beoordelen en op een gecontroleerde, gefaseerde manier over te stappen op kwantumveilige certificaten, zonder dat het platform vervangen hoeft te worden of een ingrijpende handmatige migratie nodig is. Voor de volledige volgorde van deze cryptografische flexibiliteit kunt u de Post-Quantum Cryptography Migration Guide (9 Phases) van Encryption Consulting raadplegen.

Naast onze CertSecure Manager bieden we ook PKI-as-a-Service aan voor organisaties die de aanzienlijk toegenomen belasting van certificaatuitgiften als gevolg van de 47-daagse geldigheidsduur moeten verwerken zonder hun interne PKI-infrastructuur te hoeven bouwen of te herzien. Het biedt een volledig beheerde PKI die is ontworpen om mee te schalen met de nieuwe vernieuwingsfrequentie. Naarmate de certificaatuitgiftesnelheid in 2029 toeneemt, zullen organisaties met een onderbemande interne CA-infrastructuur te maken krijgen met uitdagingen op het gebied van doorvoer en beschikbaarheid. PKI-as-a-Service neemt deze belasting over zonder dat interne infrastructuurwijzigingen nodig zijn, waardoor uw team zich kan concentreren op governance en compliance in plaats van op CA-activiteiten.

CBOM Secure is een ander product van Encryption Consulting voor cryptografische detectie en inventarisatie, waarmee u de roadmap voor de 47-daagse overstap naar TLS-certificaten kunt realiseren en uitvoeren. Voordat u certificaten kunt automatiseren, moet u precies weten welke cryptografische assets er in uw omgeving aanwezig zijn. CBOM Secure detecteert elk certificaat in uw infrastructuur, zodat u precies weet wat er vóór elke deadline geautomatiseerd moet worden beheerd. Lees meer over waarom de meeste cryptografische inventarissen dit risico over het hoofd zien in het artikel " De cryptografische blinde vlek in uw eigen infrastructuur".

Conclusie

Het besluit van het CA/Browser Forum om de geldigheidsduur van TLS-certificaten tegen maart 2029 te verkorten tot 47 dagen is de meest ingrijpende verandering in het beheer van de certificaatlevenscyclus in meer dan een decennium. Nu fase 1 al is voltooid en fase 2 in maart 2027 van start gaat, is de 47-dagenlimiet in 2029 nog maar een kwestie van maanden in de planning voor de infrastructuur.

De organisaties die deze fasen begrijpen en soepel toepassen, zijn de organisaties die certificaatlevenscyclusbeheer beschouwen als een geautomatiseerde, gemonitorde, centraal beheerde en continu geteste infrastructuur in plaats van een periodieke administratieve taak. Organisaties die wachten tot elke fase zich voordoet, zullen te maken krijgen met terugkerende operationele crises, die steeds vaker voorkomen naarmate de geldigheidsperioden korter worden.

Bij Encryption Consulting staan ​​we klaar om u bij elke stap van dit traject te helpen. Het is nu de tijd om deze infrastructuur op te bouwen, voordat fase 2 de hiaten pijnlijk en moeilijk beheersbaar maakt.

Veelgestelde Vragen / FAQ

Wat is de regel van het CA/Browser Forum met betrekking tot de geldigheidsduur van certificaten van 47 dagen?

Stemming SC-081v3, goedgekeurd door het CA/Browser Forum in april 2025, verkort de maximale geldigheidsduur van publiekelijk vertrouwde TLS-certificaten van 398 dagen naar 47 dagen op 15 maart 2029. De verkorting vindt plaats in drie stappen: 200 dagen vanaf 15 maart 2026, 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029. Alle grote browserleveranciers, waaronder Apple, Google, Microsoft en Mozilla, stemden voor.

Moeten certificaten die vóór een bepaalde fase-deadline zijn afgegeven, eerder worden vervangen?

Nee. Een certificaat dat vóór de ingangsdatum van een fase is afgegeven, behoudt zijn oorspronkelijke geldigheidsperiode tot het vanzelf verloopt. De nieuwe maximale geldigheidsperiode geldt alleen voor certificaten die op of na elke deadline zijn afgegeven of verlengd, dus er is geen respijtperiode voor nieuwe afgiften, maar bestaande certificaten worden niet met terugwerkende kracht verkort.

Wat is hergebruik van domeincontrolevalidatie (DCV) en waarom is dat hier relevant?

DCV-hergebruik geeft aan hoe lang een certificeringsinstantie kan vertrouwen op een eerdere controle van domeineigendom in plaats van deze opnieuw te verifiëren alvorens een nieuw certificaat uit te geven. SC-081v3 verkort deze hergebruiksperiode, net als de certificaatvaliditeit, tot slechts 10 dagen in maart 2029. Hierdoor wordt geautomatiseerde, op ACME gebaseerde domeinvalidatie een praktische vereiste in plaats van een luxe.

Is de 47-dagenregel ook van toepassing op interne of particuliere certificaten?

Nee. SC-081v3 regelt alleen publiekelijk vertrouwde TLS-certificaten, dat wil zeggen certificaten die zijn uitgegeven door certificeringsinstanties (CA's) in browserrootprogramma's voor servers die toegankelijk zijn via internet. Privé- of interne PKI's, die uitsluitend binnen een bedrijfsnetwerk worden gebruikt, vallen niet onder de basisvereisten van het CA/Browser Forum en kunnen langere geldigheidsperioden blijven hanteren, hoewel veel organisaties ervoor kiezen om hun interne beleid af te stemmen op het publieke schema voor consistentie.

Hoe moeten organisaties zich voorbereiden op 47-daagse certificaten?

Begin met een volledige inventarisatie van alle openbare TLS-certificaten die in gebruik zijn, aangezien niet-bijgehouden certificaten de meest voorkomende oorzaak zijn van verlopen certificaten. Ga vervolgens over op geautomatiseerde uitgifte en verlenging via ACME, stel verlengingswaarschuwingen in die in elke fase worden afgeschaald en pak eventuele verouderde systemen aan, zoals vastgezette of in firmware ingebedde certificaten, die niet kunnen deelnemen aan geautomatiseerde verlenging.