Hoe migreer je één miljoen certificaten naar PKIaaS zonder storingen te veroorzaken?

Een PKI-migratie van een miljoen certificaten klinkt als een project van meerdere jaren dat alleen de grootste bedrijven met speciale PKI-teams zouden kunnen uitvoeren. In de praktijk is het migreren van een miljoen certificaten naar PKI as a Service geen kwestie van een miljoen afzonderlijke bewerkingen. De meeste van die certificaten migreren via hun natuurlijke vernieuwingscyclus, afgehandeld door automatiseringsclients die opnieuw geconfigureerd zijn om vernieuwingen aan te vragen bij PKIaaS in plaats van bij de oude CA. Het migratieprogramma is gericht op het opzetten van die automatisering; de automatisering voert de daadwerkelijke migratie uit.

Het risico op uitval bij een PKI-migratie schuilt niet in het verplaatsen van certificaten, maar in het onjuist verplaatsen ervan: het distribueren van het nieuwe PKIaaS-root-CA-certificaat naar vertrouwensarchieven nadat er al certificaten onder zijn uitgegeven; het produceren van certificaten met onjuiste profielen die door applicaties worden afgewezen; of het intrekken van de oude CA-infrastructuur voordat alle uitgegeven certificaten zijn vervangen. Deze risico's zijn te vermijden met de juiste migratievolgorde.

Dit draaiboek beschrijft de tien fasen van een PKIaaS-migratie op bedrijfsniveau: van de initiële inventarisatie die onthult wat er precies gemigreerd wordt, via de gefaseerde uitrol die overgangsrisico's minimaliseert, tot het beheer na de migratie dat ervoor zorgt dat de oude CA nooit meer terugkomt. De fasen zijn ontworpen om in volgorde te worden uitgevoerd, waarbij de voltooiingscriteria van elke fase de voorwaarde vormen voor de volgende fase.

Kort antwoord: Hoe werkt een PKIaaS-migratie met een miljoen certificaten in de praktijk?

De migratie verloopt in drie operationele modi die gelijktijdig actief zijn. Geautomatiseerde certificaten (die al beheerd worden door cert-manager, ACME-clients, MDM-inschrijving of automatische inschrijving) worden gemigreerd door de automatiseringsclient opnieuw te configureren zodat deze naar het PKIaaS-inschrijvingseindpunt verwijst; de volgende verlengingscyclus voltooit de migratie voor dat certificaat zonder de applicatie aan te raken. Handmatig aangemaakte en verlengde certificaten worden proactief gemigreerd in prioriteitsvolgorde, te beginnen met de certificaten die het snelst verlopen. Certificaten met een lange levensduur die zelden worden verlengd, worden in de passieve verlengingsperiode geplaatst, tenzij de oude CA moet worden uitgefaseerd voordat ze verlopen. Het actieve migratieprogramma duurt 4 tot 9 maanden; de volledige passieve verlengingsperiode voegt daar nog eens 12 tot 18 maanden aan toe voor de resterende certificaten.

Key Takeaways

• De migratie is geen simpele omschakeling. Vertrouwensbronnen kunnen niet direct worden vervangen zonder storingen te veroorzaken; de migratie zorgt ervoor dat de bestaande CA en PKIaaS parallel draaien gedurende de overgangsperiode. De bestaande CA's blijven operationeel en hun CRL/OCSP-infrastructuur blijft actief totdat alle door hen uitgegeven certificaten zijn verlopen of vervangen. Het plannen van deze co-existentieperiode is de eerste ontwerpbeslissing bij elke PKI-migratie.
• Ontdekkingsprocessen brengen altijd meer aan het licht dan het CA-team weet. Netwerkcertificaatdetectie vindt certificaten die zijn uitgegeven door schaduw-CA's, openbare CA's die de interne CA hebben omzeild, verlopen certificaten die nog steeds in gebruik zijn en certificaten met zwakke sleutelparameters. De resultaten van de detectie bepalen wat er daadwerkelijk wordt gemigreerd, wat bijna altijd omvangrijker en complexer is dan de initiële schatting.
• Het in kaart brengen van certificaatprofielen is de meest risicovolle technische voorbereidingsstap. Elke bestaande CA-sjabloon moet worden gereproduceerd als een PKIaaS-certificaatprofiel met de juiste EKU OID's, brontoewijzingen voor onderwerpnamen, geldigheidsperioden en SAN-beperkingen. Een fout in de profieltoewijzing resulteert in een certificaat dat weliswaar succesvol wordt geregistreerd, maar door de applicatie wordt afgewezen, meestal precies op het verkeerde moment.
• Door eerst de onderste 60% van de systemen te automatiseren, wordt het risico met de minste inspanning het meest beperkt. Geautomatiseerde certificaten worden gemigreerd met een configuratiewijziging, niet met een handmatige handeling. Door 600,000 geautomatiseerde certificaten binnen de eerste 30 tot 60 dagen van de uitrol van de oude CA over te zetten, wordt de resterende migratieomvang teruggebracht tot de 400,000 certificaten die daadwerkelijk aandacht vereisen.
• Governance na de migratie is bepalend voor het succes of falen van migraties een jaar later. Een organisatie die de migratie voltooit, maar geen doorlopende automatiseringsdekkingsstatistieken, handhaving van certificaatbeleid en nieuwe controlemechanismen voor certificaatuitgifte implementeert, zal merken dat haar PKI-omgeving binnen 18 maanden terugvalt op handmatige uitgifte en het gebruik van schaduw-CA's.

Fase 1: Ontdekking en inventarisatie (week 1 tot en met 3)

De ontdekkingsfase levert de basisinventaris op waarop alle andere stappen in de migratie gebaseerd zijn. Ga niet verder naar een volgende fase zonder een complete en geverifieerde certificateninventaris. Het ontwerpen van een migratieprogramma op basis van een onvolledige inventaris is de meest voorkomende oorzaak van onverwachte problemen tijdens de migratie die tot storingen leiden.

Voer beide ontdekkingsbronnen gelijktijdig uit:

Ontdekking aan de CA-zijde: Exporteer de database met uitgegeven certificaten van elke CA binnen het toepassingsgebied (interne bedrijfs-CA's, afdelings- of applicatiespecifieke CA's en extern gehoste beheerde PKI-services die al in gebruik zijn). De CA-database bevat de gezaghebbende lijst van uitgegeven certificaten, de vervaldatum en het sjabloon of profiel waarop ze gebaseerd zijn. De database geeft echter geen informatie over waar deze certificaten zijn geïmplementeerd of of ze nog steeds in gebruik zijn.

Netwerk- en hostdetectie: Voer actieve certificaatdetectie uit op alle interne netwerksegmenten om certificaten te vinden op actieve TLS-eindpunten. Scan ook configuratiebeheerdatabases (CMDB's), certificaatarchieven op servers, Kubernetes Secret-archieven, MDM-certificaatinventarissen en applicatieconfiguratiebestanden. Netwerkdetectie vindt wat er daadwerkelijk is geïmplementeerd, inclusief certificaten die niet in de CA-database staan ​​(uitgegeven door andere CA's, zelfondertekende certificaten of certificaten die zijn uitgegeven voordat het CA-systeem operationeel was).

De output van deze twee ontdekkingsrondes genereert de hoofdcertificateninventaris met de volgende kenmerken voor elk certificaat: serienummer, subject DN, SAN's, uitgevende CA, vervaldatum, sleutelalgoritme en -grootte, handtekeningalgoritme, EKU OID's, implementatielocaties (hostnamen, IP-adressen), inschrijvingsprotocol (indien bekend) en eigenaarsteam of -bedrijfseenheid. Deze inventaris is de bron van waarheid voor de migratie. Deze moet worden geladen in het CLM-platform dat de migratie en de omgeving na de migratie beheert.

Het opsporen van certificaten duurt doorgaans 1 tot 3 weken, afhankelijk van de netwerkgrootte en de bereikbaarheid van externe segmenten. Houd rekening met een budget voor het opsporen van ongeveer 20 tot 40% meer certificaten dan de initiële schatting van het CA-team. Schaduw-PKI (zelfondertekende certificaten, certificaten van openbare CA's die zijn aangeschaft zonder tussenkomst van het PKI-team, certificaten uitgegeven door ontwikkelings-CA's die nooit zijn gedeactiveerd) komt veel voor in grote bedrijven en wordt bijna altijd onderschat voordat het opsporingsproces begint.

Fase 2: Segmentatie en prioritering (week 2 tot en met 4)

Na de inventarisatie worden de certificaten opgesplitst in migratiecohorten. Deze opdeling bepaalt de migratievolgorde en de automatiseringsaanpak voor elk cohort.

Cohort A: Verloopt binnen 90 dagen (direct migreren). Elk certificaat dat binnen 90 dagen verloopt, vormt een direct risico op uitval. Deze certificaten krijgen de hoogste migratieprioriteit, ongeacht hun categorie. Als de PKIaaS-infrastructuur nog niet klaar is om verlengingen uit te geven (omdat de root-ceremonie nog niet heeft plaatsgevonden), moeten deze certificaten onmiddellijk worden verlengd via de oude CA om de looptijd te verlengen. De migratie van de automatisering hiervan is een prioriteit vanaf dag één zodra PKIaaS operationeel is.

Cohort B: Automatisch verlengbaar (migratie via herconfiguratie van automatisering). Alle certificaten die al worden beheerd door automatiseringsclients en die opnieuw kunnen worden geconfigureerd zonder de applicatie die ze gebruikt aan te raken: certificaatbronnen van cert-manager in Kubernetes, ACME-clients op Linux-servers, MDM SCEP-inschrijvingsprofielen (Intune, Jamf, Workspace ONE) en AD-automatische inschrijving via WSTEP. Deze cohort migreert wanneer de automatiseringsclient is gekoppeld aan het PKIaaS-inschrijvingseindpunt; de volgende verlengingscyclus voltooit de migratie. Voor grote ondernemingen omvat deze cohort doorgaans 50 tot 70% van het totale aantal certificaten.

Cohort C: Internetgerichte TLS (proactief migreren, grote impact op de bedrijfsvoering). Certificaten op internetgerichte webservers, API's en loadbalancers. Storingen in deze certificaten hebben grote gevolgen als ze verlopen of niet goed functioneren. Migreer proactief vóór de verlengingsperiode om de PKIaaS-profielconfiguratie onder gecontroleerde omstandigheden te valideren.

Cohort D: Interne applicatie- en servicecertificaten (migratie in fases). Interne TLS-certificaten, service-to-service-authenticatiecertificaten, applicatieservercertificaten. Migratie in fases nadat cohort B en C zijn gevalideerd. Deze certificaten hebben doorgaans standaard vernieuwingscycli en kunnen via geautomatiseerde herconfiguratie worden gemigreerd zodra de profielen zijn gevalideerd.

Cohort E: Langdurig geldige certificaten die zelden worden verlengd (passief migratievenster). Certificaten met een geldigheidsduur van 3 tot 5 jaar die betrouwbaar automatisch worden verlengd en waarvan de verlengingsdatum meer dan 12 maanden in de toekomst ligt. Laat deze certificaten over aan het passieve migratievenster; de automatisering zal ze vanuit PKIaaS verlengen wanneer het verlengingsvenster aanbreekt. Monitor via CLM om te bevestigen dat de verlenging correct verloopt.

Cohort F: Handmatig beheerd en niet-handmatig beheerd (afzonderlijk afhandelen). Certificaten die handmatig worden beheerd, niet zijn gekoppeld aan een bestaand systeem in de CMDB, of zwakke sleutelparameters hebben (RSA-1024, SHA-1 handtekeningen). Deze vereisen individueel onderzoek. Sommige worden handmatig gemigreerd; sommige mogen verlopen; sommige onthullen een verborgen PKI die moet worden uitgefaseerd.

Fase 3: Certificaatprofiel en beleidsafstemming (week 3 tot en met 6)

Maak voor elke actieve legacy CA-sjabloon of certificaatprofiel in de ontdekkingsinventaris een overeenkomend PKIaaS-certificaatprofiel aan dat de certificaatinhoud van de sjabloon reproduceert. Dit is de technisch meest risicovolle voorbereidingsstap. Een fout in de profieltoewijzing leidt tot certificaten die weliswaar succesvol worden geregistreerd, maar die door applicaties worden afgewezen, meestal op het moment van implementatie of bij de volgende TLS-handshake.

De profieltoewijzing moet worden gecontroleerd door iemand met praktische kennis van hoe elk certificaattype wordt gebruikt. De belangrijkste velden die correct moeten worden toegewezen zijn:

• OID's voor sleutelgebruik en uitgebreid sleutelgebruik: Controleer de exacte OID's aan de hand van de toepassingen die ze controleren. Clientauthenticatie, serverauthenticatie, codeondertekening, S/MIME en Kerberos PKINIT hebben allemaal specifieke OID's. Als er één ontbreekt, zal de toepassing die ernaar zoekt het certificaat afwijzen, zelfs als alle andere velden correct zijn.
• Onderwerp DN-bron: Waar komt de Subject CN vandaan? Voor machinecertificaten is dit doorgaans de hostnaam uit Active Directory. Voor gebruikerscertificaten is dit de weergavenaam uit Active Directory. Voor servicecertificaten is dit een vaste tekenreeks of een veld uit het inschrijvingsverzoek. Documenteer de bron voor elk veld en controleer of de regels voor het vullen van subjecten in het PKIaaS-profiel dezelfde uitvoer genereren.
• Soorten en bronnen van alternatieve onderwerpnamen: Voor webservercertificaten worden de SAN's doorgaans door de aanvrager verstrekt. Voor machinecertificaten is de DNS SAN afkomstig uit Active Directory. Voor gebruikerscertificaten is de UPN SAN afkomstig uit Active Directory. Controleer of de SAN-regels van het PKIaaS-profiel dezelfde SAN-waarden genereren als de oude sjabloon.
• Geldigheidsduur: Houd de geldigheidsperiode van de oude sjabloon aan, tenzij er een specifieke reden is om deze te wijzigen (de 47-dagenperiode van het CA/B Forum voor openbare TLS-certificaten, of een wijziging in het organisatiebeleid die ingaat met de migratie).
• CA/B Forum-naleving: Als gemigreerde certificaten worden gebruikt voor openbare TLS (en niet alleen voor intern vertrouwde certificaten), moeten ze voldoen aan de CA/B Forum Baseline Requirements. Als de oude CA certificaten heeft uitgegeven met niet-conforme profielen (bijvoorbeeld door interne domeinnamen in SAN's te gebruiken), kunnen die profielen niet worden overgenomen in PKIaaS-uitgifte en moeten de certificaatgebruikers worden bijgewerkt om conforme subject- en SAN-waarden te gebruiken vóór de migratie.

Stel een schriftelijk profielmappingdocument op waarin elk legacy-sjabloon wordt gekoppeld aan het overeenkomstige PKIaaS-profiel, met een veld-voor-veldvergelijking van de bovengenoemde velden. Dit document wordt door het migratieteam van de pilotgroep beoordeeld voordat de pilot van start gaat en dient als referentie voor de validatie van certificaten die tijdens de pilotfase worden uitgegeven.

Fase 4: PKIaaS-infrastructuur opzetten (week 4 tot en met 8)

Stel de PKIaaS CA-hiërarchie in, voer de ceremonie voor de root CA-sleutel uit en configureer de inschrijvings-eindpunten voordat de migratie begint. Concreet:

Ceremonie voor de root-CA-sleutel: Voer voor door de klant gehoste of hybride implementaties de ceremonie voor de root-CA-sleutel uit volgens de procedure in uw CP/CPS. Plan voor door de leverancier gehoste implementaties de ceremonie in met de PKIaaS-provider. Ga niet verder met de migratie voordat de ceremonie is voltooid en het bewijsmateriaal is ontvangen.

Configuratie van het inschrijvingseindpunt: Configureer het ACME-eindpunt (voor Linux en Kubernetes), het EST-eindpunt (voor netwerkapparaten en eindpunten met beperkte toegang), het SCEP-eindpunt (voor MDM en legacy OT) en de WSTEP-proxy (voor automatische inschrijving in Windows AD). Implementeer de WSTEP-proxy voordat u groepsbeleidsobjecten (GPO's) bijwerkt. Valideer elk eindpunt met een testinschrijving vóór de pilotfase.

Verdeling van het vertrouwen in de root-CA: Distribueer het nieuwe PKIaaS-root-CA-certificaat naar alle domeinmachines via het GPO-beleid 'Vertrouwde basiscertificeringsinstanties'. Sta ten minste één volledige vernieuwingscyclus van het groepsbeleid toe (standaard 90 minuten, of handmatig geactiveerd met gpupdate /force) voordat de PKIaaS CA een certificaat uitgeeft aan een machine in het domein. Een machine die een PKIaaS-certificaat ontvangt voordat de PKIaaS-root in de vertrouwensopslag is opgenomen, zal zijn eigen certificaat niet vertrouwen, wat precies de fout veroorzaakt die de migratie probeert te voorkomen.

CLM-connectiviteit: Verbind het CLM-platform met zowel de legacy CA als de PKIaaS CA. De CLM biedt een uniforme certificaatinventaris die de voortgang van de migratie bijhoudt, certificaten identificeert die niet volgens schema zijn gemigreerd en vervalrisico's detecteert tijdens de migratieperiode waarin beide CA's actief zijn. CertSecure Manager van Encryption Consulting ondersteunt connectors voor zowel legacy CA-systemen als PKIaaS-providers, waardoor deze dual-CA-inventaris vanaf het begin van het migratieprogramma beschikbaar is.

Fase 5: Migratie van de pilotgroep (week 7 tot en met 10)

De pilot migreert een gecontroleerde subset van de certificaten, doorgaans 500 tot 2,000 certificaten van elk relevant certificaattype, voordat de productie-uitrol begint. De pilot is geen test van het concept, maar een test van de specifieke profielen, automatiseringsconfiguraties en monitoring die in de productieomgeving zullen worden gebruikt. De certificaten voor de pilot moeten afkomstig zijn van daadwerkelijke gebruikers in de productieomgeving, niet van testomgevingen met afwijkende configuraties.

De checklist voor pilotvalidatie voor elk certificaattype:

• Het uitgegeven certificaat heeft de juiste uitgever (PKIaaS CA, niet de oude CA).
• Het subject-DN komt overeen met de verwachte waarde uit het profieltoewijzingsdocument.
• SAN's zijn aanwezig en komen overeen met de verwachte waarden.
• De sleutelgebruiks- en EKU-OID's komen overeen met het profieltoewijzingsdocument.
• De certificaatketens verwijzen correct naar de PKIaaS-root-CA die zich nu in de vertrouwensopslag van het consumerende systeem bevindt.
• De applicatie of het protocol dat het certificaat gebruikt, wordt succesvol gevalideerd (TLS-handshake voltooid, 802.1X-authenticatie geslaagd, aanmelding met smartcard geslaagd, enz.).
• Het OCSP-antwoord voor het nieuwe certificaat is "goed" en wordt verzonden door de PKIaaS OCSP-responder.
• Het certificaat verschijnt in de CLM-inventaris onder de naam PKIaaS CA, niet onder de naam legacy CA.

Elke mislukking van de pilot vormt een belemmering voor de uitrol naar de productieomgeving. Ga niet verder naar fase 6 totdat alle pilotfouten zijn vastgesteld, de hoofdoorzaak is geïdentificeerd in de profieltoewijzing of inschrijvingsconfiguratie, de configuratie is gecorrigeerd en de gecorrigeerde pilotcertificaten alle validatiecontroles hebben doorstaan. De pilot is de belangrijkste investering in het voorkomen van storingen binnen het gehele migratieprogramma.

Fase 6: Implementatie van automatiseringstools (week 8 tot en met 14)

Voordat de gefaseerde uitrol begint, moet de automatiseringssoftware voor elke cohort worden geïmplementeerd en geconfigureerd. Dankzij de automatisering is het mogelijk om 600,000 certificaten te migreren zonder dat het migratieteam evenredig hoeft te groeien.

Kubernetes en cloud-native (Cohort B): Werk de ClusterIssuer-resources van cert-manager bij zodat ze verwijzen naar het PKIaaS ACME-eindpunt met EAB-referenties. Controleer voor elke Certificate-resource of de issuerRef naar de PKIaaS ClusterIssuer verwijst. Bij de volgende verlengingstrigger (wanneer de resterende geldigheidsduur van het certificaat onder de renewBefore-drempel komt) vraagt ​​cert-manager automatisch de verlenging aan bij PKIaaS. Er is geen handmatige actie per certificaat vereist.

Automatische inschrijving voor Windows AD (Cohort B): Werk het certificaatinschrijvingsbeleid in het domein-GPO bij zodat het PKIaaS WSTEP-proxy-eindpunt als primaire CEP-server wordt aangewezen, met de oude CA CEP als secundaire terugvalserver. Pas het GPO eerst toe op de pilot-OU (geverifieerd in Fase 5) en rol het vervolgens uit naar de productie-OU's volgens de uitrolvolgorde in Fase 7. Domeinmachines worden automatisch ingeschreven via PKIaaS bij de volgende vernieuwing van het groepsbeleid of bij de trigger voor automatische inschrijving.

MDM-geregistreerde apparaten (Cohort B): Werk het SCEP- of PKCS-certificaatprofiel in Intune, Jamf of Workspace ONE bij zodat het verwijst naar het PKIaaS SCEP-eindpunt. Bij de volgende MDM-check-in of geforceerde synchronisatie van het apparaat levert het MDM-platform het bijgewerkte profiel en vernieuwt het apparaat zijn certificaat via PKIaaS. Voor Intune met native PKIaaS-integratie is de NDES-server niet langer nodig.

Linux-servers en DevOps (Cohort B en C): Werk de ACME-clientconfiguraties (certbot, acme.sh of HashiCorp Vault ACME) bij om de PKIaaS ACME-eindpunt-URL te gebruiken. Infrastructure-as-code-tools (Terraform, Ansible, Puppet) die certificaten leveren, moeten worden bijgewerkt om de PKIaaS REST API of het ACME-eindpunt te gebruiken. Voor CI/CD-pipelines moet de OIDC-uitwisselingsconfiguratie worden bijgewerkt om certificaten van PKIaaS te verkrijgen.

Netwerkapparaten (Cohort D): Werk de SCEP-profielconfiguraties op netwerkapparaten bij zodat ze verwijzen naar het PKIaaS SCEP-eindpunt. Voor apparaten die worden beheerd via een netwerkbeheersysteem, moet de sjabloonconfiguratie centraal worden bijgewerkt. Voor individueel geconfigureerde apparaten moet de update tijdens het volgende onderhoudsvenster plaatsvinden.

Fase 7: Gefaseerde uitrol per cohort (maanden 3 tot en met 7)

De gefaseerde uitrol voert cohortmigraties uit in prioriteitsvolgorde, met gedefinieerde succescriteria en terugdraaitriggers voor elk cohort voordat naar het volgende wordt overgegaan. De volgorde is Cohort A (direct risico op verlopen licentie), vervolgens B (geautomatiseerd, breedste reikwijdte), vervolgens C (TLS voor internettoepassingen), vervolgens D (interne applicaties), waarbij E passief op de achtergrond wordt uitgevoerd.

Definieer voor elk cohort het volgende:

Go-criteria: Wat moet er waar zijn voordat de uitrol van deze cohort begint? Doorgaans: de pilot voor dit certificaattype heeft alle validatiecontroles doorstaan, de automatiseringstools voor deze cohort zijn geïmplementeerd en getest, CLM toont de legacy CA-certificaten van de cohort in de inventaris, en de PKIaaS OCSP- en ACME-eindpunten zijn door monitoring als gezond bevestigd.

Succescriteria: Wat houdt een succesvolle cohortmigratie in? Doorgaans: X% van de cohortcertificaten is nu toegewezen aan de PKIaaS CA in de CLM-inventaris; geen mislukte inschrijvingen in de automatiseringslogboeken; monitoring op applicatieniveau toont geen authenticatiefouten die toe te schrijven zijn aan certificaatproblemen; OCSP-antwoord voor alle nieuwe certificaten is "goed".

Terugdraaitrigger: De specifieke voorwaarde die een onmiddellijke terugdraaiing voor deze cohort activeert, zonder te wachten op verdere escalatie. Typisch: meer dan 1% van de certificaten in de cohort vertoont validatiefouten op applicatieniveau; OCSP-respons mislukt voor meer dan een bepaalde drempelwaarde van de nieuwe certificaten; elk certificaat met een profielafwijking die een storing in een downstream-applicatie kan veroorzaken.

Cohort B (geautomatiseerde certificaten) is het cohort met de grootste impact. Door de profielen voor cert-manager, AD-auto-enrollment en MDM-enrollment opnieuw te configureren zodat ze naar PKIaaS verwijzen, wordt het grootste volume certificaten met de minste inspanning per certificaat verplaatst. In een omgeving met 1 miljoen certificaten, waarvan 60% geautomatiseerd is, verplaatst de migratie van Cohort B 600,000 certificaten in 4 tot 8 weken herconfiguratie van de automatisering door een PKI-team van 3 tot 5 personen.

Fase 8: Beheer van de co-existentie van legacy CA-systemen (doorlopend tijdens de uitrol)

Tijdens de migratieperiode zijn twee CA-hiërarchieën tegelijkertijd actief. Door de co-existentieperiode correct te beheren, wordt de meest voorkomende migratiestoring voorkomen: een verouderd CA-certificaat dat tijdens de migratie verloopt zonder te worden vernieuwd door PKIaaS, omdat de automatisering van het systeem niet tijdig opnieuw is geconfigureerd.

De CLM-laag is de operationele tool voor co-existentiebeheer. Deze moet zo geconfigureerd worden dat de migratiestatus van elk certificaat in de omgeving wordt weergegeven: welke CA het certificaat heeft uitgegeven, of de automatisering voor dit certificaat opnieuw is geconfigureerd om PKIaaS te gebruiken, en hoeveel tijd er nog resteert voordat het verloopt. Configureer CLM-waarschuwingen voor legacy CA-certificaten die binnen 60 dagen verlopen en nog niet zijn gemigreerd. Dit zijn de certificaten die het risico lopen te verlopen als er geen PKIaaS-vervanging komt en het migratieschema vertraging oploopt.

De oude CA moet tijdens de co-existentieperiode volledig operationeel blijven. Het publicatieschema voor de CRL's moet worden gehandhaafd, zodat door de oude CA uitgegeven certificaten nog steeds kunnen worden gevalideerd door systemen die de intrekking controleren. Wijzig de CRL-distributiepunten, de OCSP-configuratie of de vertrouwensketen van de CA-certificaten van de oude CA niet tijdens de migratie. Elke verstoring van de intrekkingsinfrastructuur van de oude CA tijdens de migratieperiode zal leiden tot problemen met de certificaten die nog niet zijn gemigreerd.

Volg wekelijks de migratiesnelheid: welk percentage van het totale aantal certificaten is nu toegewezen aan de PKIaaS CA in CLM, welk percentage bevindt zich nog op de oude CA en of de migratie in het vereiste tempo verloopt om te worden voltooid vóór de beoogde datum voor de uitfasering van de oude CA. Als de snelheid lager is dan gepland, moet worden vastgesteld of het probleem zich bevindt in de geautomatiseerde cohorten (configuratie nog niet geïmplementeerd), de handmatige cohorten (onvoldoende teamcapaciteit voor handmatige migratie) of de passieve cohort (certificaten met een lange geldigheidsduur die hun verlengingsperiode nog niet hebben bereikt).

Fase 9: Ontmanteling van de oude CA-installaties (maanden 12 tot en met 24)

Het buitenbedrijf stellen van de oude CA is de laatste stap en mag niet overhaast worden uitgevoerd. Het buitenbedrijf stellen van de oude CA voordat alle certificaten zijn vervangen of verlopen, leidt tot een onmiddellijke onderbreking van alle certificaten die nog in gebruik zijn onder die CA. De CLM-inventaris is de controlemaatregel: ga niet verder met het buitenbedrijf stellen totdat de inventaris bevestigt dat er geen actieve certificaten meer zijn toegewezen aan de oude CA.

De ontmantelingsprocedure:

• Bevestig via CLM dat er geen actieve certificaten meer zijn toegewezen aan de oude uitgevende CA.
• Trek het oude CA-certificaat in bij de oude root-CA.
• Publiceer een definitieve CRL van de oude certificeringsinstantie die de intrekking van alle ooit door die instantie uitgegeven certificaten weerspiegelt. Deze definitieve CRL moet een geldigheidsperiode hebben die langer is dan de langste geldigheidsperiode van enig certificaat dat de certificeringsinstantie ooit heeft uitgegeven, zodat intrekkingsverzoeken voor oude certificaten nog steeds kunnen worden beantwoord met behulp van de in de cache opgeslagen CRL.
• Zorg ervoor dat de oude CRL-distributiepunten gedurende de volledige geldigheidsperiode van de CRL toegankelijk blijven.
• Verwijder het oude root-CA-certificaat uit de lijst met vertrouwde rootcertificeringsinstanties van het domein via een groepsbeleidsobject (GPO). Test dit eerst op een niet-kritieke organisatie-eenheid (OU) voordat u de wijziging domeinbreed toepast.
• Archiveer de oude CA-database, HSM (of CA-softwarestatus) en bewijsstukken van ceremonies gedurende de bewaartermijn die vereist is door uw compliance-raamwerk.

Fase 10: Bestuur na de migratie

Goed beheer na de migratie is wat een permanente verbetering onderscheidt van een tijdelijke verbetering die binnen twee jaar weer teniet wordt gedaan. Organisaties die een PKI-migratie voltooien maar geen doorlopende controles instellen voor de omgeving na de migratie, zien hun certificatenportfolio terugvallen in handmatige uitgifte, schaduw-PKI en dezelfde operationele problemen waar ze juist van af wilden.

Automatiseringsdekkingsindicator: Definieer en volg het percentage certificaten in de omgeving dat door automatisering wordt beheerd (cert-manager, MDM-inschrijving, ACME-clients, automatische inschrijving). Streef naar 90% of hoger voor nieuwe certificaten nadat de migratie is voltooid. Elk nieuw certificaat dat in de omgeving terechtkomt zonder automatiseringsdekking, moet worden behandeld als een procesuitzondering die herstel vereist.

Poort voor certificaatuitgifte: Werk het certificaataanvraagproces van de organisatie bij zodat alle nieuwe interne certificaten via de PKIaaS-inschrijvingsautomatisering (ACME, EST, SCEP, WSTEP) moeten worden aangevraagd in plaats van via handmatige CSR-indiening. Handmatige CSR-indiening wordt nog steeds ondersteund voor speciale gevallen, maar vereist een goedkeuringsworkflow en een CLM-item dat het handmatige certificaat bijhoudt voor verlenging. Dit voorkomt de opeenhoping van handmatig beheerde certificaten, wat de oorspronkelijke noodzaak voor de migratie veroorzaakte.

Handhaving van het beleid in CLM: Configureer CLM om continu beleidsschendingen te signaleren: certificaten met sleutelgroottes onder het huidige minimum, handtekeningalgoritmen die niet aan de huidige standaard voldoen, geldigheidsperioden die het huidige beleid overschrijden of certificaten die zijn uitgegeven buiten de goedgekeurde PKIaaS CA. Beleidsschendingen moeten worden doorgestuurd naar het verantwoordelijke team voor herstel binnen een vastgestelde termijn, en niet naar een spreadsheet die elk kwartaal wordt gecontroleerd.

Beheer van de groei van het certificaatportfolio: Het certificaatportfolio van een onderneming groeit jaarlijks met 8 tot 12% door de toevoeging van nieuwe services, apparaten en workloads. Na de migratie moet het beheer regelmatig de dekking controleren: vragen nieuwe applicatie-implementaties certificaten aan via de PKIaaS-automatisering, of gebruiken ontwikkelaars zelfondertekende certificaten en omzeilen ze het PKI-programma? CLM-detectie moet continu plaatsvinden, niet alleen tijdens de migratie, om nieuwe, niet-beheerde certificaten te detecteren voordat ze een risico vormen voor storingen.

Voorbereiding op het 47-dagen schema van het CA/B Forum: CA/B Forum-stemming SC-081v3 (goedgekeurd in april 2025) verkort de maximale geldigheidsduur van openbare TLS-certificaten tot 47 dagen met ingang van 15 maart 2029. Voor organisaties die vóór die datum migreren naar PKIaaS, biedt de migratie de mogelijkheid om vanaf het begin cert-manager- of ACME-automatisering met de kortere geldigheidsperiode in te stellen, in plaats van achteraf automatisering te moeten implementeren voor een certificaatportfolio dat handmatig werd beheerd met een geldigheidsduur van 1 jaar of 90 dagen. Controleer na de migratie of alle openbare TLS-certificaten automatisch worden verlengd met de juiste verlengingstermijnen (14 tot 21 dagen vóór de vervaldatum voor certificaten met een geldigheidsduur van 47 dagen).

Samenvatting van het migratietijdspad

Fase	Timeline	Belangrijkste uitvoer	Poortvoorwaarde voor de volgende fase
1. Ontdekking en inventarisatie	Weken 1 tot 3	Volledig certificatenoverzicht met vervaldatumprofiel	Voorraadgegevens zijn in CLM geladen, inclusief toewijzings- en vervaldatumgegevens.
2. Segmentatie en prioritering	Weken 2 tot 4	Cohortdefinities en migratievolgorde	Cohort A is geïdentificeerd en noodverlengingen zijn voltooid.
3. Profiel- en beleidsmapping	Weken 3 tot 6	Profielmappingdocument, veld-voor-veld vergelijking	Alle actieve sjablonen zijn gekoppeld; het document is beoordeeld en goedgekeurd.
4. Infrastructuur voor PKIaaS	Weken 4 tot 8	Operationele PKIaaS CA; root in vertrouwensarchieven; eindpunten gevalideerd	Root gedistribueerd; alle inschrijvingspunten reageren op testinschrijvingen.
5. Migratie van de pilotgroep	Weken 7 tot 10	Gevalideerde pilotenbrevetten per brevettype	Alle pilotvalidatiecontroles zijn geslaagd; geen profiel- of ketenfouten.
6. Implementatie van automatiseringstools	Weken 8 tot 14	Automatisering geconfigureerd voor cohorten A, B, C, D.	Automatisering getest in een pilotproject; gevalideerde vernieuwing voor elke cohort.
7. Gefaseerde uitrol per cohort	Maanden 3 tot en met 7	60% tot 80% van het vastgoed op PKIaaS	Succescriteria per cohort zijn behaald voordat het volgende cohort begint.
8. Co-existentiebeheer	Maanden 3 tot en met 18	CLM dual-CA-voorraad; geen vervaldatumhiaten.	Lopend; wordt opgelost zodra de passieve cohort de verlengingsfase doorloopt.
9. Ontmanteling van Legacy CA	Maanden 12 tot en met 24	Legacy CA's zijn buiten gebruik gesteld; trustkantoren zijn opgeruimd.	CLM bevestigt dat er geen actieve legacy CA-certificaten meer zijn.
10. Bestuur na migratie	Lopend	Automatiseringsdekkingsstatistieken; beleidshandhaving; CLM-ontdekking	Permanente operationele staat

Hoe encryptieconsultancy kan helpen

• PKI-beoordelingsservice: Encryptie Consulting's PKI-beoordelingsservice Dit document levert de basisgegevens voor de ontdekking, cohortsegmentatie en profielmapping op, zoals vereist in fase 1 tot en met 3 van dit draaiboek. Voor organisaties die een onafhankelijke beoordeling nodig hebben voordat ze zich vastleggen op een migratieaanpak, biedt de beoordeling een onderbouwd migratieplan met inspanningsschattingen en risicoanalyse.
• PKI als een service: Encryptie Consulting's PKIaaS-aanbod De CA-infrastructuur voor de migratie omvat ACME+EAB voor certificaatbeheer en Linux-automatisering, native Intune- en Jamf MDM-integratie waardoor NDES uit de architectuur wordt verwijderd, WSTEP-proxy voor AD-auto-inschrijving, SCEP voor netwerkapparaten en legacy OT, en een REST API voor tools voor infrastructuurautomatisering. Neem contact met ons op via Encryptie Consulting om de omvang en het tijdschema van uw migratie te bespreken.
• CertSecure Manager: Encryptie Consulting's CertSecure Manager Het biedt de CLM-laag die de migratie beheersbaar maakt: een uniforme inventaris van zowel de oude CA als de PKIaaS CA vanaf de eerste dag van de migratie; cohorttracking en statistieken over de migratiesnelheid; waarschuwingen voor verlopen certificaten van oude CA's die nog niet zijn gemigreerd; en de continue detectie die nodig is voor het beheer na de migratie om nieuwe, niet-beheerde certificaten op te sporen voordat ze een risico vormen voor uitval.
• PKI-diensten: Voor organisaties die behoefte hebben aan praktische, deskundige ondersteuning tijdens de fasen van profielmapping, pilotvalidatie of de implementatie van automatiseringstools, biedt Encryption Consulting de juiste oplossing. PKI-diensten Wij bieden advies en implementatieondersteuning gedurende elke fase van het migratieplan, met name op het gebied van AD CS-sjabloonmigratie, ClusterIssuer-configuratie in cert-manager en automatisering van MDM-inschrijvingen.
• CBOM Secure: Voor organisaties waarbij de migratie ook het rationaliseren van het gebruik van verouderde cryptografische algoritmen omvat (RSA-1024, SHA-1 of 3DES-certificaten die tijdens de ontdekking worden aangetroffen), biedt Encryption Consulting de volgende oplossingen. CBOM Secure Het bedrijf levert de cryptografische inventaris en de beoordeling van de algoritmestatus, die samen met het certificaatmigratieprogramma de prioriteiten voor herstelmaatregelen bepalen.

Conclusie

Het migreren van een miljoen certificaten naar PKIaaS is een programma, geen project. De actieve migratiefasen duren 4 tot 9 maanden. De periode voor passieve verlenging van de resterende certificaten komt daar nog eens 12 tot 18 maanden bij. Het beheer na de migratie is permanent. Organisaties die de volledige tijdlijn van het programma plannen en investeren in de benodigde infrastructuur voor detectie, profielmapping, automatisering en CLM, voltooien de migratie zonder onderbrekingen en beschikken over een certificaatprogramma dat aanzienlijk beter beheerd wordt dan waarmee ze begonnen.

De organisaties die problemen ondervinden met PKI-migraties zijn doorgaans niet degenen die technische problemen hebben ondervonden. Het zijn eerder de organisaties die de omvang van de ontdekking hebben onderschat, de pilotvalidatiefase onder tijdsdruk hebben overgeslagen of hebben geprobeerd de oude CA buiten gebruik te stellen voordat de CLM de volledigheid van de migratie had bevestigd. Het bovenstaande draaiboek is ontworpen om elk van deze faalscenario's te voorkomen met specifieke voorwaarden waaraan niet kan worden voldaan zonder expliciete risicoacceptatie.

Het CA/B Forum-schema voor de geldigheidsduur van 47 dagen, dat ingaat op 15 maart 2029, maakt de migratie urgent. Organisaties die op die datum nog steeds een groot aantal TLS-certificaten handmatig beheren en certificaten met een geldigheidsduur van 90 dagen of 1 jaar handmatig verlengen, zullen direct te maken krijgen met een operationele crisis, aangezien de verlengingsfrequentie verdrievoudigt. Migreren naar PKIaaS-automatisering vóór die datum is een risicobeperking voor een bekende, gedateerde regelgevingsmaatregel.

Als uw organisatie een PKIaaS-migratie plant en de aanpak wilt valideren voordat u zich aan een programma verbindt, neem dan contact op met Encryption Consulting . Wij hebben PKI-migraties voor grote bedrijven uitgevoerd en geadviseerd in de financiële sector, de gezondheidszorg, de defensie en kritieke infrastructuur.

Dit bericht wordt elke zes maanden herzien, en ook wanneer het CA/B Forum updates publiceert over het schema voor de vermindering van de geldigheidsduur van SC-081v3-certificaten, of wanneer cert-manager, Intune of Jamf belangrijke wijzigingen in hun PKI-integratiemodellen publiceren.

Veelgestelde Vragen / FAQ

Hoe lang duurt het om een ​​miljoen certificaten naar PKIaaS te migreren?

Het actieve migratieprogramma (van ontdekking tot gefaseerde uitrol) duurt 4 tot 9 maanden. De periode voor passieve verlenging van langlopende certificaten voegt daar nog 12 tot 18 maanden aan toe. De volledige uitfasering van de oude CA's vindt doorgaans 12 tot 24 maanden na de start van het programma plaats. Het grootste deel van de certificeringsinstanties wordt gemigreerd via geautomatiseerde herconfiguratie van de verlenging in plaats van vervanging van individuele certificaten, waardoor het programma schaalbaar is zonder dat een evenredige uitbreiding van het team nodig is.

Moeten alle miljoen certificaten in één keer vervangen worden?

Nee. De meeste certificaten worden automatisch vervangen tijdens hun natuurlijke vernieuwingscyclus. Wanneer de automatisering opnieuw wordt geconfigureerd om naar PKIaaS te verwijzen, wordt het certificaat tijdens de volgende vernieuwingscyclus vervangen zonder dat de applicatie die het certificaat gebruikt, wordt aangepast. Proactieve vervanging is alleen nodig voor certificaten die verlopen voordat de automatisering de vernieuwing kan afhandelen, of wanneer de oude CA moet worden uitgefaseerd voordat alle certificaten op natuurlijke wijze verlopen.

Hoe moeten certificaten prioriteit krijgen bij de migratie?

Hoogste prioriteit: certificaten die binnen 90 dagen verlopen. Tweede prioriteit: automatisch verlengbare certificaten (cert-manager, MDM-ingeschreven, ACME-geautomatiseerd, AD-auto-inschrijving) omdat deze via een configuratiewijziging worden gemigreerd en niet via individuele certificaten. Derde prioriteit: TLS voor internettoepassingen (grote impact op de bedrijfsvoering indien onjuist). Vierde prioriteit: interne applicaties en services. Passieve verlenging zorgt voor betrouwbare automatisering van langlopende certificaten. Handmatige en achtergebleven certificaten vereisen individueel onderzoek en herstel.

Wat is het risico op storingen tijdens een PKIaaS-migratie?

De belangrijkste risico's op uitval zijn: de PKIaaS-root-CA bevindt zich niet in de vertrouwensarchieven voordat de eerste certificaten worden uitgegeven; fouten in de profieltoewijzing die leiden tot certificaten die door applicaties worden afgewezen; mislukte inschrijvingen waardoor systemen zonder certificaat achterblijven; en intrekking van de legacy-CA voordat al haar certificaten zijn gemigreerd. Elk van deze risico's wordt aangepakt door specifieke voorwaarden in het draaiboek: distributie van de root-CA vóór de uitgifte van certificaten, validatie in een pilotfase vóór de uitrol naar productie, CLM-monitoring op mislukte inschrijvingen en CLM-bevestiging dat er geen actieve legacy-CA-certificaten meer zijn vóór de buitenbedrijfstelling.

Wanneer kan de oude CA buiten gebruik worden gesteld na de migratie naar PKIaaS?

De oude CA mag pas buiten gebruik worden gesteld nadat CLM heeft bevestigd dat er geen actieve certificaten meer aan die CA zijn toe te schrijven in de omgeving. De procedure voor het buiten gebruik stellen is als volgt: bevestig dat er geen actieve certificaten meer zijn in CLM, trek de oude uitgevende CA in van de oude root, publiceer een definitieve CRL met een geldigheidsduur die langer is dan de langst geldige certificaten die de CA ooit heeft uitgegeven, behoud de CRL-distributiepunten gedurende de volledige geldigheidsperiode van de CRL en verwijder vervolgens de oude root uit de vertrouwensarchief via GPO (eerst testen op een niet-kritieke OU).