Meteen naar de inhoud

Certificaten voor 47 dagen komen eraan. Ben je er klaar voor?

Handel nu →

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

Compliant

CA/Browser Forum-stemming SC-081v3, goedgekeurd in april 2025, verkort de maximale geldigheidsduur van publiekelijk vertrouwde TLS-certificaten van 398 dagen naar 47 dagen op 15 maart 2029, in drie fasen. Als uw organisatie nog steeds afhankelijk is van handmatige verlengingsworkflows, agendaherinneringen of andere menselijke processen om de vervaldatum van certificaten bij te houden, klopt de operationele berekening niet meer voordat de laatste fase aanbreekt. De vereiste eerste actie is een volledige inventarisatie van de certificaten: u kunt niet automatiseren wat u niet kunt vinden.

Kort antwoord: Wat is de 47-dagen TLS-certificaatplicht?

CA/Browser Forum-stemming SC-081v3 verkort de maximale geldigheidsduur van TLS-certificaten van 398 dagen naar 47 dagen op 15 maart 2029, in drie fasen: 200 dagen vanaf 15 maart 2026 (reeds van kracht), 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029. Het hergebruik van domeincontrolevalidatie (DCV) wordt volgens hetzelfde schema verkort tot 10 dagen in 2029. Handmatige verlengingsprocessen zijn niet compatibel met dit schema. Automatisering op basis van ACME is vereist.

Key Takeaways

  • CA/Browser Forum-stemming SC-081v3 verkort de maximale geldigheidsduur van 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. Fase 1 is reeds van kracht.
  • De hergebruiksperioden voor domeincontrolevalidatie (DCV) nemen volgens hetzelfde schema af en bereiken in 2029 slechts 10 dagen. Hierdoor wordt geautomatiseerde domeinvalidatie op basis van ACME een harde operationele vereiste, en geen optimalisatie.
  • 72% van de organisaties heeft de afgelopen 12 maanden minstens één storing gehad die verband hield met certificaten, en slechts 34% heeft een volledig en actueel overzicht van hun eigen certificaten. Het schema van 47 dagen comprimeert diezelfde werklast tot cycli die zes keer korter zijn.
  • Handmatige verlenging en agendaherinneringen zijn niet geschikt voor certificaten met een geldigheidsduur van 47 dagen. ACME-gebaseerde automatisering, verificatie van de implementatie en een centrale certificaatinventaris zijn nu basisvereisten.
  • Certificaatpinning is fundamenteel onverenigbaar met een geldigheidsduur van 47 dagen. Omgevingen die pinning gebruiken, moeten vóór maart 2029 overstappen op standaard CA-gebaseerde vertrouwensverificatie.
  • Het probleem van het niet-implementeren van een certificaat, waarbij een vernieuwd certificaat wel wordt verkregen maar niet wordt geïmplementeerd, is een kritieke foutmodus bij een geldigheidsduur van 47 dagen. Automatisering moet daarom verificatie na implementatie omvatten.

Wat is er veranderd aan stembiljet SC-081v3 en wanneer gaat elke fase in?

Stemming SC-081v3 werd oorspronkelijk in januari 2025 door Apple voorgesteld. Het CA/Browser Forum keurde het op 11 april 2025 goed, met 25 certificeringsinstanties die voor stemden en geen enkele tegen. Alle vier de grote browserleveranciers, Apple, Google, Microsoft en Mozilla, stemden voor. De periode voor de beoordeling van de intellectuele eigendomsrechten werd op 13 mei 2025 afgesloten zonder bezwaren, waardoor de stemming vanaf die datum volledig van kracht is.

Het voorstel wijzigt twee onderdelen van de CA/Browser Forum TLS Baseline Requirements:

  • Sectie 6.3.2: Stelt het gefaseerde schema vast voor het verkorten van de maximale geldigheidsduur van TLS-certificaten.
  • Sectie 4.2.1: Hiermee wordt het parallelle schema vastgesteld voor het verkorten van de periode waarin bewijsmateriaal voor domeincontrolevalidatie (DCV) opnieuw kan worden gebruikt tussen certificaatuitgiften.

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

FaseIngangsdatumMaximale geldigheidsduur van het TLS-certificaatMaximale DCV-hergebruikperiodeHuidige status
Fase 115 maart 2026200 dagen200 dagenVan kracht. Elk nieuw TLS-certificaat dat op of na deze datum wordt uitgegeven, heeft een maximale geldigheidsduur van 200 dagen.
Fase 215 maart 2027100 dagen100 dagenBinnenkort. De verlengingsfrequentie is verdubbeld ten opzichte van fase 1.
Fase 315 maart 202947 dagen10 dagenBinnenkort. Certificaten worden ongeveer elke 6 weken vernieuwd. DCV moet bij vrijwel elke verlenging opnieuw worden geverifieerd.
CA/Browser Forum SC-081v3 gefaseerd geldigheidsschema. Certificaten die vóór de deadline van elke fase zijn uitgegeven, behouden hun oorspronkelijke geldigheidsperiode. Er geldt geen respijtperiode voor certificaten die op of na de deadline zijn uitgegeven.

Domeincontrolevalidatie (DCV) is het proces dat een certificeringsinstantie gebruikt om te verifiëren dat een certificaataanvrager de eigenaar is van het aangevraagde domein. Historisch gezien kon dit gevalideerde bewijs tot 398 dagen worden hergebruikt. SC-081v3 verkort deze hergebruiksperiode tot slechts 10 dagen tegen maart 2029, wat betekent dat het domeineigendom bij bijna elke certificaatvernieuwing opnieuw moet worden geverifieerd. Voor een gedetailleerde handleiding over het automatiseren van de DCV-stap, zie onze gids voor persistente DCV en DNS-connectoren.

Waarom heeft het CA/Browser Forum deze beslissing genomen?

De trend naar kortere geldigheidsduur van certificaten is al meer dan tien jaar gaande. TLS-certificaten waren tot 2015 maximaal vijf jaar geldig. De maximale geldigheidsduur daalde naar drie jaar in 2015, twee jaar in 2018 en 398 dagen in 2020, toen Apple eenzijdig de vertrouwenslimiet voor nieuwe certificaten in Safari invoerde. SC-081v3 zet deze trend voort met een vaste einddatum. Het CA/Browser Forum heeft vier redenen voor deze verandering geformuleerd:

  • De impact van gecompromitteerde certificaten beperken: Wanneer een privésleutel wordt gestolen, een certificaat frauduleus wordt uitgegeven of een ondertekeningsalgoritme zwak blijkt te zijn, is de schade rechtstreeks evenredig met de geldigheidsduur van het certificaat. Een certificaat met een geldigheidsduur van 47 dagen biedt een veel kortere periode waarin het vertrouwen kan worden misbruikt dan een certificaat met een geldigheidsduur van 398 dagen.
  • Het intrekken van de overeenkomst: Certificaatintrekking werkt in de praktijk grotendeels niet goed. Het Online Certificate Status Protocol (OCSP) werkt in de meeste browsers op basis van een 'soft fail', wat betekent dat browsers doorgaan in plaats van de verbinding te blokkeren als de OCSP-responder onbereikbaar is. Lijsten met ingetrokken certificaten (CRL's) worden zelden bijgewerkt en inconsistent gecontroleerd. Let's Encrypt heeft OCSP in 2024 volledig uitgefaseerd en die overgang in 2025 voltooid. Bij een geldigheidsduur van 47 dagen wordt natuurlijke vervaldatum het primaire intrekkingsmechanisme.
  • Het afdwingen van strengere cryptografische procedures: 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 met een geldigheidsduur van 398 dagen tot 2025 in productie blijven. Kortere geldigheidsperioden dwingen tot frequentere uitgifte en frequentere toepassing van de huidige algoritme- en sleutelstandaarden.
  • Het stimuleren van de acceptatie van automatisering: Het CA/Browser Forum heeft expliciet gesteld dat een van de doelen van SC-081v3 is om de invoering van geautomatiseerd certificaatlevenscyclusbeheer af te dwingen. Een certificaat met een geldigheidsduur van 47 dagen dat elke zes weken wordt vernieuwd, is operationeel onverenigbaar met handmatige processen, waardoor automatisering een structurele vereiste is in plaats van een aanbevolen werkwijze.

Wat laten de gegevens zien over de huidige volwassenheid van certificaatbeheer?

De verstoring die SC-081v3 veroorzaakt, is niet hypothetisch. Onderzoek in de sector toont aan dat de markt, met een geldigheidsduur van 398 dagen, al onder druk staat:

  • Volgens het State of Machine Identity Security Report 2025 heeft 72% van de organisaties de afgelopen 12 maanden minstens één storing ondervonden die verband hield met certificaten, en gaf 45% aan dat er wekelijks storingen plaatsvonden. Dit is een stijging ten opzichte van de slechts 12% die in 2022 wekelijkse storingen meldde.
  • Volgens een wereldwijd onderzoek uit 2026 onder meer dan 400 senior IT- en beveiligingsmanagers heeft slechts 34% van de organisaties een volledig en actueel overzicht van hun eigen digitale certificaten, en is bijna driekwart zeer of extreem bezorgd over storingen die worden veroorzaakt door verlopen certificaten.
  • Het aantal machine-identiteiten is nu naar schatting 82 keer zo groot als het aantal menselijke identiteiten, en 79% van de beveiligingsdeskundigen verwacht dat deze verhouding het komende jaar met maar liefst 150% zal toenemen.

Deze cijfers beschrijven een sector die al moeite had met de jaarlijkse verlengingscycli. Het samenpersen van dezelfde werklast in cycli van 47 dagen, met een hergebruikvenster van 10 dagen voor DCV dat domeinherverificatie vereist bij bijna elke verlenging, is iets wat handmatige processen niet aankunnen. Voor meer informatie over hoe de groei van machine-identiteiten dit probleem voor PKI-teams verergert, raadpleegt u onze handleiding voor machine-identiteiten voor PKI-teams.

Wat betekenen 47-dagencertificaten in de praktijk?

De operationele gevolgen van SC-081v3 variëren afhankelijk van de omvang en complexiteit van het certificatenportfolio en de huidige stand van zaken met betrekking tot certificaatbeheer. Drie gebieden zorgen voor de meest consistente operationele uitdagingen:

Inzicht in certificaatinventaris

Je kunt het verlengen van certificaten waarvan je niet weet dat ze bestaan, niet automatiseren. De wildgroei aan certificaten verspreid over meerdere teams, cloudomgevingen, Kubernetes- clusters, CDN-configuraties en legacy-servers is de meest voorkomende oorzaak van problemen met verlopen certificaten. Bij jaarlijkse verlengingscycli kan een niet-ontdekt 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 door externe teams worden beheerd, is de fundamentele voorwaarde voor al het andere.

De kloof tussen vernieuwing en implementatie

Een van de meest voorkomende fouten in geautomatiseerde certificaatomgevingen is de kloof tussen vernieuwing en implementatie: de ACME-client verkrijgt met succes een nieuw certificaat, maar de implementatiestap die het installeert op de betreffende server, load balancer of Kubernetes ingress mislukt zonder dat dit gebeurt. Het vernieuwde certificaat blijft ongebruikt, terwijl het oude certificaat verkeer blijft afhandelen totdat het verloopt. Bij een geldigheidsduur van 47 dagen is deze kloof een kritieke fout. Certificaatvernieuwing moet worden geïntegreerd met een implementatieverificatie die bevestigt dat het nieuwe certificaat daadwerkelijk aan clients wordt aangeboden voordat de vernieuwing als voltooid wordt gemarkeerd.

Verouderde infrastructuur en certificaatpinning

Verouderde applicaties met hardgecodeerde certificaten, IoT-apparaten met in de firmware ingebouwde CA's en omgevingen die gebruikmaken van certificaatpinning, vertegenwoordigen allemaal situaties waarin 47-daagse certificaten uitdagingen creëren die niet alleen met automatisering kunnen worden opgelost. Certificaatpinning, waarbij een client is geconfigureerd om alleen een specifiek certificaat of een publieke sleutel te vertrouwen in plaats van elk certificaat van een vertrouwde CA, is fundamenteel onverenigbaar met een geldigheidsduur van 47 dagen. De enige haalbare aanpak voor omgevingen met certificaatpinning is om vóór maart 2029 over te stappen van certificaatpinning naar standaard CA-gebaseerde vertrouwensverificatie.

Certificaatbeheer

Voorkom certificaatuitval, stroomlijn IT-activiteiten en verhoog uw flexibiliteit met onze oplossing voor certificaatbeheer.

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

De onderstaande vergelijking laat zien waarom handmatige processen niet langer haalbaar zijn voordat fase 3 aanbreekt:

Vereiste geldigheidsduur van 47 dagenHandmatig of kalendergestuurdGeautomatiseerd CLM (ACME + CertSecure Manager)
Verlengingen per certificaat per jaar1 vandaag, oplopend tot 8 of meer in maart 2029.Hetzelfde volume, geen extra personeel.
Domeinvalidatie (hergebruik van DCV gedurende 10 dagen tegen 2029)Voer de test handmatig opnieuw uit bij elke verlengingscyclus.Machine-naar-machine uitdaging-antwoord via ACME-protocollen (HTTP-01, DNS-01)
CertificaatinventarisSpreadsheets, tribale kennis en handmatige scansContinue detectie in de cloud, on-premises en Kubernetes.
kloof tussen vernieuwing en implementatieHet 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 stroomuitvalHoog, 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-rapportageHandmatige logverzameling; inconsistente dekking in verschillende omgevingen.Gecentraliseerde, exporteerbare verlengings- en uitgiftegeschiedenis voor alle omgevingen.
DCV-automatiseringHandmatige voltooiing van de uitdaging; pauze na een hergebruikperiode van 10 dagen.ACME automatiseert de voltooiing van de uitdaging; DNS-connectoren maken persistente DCV mogelijk.
Handmatig certificaatbeheer was al een lastige opgave bij een geldigheidsduur van 398 dagen. Met een geldigheidsduur van 47 dagen en een hergebruiksperiode van 10 dagen voor DCV-certificaten, is het geen haalbare optie meer voor organisaties die meer dan een handvol openbare certificaten beheren.

Hoe moeten organisaties zich voorbereiden op het 47-daagse certificeringsprogramma?

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. De onderstaande zevenstappenreeks geeft de volgorde weer waarin de afhankelijkheden moeten worden opgelost:

  1. Stel een complete certificateninventaris samen: Ontdek alle openbare TLS-certificaten in alle omgevingen en teams. Gebruik Certificate Transparency (CT)-logmonitoring, API's van cloudproviders, netwerkscans en integraties met de beheerconsole van uw CA. CBOM Secure Voert continue cryptografische detectie uit in cloud-, on-premises- en Kubernetes-omgevingen, waardoor u een volledig overzicht krijgt van elk certificaat voordat u iets automatiseert. Dit is de fundamentele stap: alles wat volgt, hangt af van de kennis van uw certificaten. Bewijsmateriaal: een complete inventaris van certificaten met CA, vervaldatum, installatielocatie en eigenaar voor elk certificaat.
  2. Stel verlengingswaarschuwingen in met fasespecifieke aanlooptijden: Bij een geldigheidsduur van minder dan 200 dagen (Fase 1) moeten verlengingswaarschuwingen 60 dagen voor de vervaldatum worden ingesteld. Bij een geldigheidsduur van minder dan 100 dagen (Fase 2) moeten waarschuwingen 30 dagen voor de vervaldatum worden ingesteld. Bij een geldigheidsduur van minder dan 47 dagen (Fase 3) moeten waarschuwingen 25 tot 30 dagen voor de vervaldatum worden geactiveerd, met escalerende waarschuwingen na 14 en 7 dagen. Bewijsmateriaal: CLM-platformwaarschuwingsconfiguratie met drempelwaarden per omgeving en fase.
  3. Standaardiseer ACME voor de afgifte van certificaten: Het Automated Certificate Management Environment (ACME)-protocol (RFC 8555) is het mechanisme dat specifiek is ontworpen voor geautomatiseerde uitgifte en verlenging van certificaten. CertSecure Manager Ondersteunt ACME native naast SCEP- en EST-protocollen en integreert direct met zowel openbare als private CA's. Bewijsmateriaal: implementatiegegevens van ACME-clients; logboeken met succesvolle geautomatiseerde verlengingen waaruit blijkt dat de domeinvalidatie is voltooid.
  4. Elimineer vastgelegde vernieuwingsintervallen: Controleer alle scripts, cronjobs en automatiseringsconfiguraties op vastgelegde verlengingsintervallen zoals 'elke 60 dagen verlengen' of 'elke 90 dagen verlengen'. Vervang deze door dynamische verlengingslogica op basis van de vervaldatum van het certificaat of ACME ARI-signalen (Automatic Renewal Information). Bewijsmateriaal: resultaten van de configuratiecontrole; bijgewerkte automatisering met de op vervaldatum gebaseerde verlengingslogica.
  5. Overbrug de kloof tussen vernieuwing en implementatie: Controleer voor elk certificaat dat onder de scope valt 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 cruciaal in omgevingen waar verlenging en implementatie door aparte systemen of teams worden afgehandeld. Bewijsmateriaal: verificatielogboeken van de implementatie waaruit blijkt dat het aangeboden certificaat overeenkomt met het verlengde certificaat voor elke verlengingsgebeurtenis.
  6. Pak verouderde infrastructuur en certificaatpinning aan: Identificeer alle systemen die niet kunnen deelnemen aan geautomatiseerde verlenging: verouderde servers, in firmware ingebedde certificaten en vastgezette configuraties. Definieer voor elk systeem een ​​migratieplan vóór fase 3. Deze wijzigingen zijn doorgaans het meest tijdrovend en moeten ruim vóór maart 2029 van start gaan. Bewijsstukken: inventaris van de verouderde infrastructuur; migratieplan met verantwoordelijke en streefdatum voor elk systeem; documenten betreffende het verwijderen van certificaatvastlegging.
  7. Stel een gecentraliseerd CLM-bestuur in: Stap over naar een centraal platform voor certificaatlevenscyclusbeheer 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. Bewijsmateriaal: implementatie van het CLM-platform voor alle relevante omgevingen; compliance-rapport met nul certificaten binnen 7 dagen na vervaldatum.

Checklist voor de gereedheidsaudit van TLS na 47 dagen

Gebruik deze checklist om de gereedheid van uw organisatie voor elke fase van SC-081v3 te beoordelen. De items zijn georganiseerd per fase waarin ze cruciaal worden:

Controle gebiedeisKritisch doorbewijsmateriaal artefactStatus
CertificaatinventarisEen complete inventarisatie van alle openbare TLS-certificaten met CA, vervaldatum, installatielocatie en verantwoordelijk team.Nu (Fase 1 van kracht)CLM-inventarisexport of CBOM-beveiligingsrapportNaar actie
Fase 1-nalevingAlle nieuwe TLS-certificaten die op of na 15 maart 2026 worden uitgegeven, hebben een maximale geldigheidsduur van 200 dagen.15 maart 2026 (reeds van kracht)Configuratie van het CA-uitgiftebeleid; certificaatcontrole bevestigt dat er geen nieuwe certificaten zijn uitgegeven die ouder zijn dan 200 dagen.Naar actie
ACME-automatiseringsimplementatieOp ACME gebaseerde geautomatiseerde vernieuwing is geïmplementeerd voor alle openbare TLS-certificaten.Vóór fase 2 (maart 2027)ACME-klantimplementatiegegevens; logboeken met succesvolle geautomatiseerde verlengingenNaar actie
DCV-automatiseringGeautomatiseerde domeincontrolevalidatie die HTTP-01- of DNS-01-uitdagingen kan voltooien zonder handmatige tussenkomst.Vóór fase 2 (maart 2027); cruciaal tegen fase 3 (hergebruikperiode van 10 dagen)ACME-uitdagingslogboeken; DNS-connectorconfiguratieNaar actie
Drempelwaarden voor verlengingswaarschuwingenWaarschuwingsdrempels ingesteld per fase: 60 dagen voor fase 1, 30 dagen voor fase 2, 25 tot 30 dagen voor fase 3.Doorlopend; update bij elke fase.CLM-platformwaarschuwingsconfiguratie; bewijs van waarschuwingsleveringNaar actie
Audit van vastgelegde verlengingsintervallenGeen enkel automatiseringsscript of cronjob gebruikt vastgelegde vernieuwingsintervallen; ze maken allemaal gebruik van vervaldatum- of ACME ARI-logica.Vóór fase 2 (maart 2027)Resultaten van de configuratieaudit; bijgewerkte scripts die de dynamische vernieuwingslogica weergeven.Naar actie
Het dichten van de kloof tussen vernieuwing en implementatie.De automatisering van certificaatvernieuwing omvat verificatie na implementatie om te bevestigen dat het nieuwe certificaat aan de clients is geleverd.Vóór fase 2 (maart 2027)Implementatieverificatielogboeken per verlengingsgebeurtenisNaar actie
Fase 2-nalevingAlle nieuwe TLS-certificaten die op of na 15 maart 2027 worden uitgegeven, hebben een maximale geldigheidsduur van 100 dagen.15 maart 2027Configuratie van het CA-uitgiftebeleid; certificaatcontrole ter bevestiging van de nalevingNaar actie
Migratie van verouderde infrastructuurAlle systemen die gebruikmaken van handmatige certificaatimplementatie, hardgecodeerde certificaten of in de firmware ingebouwde CA's, hebben een gedocumenteerd migratieplan met een streefdatum vóór maart 2029.Vóór fase 3 (maart 2029)Inventarisatie van de bestaande infrastructuur; migratieplan met eigenaar en streefdatum.Naar actie
Verwijdering van certificaatvastleggingGeen enkel productiesysteem maakt gebruik van certificaat- of publieke sleutelpinning voor publiekelijk vertrouwde certificaten.Vóór fase 3 (maart 2029)Audit van de applicatiecode; verwijderingsrecords van vastgezette gegevens; standaard CA-gebaseerde vertrouwensverificatie bevestigd.Naar actie
Fase 3-nalevingAlle nieuwe TLS-certificaten die op of na 15 maart 2029 worden uitgegeven, hebben een maximale geldigheidsduur van 47 dagen; hergebruik van DCV is niet langer dan 10 dagen.15 maart 2029CA-uitgiftebeleid; DCV-automatiseringslogboeken; certificaataudit ter bevestiging van nalevingNaar actie
CLM centrale bestuursstructuurHet gecentraliseerde CLM-platform biedt uniforme inventarisatie, automatisering van verlengingen, implementatieorkestratie en compliance-rapportage voor alle omgevingen.Vóór fase 3 (maart 2029)Dekkingsrapportage CLM-platform; nalevingsrapportage waaruit blijkt dat er binnen 7 dagen na vervaldatum geen certificaten meer zijn.Naar actie
Crypto-flexibiliteit voor authenticatiesystemenHet CLM-platform ondersteunt de uitgifte van post-quantumcertificaten voor toekomstige migratie, naarmate de NIST PQC-standaarden worden overgenomen door rootprogramma's van browsers.Nu plannen; uitvoering tussen 2028 en 2030.Roadmap voor PQC van de leverancier; ondersteuningsdocumentatie voor PQC op het CLM-platformNaar actie
TLS-gereedheidschecklist van 47 dagen, afgestemd op de deadlines van fase SC-081v3. Voeg voltooiingsdata en initialen van de beoordelaars toe voor formele bewijspakketten.

Hoe encryptieconsulting kan helpen bij de overgangsperiode van 47 dagen.

Encryption Consulting is een ISO/IEC 27001:2022 en SOC 2 gecertificeerd bedrijf voor toegepaste cryptografie. Ons portfolio omvat alle onderdelen van de 47-daagse transitie: geautomatiseerd lifecyclemanagement, cryptografische ontdekking, volledig beheerde PKI en gereedheid voor de post-quantummarkt.

  • CertSecure Manager: CertSecure Manager Dit is het certificaatlevenscyclusbeheerplatform van Encryption Consulting en het meest directe operationele 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. Het automatiseert de inschrijving en verlenging op webservers zoals Apache, Tomcat en IIS, en loadbalancers zoals F5 BIG-IP. Verlengingen worden dynamisch geactiveerd op basis van de vervaldatum van certificaten, niet op basis van vastgelegde intervallen, waardoor het inherent compatibel is met elke fase van SC-081v3. Het is gebouwd met crypto-flexibiliteit als kern, waardoor organisaties op een gecontroleerde, gefaseerde manier kunnen migreren naar post-quantumcertificaten naarmate de NIST PQC-standaarden worden overgenomen door browserrootprogramma's. Zie onze Migratiegids voor cryptografie na het kwantumtijdperk voor het volledige migratieplan in negen fasen.
  • CBOM Secure (cryptografische inventaris): CBOM Secure Het systeem detecteert elk certificaat in uw infrastructuur, inclusief cloudaccounts, on-premises omgevingen en Kubernetes-clusters, zodat u precies weet wat er vóór elke deadline geautomatiseerd beheerd moet worden. Dit is de fundamentele stap in de zevenstappenvoorbereiding: u kunt niet automatiseren wat u niet kunt vinden. Zie ook onze handleiding voor De cryptografische blinde vlek die zich in uw eigen infrastructuur schuilhoudt. Daarom ontbreken in de meeste inventarissen cruciale certificaten.
  • PKI als een service: Voor organisaties die de aanzienlijk toegenomen belasting van certificaatuitgifte met een geldigheidsduur van 47 dagen moeten verwerken zonder hun interne PKI-infrastructuur te hoeven herzien, PKI-as-a-Service Biedt een volledig beheerde CA die is ontworpen om mee te schalen met de nieuwe vernieuwingsfrequentie. Naarmate de uitgiftefrequenties tegen 2029 verzesvoudigen, 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 er wijzigingen in de interne infrastructuur nodig zijn.
  • Permanente DCV- en DNS-connectoren: Voor organisaties die de domeinvalidatiestap zelf willen automatiseren, bieden wij een oplossing. permanente DCV- en DNS-connector Deze handleiding behandelt de automatisering van de ACME-uitdaging voor het hergebruikvenster van 10 dagen voor DCV's dat in fase 3 aanbreekt.

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 tien jaar. Fase 1 is al van kracht. Fase 2 begint in maart 2027. De einddatum van 47 dagen in maart 2029 is een vaste deadline die door browsers niet langer zal worden gehandhaafd.

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

Veelgestelde Vragen / FAQ

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

Stemmingsvoorstel SC-081v3, goedgekeurd in april 2025, verkort de maximale geldigheidsduur van publiekelijk vertrouwde TLS-certificaten van 398 dagen naar 47 dagen op 15 maart 2029, in drie fasen: 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. Fase 1 is reeds van kracht.

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. Er is geen respijtperiode: elk certificaat dat op of na 15 maart 2026 is afgegeven, moet voldoen aan de maximale geldigheidsperiode van 200 dagen voor die fase.

Wat is hergebruik van domeincontrolevalidatie (DCV) en waarom is het belangrijk?

DCV-hergebruik bepaalt hoe lang een certificeringsinstantie kan vertrouwen op een eerdere verificatie van domeineigendom voordat nieuw bewijs vereist is. SC-081v3 verkort dit tot 10 dagen tegen maart 2029, wat betekent dat domeineigendom bij vrijwel elke certificaatvernieuwing opnieuw moet worden geverifieerd. Hierdoor wordt geautomatiseerde domeinvalidatie op basis van ACME een harde operationele vereiste in plaats van een gemak.

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

Nee. SC-081v3 is alleen van toepassing op publiekelijk vertrouwde TLS-certificaten die zijn uitgegeven door CA's in browserrootprogramma's. Privé- of interne PKI's vallen niet onder de basisvereisten van het CA/Browser Forum en kunnen langere geldigheidsperioden blijven hanteren. Veel organisaties kiezen ervoor om hun interne beleid af te stemmen op het openbare schema voor consistentie en om de CLM-automatisering te vereenvoudigen.

Wat is certificaatpinning en waarom is het incompatibel met 47-daagse certificaten?

Certificate pinning programmeert een specifiek certificaat of een openbare sleutel in een clientapplicatie of -apparaat. Bij vernieuwingscycli van 47 dagen moet de client bovendien elke zes weken worden bijgewerkt, wat operationeel onhaalbaar is. De enige haalbare oplossing is om vóór maart 2029 over te stappen van certificate pinning naar standaard CA-gebaseerde vertrouwensverificatie.

Wat is de kloof tussen vernieuwing en implementatie en hoe dichten organisaties deze?

De kloof tussen certificaatvernieuwing en -implementatie ontstaat wanneer een nieuw certificaat wordt verkregen maar niet wordt geïmplementeerd, waardoor het oude certificaat het verkeer blijft afhandelen totdat het verloopt. Bij een geldigheidsduur van 47 dagen is dit een kritieke fout. Om dit te verhelpen, moet de automatisering van certificaatvernieuwing een verificatiestap na implementatie bevatten die bevestigt dat het nieuwe certificaat daadwerkelijk in gebruik is voordat de vernieuwing als voltooid wordt gemarkeerd.

Hoe moeten organisaties zich voorbereiden op TLS-certificaten met een geldigheidsduur van 47 dagen?

De zevenstappenprocedure is als volgt: (1) een complete inventaris van certificaten opstellen; (2) fasespecifieke drempelwaarden voor verlengingswaarschuwingen vaststellen; (3) standaardiseren op ACME-automatisering; (4) vastgelegde verlengingsintervallen elimineren; (5) de kloof tussen verlenging en implementatie dichten; (6) de verouderde infrastructuur en certificaatpinning aanpakken; en (7) gecentraliseerd CLM-beheer opzetten. Begin met de inventaris, aangezien elke volgende stap afhankelijk is van de kennis van uw certificaten.