Lessen uit de massale intrekking van certificaten door DigiCert

Kort antwoord: In juli 2024 trok DigiCert meer dan 83,000 TLS-certificaten in bij ongeveer 6,800 klanten met een opzegtermijn van 24 uur, nadat een fout in de domeinvalidatie van vijf jaar was ontdekt. ​​De les: certificaatlevenscyclusbeheer kan niet afhankelijk zijn van handmatige controle, en de foutmarge wordt steeds kleiner naarmate het CA/Browser Forum de maximale certificaatvaliditeit tegen 2029 terugbrengt tot 47 dagen.

De meeste bedrijven beschouwen een incident met een certificeringsinstantie als een probleem van iemand anders, totdat ze zelf halsoverkop certificaten moeten vervangen in hun productiesystemen, zonder enige waarschuwing. De massale intrekking van certificaten door DigiCert bracht zo'n 6,800 organisaties in precies die positie. Sommige bedrijven hadden een paar uur werk voor de boeg. Anderen hadden duizenden certificaten verspreid over systemen die nog niet volledig in kaart waren gebracht, en geen manier om te weten welke certificaten als eerste zouden uitvallen.

De specifieke bug die DigiCert ontdekte is minder belangrijk dan wat het aan het licht bracht: certificaatinventarissen die alleen in spreadsheets bestaan, verlengingsprocessen die afhankelijk zijn van één engineer die zich een vervaldatum herinnert, en geen tools die binnen een dag antwoord kunnen geven op de vraag "welke certificaten hebben we nu eigenlijk, en waar?". Deze tekortkomingen verdwijnen niet zomaar uit de media en worden steeds duurder naarmate de branche de levensduur van certificaten verkort.

Samenvatting

De massale intrekking van certificaten door DigiCert in juli 2024 dwong ongeveer 6,800 klanten om meer dan 83,000 certificaten binnen 24 uur te vervangen. Elke certificeringsinstantie kan een dergelijke paniekreactie veroorzaken volgens de regels van het CA/Browser Forum. De druk neemt alleen maar toe: op 11 april 2025 keurde het CA/Browser Forum voorstel SC-081v3 goed, waarmee de maximale geldigheidsduur van openbare TLS-certificaten wordt teruggebracht tot 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029 (bron: CA/Browser Forum-voorstel, via Sectigo). Uit DigiCerts eigen Trust Pulse Survey van juli 2025 bleek dat 45% van de organisaties het afgelopen jaar te maken had met certificaatgerelateerde downtime, waarvan 37.5% te wijten was aan een verlopen certificaat (bron: DigiCert Trust Pulse Survey, juli 2025). Het dichten van die kloof begint met certificaatdetectie : een organisatie die niet kan inventariseren wat ze bezit, kan een intrekkingstermijn van 24 uur niet overleven. Vervolgens zorgt certificaatautomatisering ervoor dat de verlenging op schema blijft naarmate de geldigheidsperiodes korter worden. Dezelfde discipline strekt zich verder uit. Crypto-flexibiliteit en PQC-gereedheid zijn beide afhankelijk van dezelfde basis: een live CBOM die certificaatzichtbaarheid omzet in een continue operationele mogelijkheid in plaats van een eenmalige momentopname.

Ga direct naar: Belangrijkste conclusies | Geldigheidsperiode van 47 dagen | Impact per team | Routekaart voor gereedheid | Hoe encryptieconsultancy kan helpen | Veelgestelde vragen

Key Takeaways

• DigiCert heeft in juli 2024 meer dan 83,000 certificaten van ongeveer 6,800 klanten ingetrokken nadat een kwetsbaarheid in de domeinvalidatie, die al sinds 2019 bestond, was ontdekt. ​​De intrekking vond plaats binnen 24 uur, een deadline die was gesteld aan de naleving van de regelgeving.
• Het door het CA/Browser Forum goedgekeurde schema verkort de maximale geldigheidsduur van openbare TLS-certificaten van 398 dagen nu naar 200 dagen op 15 maart 2026, 100 dagen op 15 maart 2027 en 47 dagen op 15 maart 2029.
• Uit de eigen Trust Pulse Survey van DigiCert uit juli 2025 bleek dat 45% van de organisaties het afgelopen jaar te maken heeft gehad met uitval als gevolg van certificaatproblemen, en dat 37.5% een storing specifiek kon herleiden tot een verlopen certificaat.
• Handmatige certificaatregistratie, spreadsheets, agendaherinneringen en informele kennis kunnen de vernieuwingscyclus van 47 dagen in een multi-cloud of hybride PKI-omgeving niet bijbenen.
• Geautomatiseerde detectie, gecentraliseerd inzicht en beleidsgestuurde vernieuwing zijn niet langer optimalisatieprojecten; ze vormen de basisvereiste om de volgende massale intrekking te voorkomen, ongeacht wie de certificeringsinstantie is.

Wat is er gebeurd bij de massale intrekking van DigiCert-certificaten?

Op 29 juli 2024 maakte DigiCert bekend dat het een reeks TLS- certificaten zou intrekken nadat was gebleken dat sommige certificaten waren uitgegeven met een onjuist uitgevoerde domeincontrolevalidatie . Volgens de regels van het CA/Browser Forum heeft een certificeringsinstantie die dit soort validatiefout ontdekt 24 uur de tijd om de betreffende certificaten in te trekken, zonder uitzonderingen. DigiCert had aanvankelijk een deadline van 30 juli gesteld en deze later verlengd tot 3 augustus 2024 om 19:30 UTC, omdat het bedrijf een ongebruikelijk groot aantal getroffen certificaten moest verwerken.

De domeinvalidatiefout

De oorzaak bleek terug te voeren op een systeemwijziging uit 2019. Een van DigiCert's methoden voor domeincontrolevalidatie vereist dat een klant een DNS CNAME-record publiceert met een willekeurige waarde, voorafgegaan door een underscore om conflicten met bestaande domeinnamen te voorkomen. Een update van dat systeem in 2019 zorgde ervoor dat de underscore in bepaalde gevallen niet meer werd toegevoegd. Deze tekortkoming bleef onopgemerkt tijdens meerdere regressietests, omdat die tests het workflowgedrag controleerden en niet de structuur van de gegenereerde waarde. DigiCert ontdekte de fout pas in juli 2024 tijdens het onderzoek naar een ongerelateerde melding. Tegen die tijd had het al gevolgen voor validaties van ongeveer vijf jaar terug.

De 24-uurs scramble

Omdat de fout betrekking had op de validatie en niet op de uitgifte zelf, had DigiCert geen zeggenschap over de timing. Elk getroffen certificaat moest binnen één werkdag worden vervangen, ongeacht hoe cruciaal het systeem erachter was. Sommige organisaties met certificaten op publiek toegankelijke infrastructuur of embedded apparaten vroegen om uitstel, maar dit werd geweigerd, omdat de basisvereisten van het CA/Browser Forum geen uitzonderingen toestaan ​​voor operationele problemen. Een handvol klanten spande een rechtszaak aan om de intrekking van specifieke certificaten te vertragen. Onafhankelijke scans door beveiligingsonderzoekers toonden aan dat tienduizenden getroffen certificaten weken na de deadline nog steeds actief waren op publiek toegankelijke servers, wat aantoont hoe ongelijkmatig de daadwerkelijke herstelsnelheid was onder de getroffen klanten.

De echte les: het niet behalen van certificaten is een systemisch risico, geen incidenteel geval.

Het is verleidelijk om dit af te doen als "DigiCert had een slechte maand" en verder te gaan. Maar die interpretatie gaat voorbij aan de kern van de zaak. Elke certificeringsinstantie kan een validatiefout ontdekken die leidt tot massale intrekking van certificaten met vrijwel geen waarschuwing, omdat de 24-uursregel een algemene vereiste is van de CA's en het Browser Forum, en niet een beleid van DigiCert. De organisaties die zich in 2024 snel herstelden, waren niet de organisaties met de minste certificaten. Het waren de organisaties die al, zonder paniek, precies wisten welke certificaten ze hadden, waar elk certificaat zich bevond en wie de eigenaar was. Dat is het daadwerkelijke verschil, en het heeft niets te maken met welke CA een organisatie gebruikt.

De geldigheidsduur van uw certificaat van 47 dagen die u in de gaten moet houden.

Het DigiCert-incident vond plaats toen de maximale geldigheidsduur van certificaten nog 398 dagen was. Die marge verdwijnt. Op 11 april 2025 stemde het CA/Browser Forum in met een voorstel, oorspronkelijk ingediend door Apple en gesteund door Sectigo, om de maximale geldigheidsduur van openbare TLS-certificaten geleidelijk te verlagen naar 47 dagen in 2029. Elke fase verkort ook de periode waarin domeincontrolevalidatie kan worden hergebruikt, waardoor de operationele deadline voor het opnieuw valideren van domeineigendom steeds korter wordt, parallel aan de kortere levensduur van het certificaat zelf.

Ingangsdatum	Maximale geldigheid	Wie wordt hierdoor getroffen?	Actie nodig	Bron
15 maart 2026	200 dagen	Elke organisatie die openbare TLS-certificaten uitgeeft of verlengt.	Ga over op een vernieuwingsfrequentie van ongeveer elke zes maanden; controleer of uw CA- en ACME-gereedschappen de kortere hergebruiksperiode ondersteunen.	CA/Browser Forum-stemming, via Sectigo
15 maart 2027	100 dagen	Teams die nog steeds afhankelijk zijn van handmatige uitgifte of kwartaalvernieuwingscycli	Zorg dat geautomatiseerde verlenging ruim vóór deze datum actief is; handmatige processen kunnen een frequentie van ongeveer eens per kwartaal op bedrijfsniveau niet bijhouden.	CA/Browser Forum-stemming, via Sectigo
15 maart 2029	47 dagen	Alle publiek toegankelijke TLS-infrastructuur, inclusief multi-cloud- en hybride PKI-omgevingen.	Het uitgeven, verlengen en implementeren van certificaten moet volledig geautomatiseerd zijn; maandelijkse handmatige verlenging op grote schaal is operationeel niet haalbaar.	CA/Browser Forum-stemming, via Sectigo

Beleidsbron: Het schema van 47 dagen is afkomstig van een stemming van het CA/Browser Forum op 11 april 2025, die publiekelijk is onderschreven en gedocumenteerd in de officiële aankondiging van Sectigo . Beschouw het CA/Browser Forum en de nalevingsverklaringen van uw eigen certificeringsinstantie als de bron van waarheid voor deze tijdlijn, aangezien de vereisten voor het rootprogramma van de browser de handhavingsdetails kunnen aanpassen naarmate elke fase nadert.

Wie is de eigenaar? Impact en actie van het team.

Een massale intrekking of een verlengingscyclus van 47 dagen komt niet op het bureau van één team terecht. Het raakt de PKI-, beveiligings-, platform- en compliancefuncties op verschillende manieren, en elk vereist een aparte actie, geen gezamenlijke memo.

Team	Wat verandert er voor hen?	Onmiddellijke actie
PKI-team	Certificaatsjablonen, uitgifteprocessen en CA-relaties moeten allemaal een veel kortere geldigheidsperiode aankunnen zonder handmatige hergoedkeuring in elke cyclus.	Controleer elk uitgifteproces op handmatige goedkeuringsstappen die niet schaalbaar zijn voor een cyclus van 47 dagen.
Beveiligingsteam	Een kortere geldigheidsduur van certificaten verkleint de periode waarin een gestolen of verkeerd uitgegeven sleutel bruikbaar blijft, wat het doel is, maar het betekent ook dat snellere detectie nu een belangrijke factor is bij incidentafhandeling.	Zorg ervoor dat de logboekregistratie voor certificaattransparantie wordt gecontroleerd, zodat ongeautoriseerde of schaduwcertificaten binnen enkele uren, en niet weken, aan het licht komen.
Platform- en infrastructuurteam	Elke service, load balancer, API gateway en intern eindpunt dat een certificaat gebruikt, heeft een geautomatiseerd vernieuwings- en implementatieproces nodig, geen handleiding.	Inventariseer welke systemen nog steeds een menselijke tussenkomst vereisen voor het installeren van een vernieuwd certificaat, en geef prioriteit aan deze systemen voor automatisering.
Nalevingsteam	Auditbewijs voor certificaatbeheer moet een continu actuele inventarisatie weerspiegelen, en niet een momentopname in een spreadsheet die vlak voor een beoordeling is samengesteld.	Zorg ervoor dat uw certificateninventaris op verzoek auditklaar bewijsmateriaal kan leveren, en niet alleen na een handmatige verzameling.

Handmatig certificaatbeheer is nu een bedrijfsrisico, niet langer alleen een IT-taak.

Uit eigen onderzoek van DigiCert blijkt dit. In de Trust Pulse Survey van juli 2025 meldde DigiCert dat 45% van de organisaties in het voorgaande jaar te maken had gehad met serviceonderbrekingen als gevolg van certificaatgerelateerde incidenten, en 37.5% schreef een storing specifiek toe aan een verlopen certificaat, een van de meest te voorkomen storingen in bedrijfsinfrastructuren. Meer dan de helft van de respondenten gaf bovendien aan dat ze er niet zeker van waren dat ze de vervaldatums van certificaten in hun omgeving konden bijhouden. Dit is geen incidenteel probleem, maar de meest voorkomende situatie.

• Verlopen of onjuist uitgegeven certificaten veroorzaken storingen die klanten ervaren als een storing van uw kant, en niet als een probleem van uw certificeringsinstantie.
• Handmatige registratie kan niet betrouwbaar worden opgeschaald van een jaarlijkse of 398-daagse verlengingscyclus naar een cyclus van 47 dagen zonder het personeelsbestand oneindig uit te breiden.
• Een inventaris op basis van een spreadsheet kan niet snel genoeg antwoord geven op de vraag "welke certificaten hebben we momenteel?" om binnen een nalevingsperiode van 24 uur te kunnen reageren op een massale intrekking van certificaten.
• Compliancekaders zoals DORA en PCI DSS vereisen steeds vaker een continu actuele certificatenlijst, in plaats van een handmatig samengestelde lijst die vóór elke audit wordt opgesteld.

Waar automatisering de spelregels verandert

Dit is precies de lacune die CertSecure Manager wil dichten. Geautomatiseerde detectie vindt certificaten in uw hele omgeving in plaats van dat u erop moet vertrouwen dat iemand zich herinnert dat ze bestaan. Een gecentraliseerd dashboard biedt PKI-, beveiligings- en platformteams hetzelfde realtime overzicht van welke certificaten zijn uitgegeven, welke verlopen en welke al verlopen zijn. Beleidsgestuurde verlenging en intrekking via ACME, SCEP en EST betekent dat een cyclus van 47 dagen, of een plotselinge massale intrekking van een certificeringsinstantie, een routineuze, geautomatiseerde gebeurtenis wordt in plaats van een noodsituatie waarbij alle medewerkers moeten reageren.

Certificaatlevenscyclusbeheer in multi-cloud- en hybride PKI-omgevingen

Multicloud- en hybride PKI-omgevingen verhogen de risico's nog verder, omdat certificaten vaak via verschillende tools in elke omgeving worden uitgegeven en beheerd: een proces voor AWS-certificaten, een ander voor on-premises Microsoft CA-certificaten en weer een ander voor certificaten die zijn ingebed in SaaS-integraties. Een massale intrekking of een korte verlengingsperiode legt alle knelpunten tussen deze tools in één klap bloot. Door te standaardiseren op één certificaatbeheerlaag die certificaten in de cloud, on-premises en hybride infrastructuur detecteert en beheert via een gemeenschappelijke API, is het niet langer nodig om vier afzonderlijke handmatige processen te coördineren tijdens een incident. Het betekent ook dat een verlengingscyclus van 47 dagen consistent overal wordt afgedwongen, in plaats van alleen in de omgeving die uw team het meest nauwlettend in de gaten houdt.

Een stappenplan opstellen voor de voorbereiding op certificering

Noch een massale intrekking van licenties, noch de deadline van 47 dagen is iets wat je in één sprint oplost. Beschouw de voorbereiding als een gefaseerd programma met een duidelijke startchecklist en een realistische volgorde.

Checklist voor gereedheid

• Een volledig en actueel overzicht van alle openbare en particuliere certificaten, inclusief certificaten die zijn uitgegeven buiten uw primaire relatie met een certificeringsinstantie.
• Aan elk certificaat is een eigenaar toegewezen, niet alleen aan elk systeem.
• Automatische verlenging is ingeschakeld voor ten minste uw meest gebruikte en bedrijfskritische certificaten.
• Logboekbewaking voor certificaattransparantie is actief voor uw primaire domeinen.
• Een beproefd draaiboek voor een noodscenario met massale intrekking van de intrekking van de intrekking van de intrekking, los van uw standaard verlengingsprocedure.
• Auditklare rapportages die op aanvraag kunnen worden gegenereerd, in plaats van handmatig te worden samengesteld vóór elke beoordelingscyclus.

Een realistische uitrolsequentie

1. Voer eerst een inventarisatie uit van uw gehele vastgoedportefeuille. U kunt niet automatiseren wat u nog niet hebt gevonden.
2. Automatiseer de verlenging van uw certificaten met het hoogste risico en de meeste gebruikers, voordat u de vele certificaten met een lage prioriteit aanpakt.
3. Breid geautomatiseerde vernieuwing en implementatie uit naar multi-cloud- en hybride omgevingen, zodat geen enkele omgeving de zwakke schakel wordt.
4. Stel een noodplan voor intrekking op en test het voordat je het nodig hebt, niet tijdens een deadline van 24 uur.
5. Verplaats het genereren van auditbewijsmateriaal naar hetzelfde platform, zodat compliance-rapportage geen apart, handmatig project meer is.

Meetgegevens die bewijzen dat het programma werkt

De gereedheid is geen eenmalige projectstatus. Houd deze status na de implementatie continu bij:

• Percentage van certificaten die automatisch versus handmatig worden verlengd.
• Aantal storingen of bijna-storingen als gevolg van certificaatproblemen per kwartaal.
• Gemiddelde tijd vanaf het moment dat een certificaat wordt gevonden tot het moment dat een eigenaar wordt aangewezen.
• De tijd die nodig is om op verzoek een complete en actuele inventaris van certificaten te produceren.
• Gemiddelde tijd om een ​​certificaat in te trekken en te vervangen in een noodsituatie.

Dit in verband brengen met crypto-wendbaarheid en PQC-gereedheid.

De discipline die nodig is voor de levenscyclus van certificaten vormt ook de basis voor wat daarna komt. Crypto-flexibiliteit , de mogelijkheid om cryptografische algoritmen en certificaten te wisselen zonder een systeemherziening, is afhankelijk van de kennis van wat je hebt en de mogelijkheid om dit snel aan te passen. Dat is precies de vaardigheid die je ontwikkelt met een vernieuwingscyclus van 47 dagen. Dezelfde geautomatiseerde inventarisatie en ontdekking dragen ook direct bij aan de planning voor post-quantum gereedheid : een cryptografische materiaallijst geeft je het inzicht op algoritmeniveau dat nodig is om een ​​PQC-migratie te plannen , en het omzetten van die inventarisatie in een continue operationele capaciteit in plaats van een eenmalige momentopname zorgt ervoor dat zowel je certificaatprogramma als je tijdlijn voor quantum gereedheid realistisch blijven in plaats van ambitieus.

Hoe encryptieconsultancy kan helpen

Encryption Consulting werkt samen met PKI-, beveiligings- en compliance-teams om precies de hiaten te dichten die een massale intrekking van certificaten aan het licht brengt. CertSecure Manager automatiseert de detectie, uitgifte, verlenging en intrekking van certificaten in cloud-, on-premises- en hybride omgevingen vanuit één dashboard. Zo wordt een compliance-deadline van 24 uur of een verkorte verlengingscyclus van 47 dagen een routineproces in plaats van een noodsituatie. Ons PKI-adviessteam kan uw huidige certificatenportfolio auditeren, hiaten in eigendom en automatisering identificeren en u helpen bij het opstellen van het hierboven beschreven gereedheidsplan. En waar certificaatgereedheid samenhangt met post-quantumplanning, helpt onze PQC-adviespraktijk, inclusief een gestructureerde migratiemethodologie, u bij het sequentiëren van die werkzaamheden met behulp van dezelfde inventarisgegevens in plaats van helemaal opnieuw te beginnen.

Conclusie

De massale intrekking van DigiCert-certificaten in 2024 is jaren geleden opgelost, maar de omstandigheden die het zo pijnlijk maakten, zijn niet verdwenen, sterker nog, ze zijn strenger geworden. Een certificaat met een geldigheidsduur van 398 dagen gaf teams een ruime marge voor handmatige fouten. Een certificaat met een geldigheidsduur van 47 dagen biedt die marge niet. Organisaties die certificaatlevenscyclusbeheer beschouwen als een continue, geautomatiseerde infrastructuur, in plaats van een achtergrondtaak die alleen in crisissituaties wordt aangepakt, zullen de volgende massale intrekking van certificaten, ongeacht de certificeringsinstantie, als een non-event ervaren. De organisaties die nog steeds vertrouwen op spreadsheets en agendaherinneringen zullen juli 2024 met een veel korter lontje herbeleven.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste les die we kunnen trekken uit de massale intrekking van certificaten door DigiCert?

De belangrijkste les is dat elke certificeringsinstantie gedwongen kan worden tot een massale intrekking met slechts 24 uur voorafgaande kennisgeving, op grond van de regels van het CA/Browser Forum. Organisaties die al een volledig en actueel certificaatoverzicht hadden, herstelden zich snel. Organisaties die afhankelijk waren van handmatige registratie raakten in de problemen, en sommige hadden weken na de deadline nog steeds onbeveiligde certificaten actief op openbare servers.

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

Certificaatlevenscyclusbeheer bepaalt of een intrekking een routinematige geautomatiseerde reactie is of een noodsituatie waarbij alle medewerkers moeten ingrijpen. Naarmate het CA/Browser Forum de maximale geldigheidsduur van certificaten tegen 2029 terugbrengt tot 47 dagen, neemt de operationele marge voor handmatige processen steeds verder af. Hierdoor wordt geautomatiseerd levenscyclusbeheer een basisvereiste in plaats van een optionele upgrade.

Welke teams zijn verantwoordelijk voor de uitvoering van deze richtlijnen?

De teams die zich bezighouden met PKI, beveiliging, platform en infrastructuur, en compliance hebben elk een eigen rol hierin. PKI-teams hebben workflows nodig voor certificaatuitgifte die kortere geldigheidsperioden ondersteunen, beveiligingsteams hebben snellere monitoring van de transparantie van certificaten nodig, platformteams hebben geautomatiseerde verlenging en implementatie nodig, en compliance-teams hebben een auditklare inventaris nodig die op aanvraag beschikbaar is.

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

Handmatig certificaatbeheer vergroot het risico op storingen door verlopen certificaten. Uit een onderzoek van DigiCert uit juli 2025 bleek dat 37.5% van de organisaties dit al had ondervonden. Daarnaast leidt het tot een tragere reactie tijdens een noodintrekking, zwakkere auditbewijzen en een grotere kans dat schaduwcertificaten onopgemerkt blijven totdat ze een incident veroorzaken.

Hoe vermindert automatisering het risico op certificaatuitval?

Geautomatiseerde detectie vindt certificaten in een omgeving zonder dat iemand zich hoeft te herinneren dat ze bestaan, terwijl beleidsgestuurde vernieuwing via protocollen zoals ACME, SCEP en EST certificaten vervangt voordat ze verlopen, zonder handmatige tussenkomst. Deze combinatie zorgt ervoor dat een verkorte cyclus van 47 dagen, of een plotselinge massale intrekking, als routinehandelingen kan worden beschouwd in plaats van als een crisis.

Welke meetgegevens moeten teams bijhouden na de implementatie?

Houd het percentage automatisch versus handmatig verlengde certificaten bij, het aantal certificaatgerelateerde storingen of bijna-storingen per kwartaal, de gemiddelde tijd om een ​​eigenaar toe te wijzen aan een nieuw ontdekt certificaat, de tijd om op verzoek een volledige inventaris te genereren en de gemiddelde tijd om een ​​certificaat in te trekken en te vervangen tijdens een noodsituatie.

Hoe hangt dit samen met de gereedheid van het TLS-certificaat binnen 47 dagen?

Het DigiCert-incident is een voorproefje van de operationele druk waarmee elke organisatie permanent te maken krijgt zodra de maximale geldigheidsduur van 47 dagen van het CA/Browser Forum op 15 maart 2029 volledig van kracht wordt. Dezelfde geautomatiseerde detectie-, inventarisatie- en verlengingsmogelijkheden die de schade beperken tijdens een massale intrekking, zijn precies wat een verlengingscyclus van 47 dagen als standaardprocedure vereist.

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

Multicloud- en hybride PKI-omgevingen hebben één centrale laag voor certificaatbeheer nodig die certificaten in alle omgevingen kan detecteren en beheren via een gemeenschappelijke set beleidsregels en API's. Zonder die consolidatie legt een massale intrekking of een verkorte verlengingsperiode de zwakke punten tussen losgekoppelde tools bloot, en wordt de handhaving van een cyclus van 47 dagen inconsistent in de verschillende omgevingen.