Hur man migrerar från en gammal CA till en ny utfärdande CA

Utfärdande CA behöver ofta avvecklas av olika skäl, till exempel

• Operativsystemet närmar sig slutet av sin livslängd
• CA kan vara komprometterad
• CA har operativa problem och är för komplicerat att städa upp.

Oavsett anledning kan det verka enkelt att migrera till en ny utfärdande CA. Ändå kan det medföra nya utmaningar, såsom att minska risker, minimera driftspåverkan etc.

Vid migrering av utfärdande CA:er måste vi säkerställa,

1. De nuvarande certifikat som utfärdas förblir giltiga tills deras giltighetstid löper ut.
2. Den gamla utfärdande certifikatutfärdaren bör inte utfärda fler certifikat.
3. Vi kan flytta till andra CDP/AIA-punkter enligt de nödvändiga ändringarna, men den utfärdande CA:n skulle ha minimal drift och ingen inverkan på PKI-infrastruktur.

Snabbt svar: Hur man migrerar till en ny utfärdande CA

Att migrera till en ny utfärdande certifikatutfärdare innebär att upprätta en ersättande certifikatutfärdare, omdirigera CDP/AIA-distributionspunkter, inaktivera Delta CRL-publicering på den gamla certifikatutfärdaren, dokumentera och återaktivera certifikatmallar på den nya infrastrukturen och avveckla den gamla certifikatutfärdaren först efter att varje certifikat som den utfärdade har löpt ut eller utfärdats på nytt, utan några störningar i certifikatvalideringen.

Senast uppdaterad: augusti 2026 · Senast verifierad: augusti 2026 · Rekommenderad uppdateringskadens: verifiera giltighetsperiodsreferenserna för CA/Browser Forum varje kvartal och verifiera den fullständiga genomgången minst var sjätte månad eftersom detta är en ständigt återkommande procedurguide.

Sammanfattning: Viktiga slutsatser

• Håll certifikaten giltiga: Befintliga certifikat utfärdade av den gamla certifikatutfärdaren förblir giltiga tills de löper ut på naturlig väg; endast den gamla certifikatutfärdarens möjlighet att utfärda nya certifikat är avstängd.
• Omdirigera, ta inte bort: CDP- och AIA-distributionspunkter omdirigeras till den nya certifikatutfärdarens slutpunkter så att återkallningskontrollen aldrig avbryts mitt i migreringen.
• Inventera varje mall: Varje certifikatmall som används på den gamla certifikatutfärdaren dokumenteras och återaktiveras på den nya certifikatutfärdaren före övergången.
• Validera före avveckling: Den gamla certifikatutfärdaren tas inte längre ur bruk efter att CRL/AIA-kontroller mot den nya infrastrukturen lyckats och inga aktiva certifikat fortfarande är beroende av den.
• Återställning är inbyggd: Varje fas (Delta CRL, omdirigeringar, mallar) har en dokumenterad återställning så att ett misslyckat steg inte leder till ett avbrott.

Vem borde bry sig om den här migrationen

En utfärdande CA-migrering berör mer än PKI-teamet som kör kommandona. Här är vad varje roll bör äga.

PKI-administratörer

Ta ansvar för den tekniska övergången: kör CDP/AIA-granskningen, genomför certutil-stegen, dokumentera varje certifikatmall och håll tidslinjen för avveckling av den gamla certifikatutfärdaren.

Säkerhetsarkitekter

Designa CDP/AIA-layouten för den nya CA, godkänn certifikatmallarnas inventering och bekräfta att den nya CA stöder den kryptoflexibilitet som organisationen behöver för framtida algoritmändringar.

Plattformsteam

Uppdatera CI/CD-pipelines, automatiseringsskript, lastutjämnare och DNS/IIS-omdirigeringsregler som fortfarande refererar till den gamla certifikatutfärdarens slutpunkter innan den gamla certifikatutfärdaren stoppas.

Compliance-team

Bekräfta att ändringen uppfyller organisationens certifikatpolicy/certifieringspraxis (CP/CPS), för en revisionslogg för avvecklingsbeslutet och behåll certifikatinventeringen under den obligatoriska arkiveringsperioden.

CISO: er

Spåra avbrottsrisken över hela migreringsfönstret, godkänn den gamla certifikatutfärdarens avveckling och se till att ändringen loggas som en styrningshändelse snarare än en odokumenterad infrastrukturuppgift.

Varför detta är viktigt: Data och deadlines

Enligt DigiCerts Trust Pulse-undersökning (publicerad 2 juli 2025) upplevde nästan hälften av företagen ett certifikatrelaterat avbrott under det senaste året, och 37.5 % spårade specifikt avbrottet till ett utgånget certifikat; 18.5 % av de drabbade organisationerna rapporterade förluster på över 250 000 dollar. En förhastad eller odokumenterad migrering av utfärdande CA är precis den typ av förändring som producerar detta felläge.

CA/Browser Forums omröstning SC-081v3 (godkänd 11 april 2025) innebär en gradvis minskning av den maximala giltighetstiden för TLS-certifikat: 200 dagar från och med den 15 mars 2026, 100 dagar från och med den 15 mars 2027 och 47 dagar från och med den 15 mars 2029. Kortare certifikatlivslängder innebär att alla utfärdande CA, gamla som nya, utfärdar certifikat betydligt oftare, vilket ökar driftskostnaden för en manuell, odokumenterad CDP/AIA eller mallmigrering.

På kryptografisidan slutförde NIST sina tre första post-kvantumstandarder , FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA), den 13 augusti 2024. Alla nya utfärdande CA som etableras idag bör utvärderas för kryptoagilitet mot dessa algoritmer så att de inte behöver en andra migrering när PQC-klara certifikatprofiler blir obligatoriska.

Förutsättningar

Innan du börjar, kontrollera att följande är på plats:

• En ny server har etablerats, konfigurerats och installerats med den utfärdande CA-rollen.
• Administrativ åtkomst till både den gamla och den nya certifieringsutfärdarkonsolen och en upphöjd kommandotolk på var och en.
• En säkerhetskopia av den gamla CA:ns databas och register-CDP/AIA-värden som tas innan några ändringar påbörjas, så att migreringen kan återställas när som helst.
• Ändringskontroll och godkännande av driftstoppsfönster om miljön tillämpar styrning av certifikatpolicy.

Steg-för-steg-migreringsprocedur

Dessa steg kommer att hjälpa organisationer att migrera till en ny utfärdande CA.

Om CDP/AIA-poäng inte ändras är steg 2, 4 och 5 valfria och bör inte följas.

1. Logga in på den gamla utfärdande certifikatutfärdaren
2. Identifiera CDP/AIA-distributionspunkter (valfritt)
   1. Öppna kommandotolken
   2. Skriv kommandot

      certutil -getreg CA\CACertPublicationURLs

      

   3. Dokumentera HTTP AIA-punkterna. Ignorera LDAP och C:\%windir%

      Enligt skärmdumpen är AIA-punkten http://pki.encon.com/CertEnroll/%1_%3%4.crt

      %1 hänvisar till ServerDNSName

      %3 hänvisar till CaName

      %4 hänvisar till certifikatnamn

      Faktisk URL: http://pki.encon.com/CertEnroll/iCA2016.encon.com_iCA2016.crt

   4. Skriv kommandot

      certutil -getreg CA\CRLPublikationsURL:er

      

   5. Dokumentera HTTP CDP-punkterna. Ignorera LDAP och C:\%windir%

      Enligt skärmdumpen är CDP-punkten http://pki.encon.com/CertEnroll/%3%8%9.crl

      %3 hänvisar till CaName

      %8 hänvisar till CRLNameSuffix

      %9 hänvisar till DeltaCRL-tillåten

      Faktisk URL: http://pki.encon.com/CertEnroll/iCA2016.crl



3. Inaktivera Delta CRL och utfärda en ny lång Certifikatåterkallningslista (CRL)
   1. Öppna certifikatutfärdarkonsolen

      

   2. Högerklicka på Återkallade certifikat och klicka sedan på Egenskaper

      

   3. Avmarkera "Publicera Delta CRL"

      

   4. Redigera "CRL-publiceringsintervall" till 99 år

      

      klicka på OK

   5. Öppna kommandotolken som administratör
   6. Skriv följande kommando

      certutil -crl

      

4. Kopiera gamla CA:s certifikatfiler (crt) och CRL-filer (Certificate Revocation List) till nya CDP/AIA-punkter (valfritt)
   1. Navigera till %windir%\System32\CertSrv\CertEnroll
   2. Kopiera den gamla CA:ns crt- och CRL-filer till nya CDP/AIA-punkter

      

5. Omdirigera AIA- och CDP-punkter från den gamla CA:n till den nya platsen

   Detta kan göras med hjälp av en

   1. IIS-omdirigering, eller
   2. DNS CNAME

      omdirigerar AIA och CRL för den gamla certifieringsutfärdaren.

6. Dokumentera alla certifikatmallar och stoppa certifikatpublicering på den gamla utfärdande certifikatutfärdaren
   1. Öppna kommandoraden med förhöjda rättigheter
   2. Körning

      Certutil -katemplåtar > c:\katemplåtar.txt

      och dokumentera alla certifikatmallar som publicerats hos den gamla certifieringsutfärdaren

      

      Totalt finns certifikatmallar .

   3. Starta konsolen för certifieringsutfärdare
   4. Navigera till "Certifikatmallar"
   5. Markera alla mallar i den högra rutan, högerklicka och klicka sedan på "Ta bort"

      

      Den gamla certifieringsutfärdaren kan inte utfärda några certifikat och har alla sina AIA och CRL:er omdirigerade till en ny CRL-distributionspunkt. Nästa steg kommer att beskriva hur användare kan dokumentera certifikatmallarna som publicerats på den gamla utfärdande certifikatutfärdaren och hur de görs tillgängliga på den nya utfärdande certifikatutfärdaren.

7. Sortera certifikatutfärdarens databas, identifiera och dokumentera alla utfärdade certifikat baserat på certifikatmallar
   1. Öppna certifikatutfärdarkonsolen.
   2. Markera utfärdade certifikat.
   3. Flytta till höger och sortera efter "Certifikatmallar".

      

   4. Identifiera de certifikat som utfärdats av standardmallar för certifikat.
   5. Dokumentera certifikaten som utfärdats av anpassade certifikatmallar, dvs. alla andra mallar än standardcertifikatmallarna.



8. Dokumentcertifikat baserade på standardmallar för certifikat
   1. Öppna kommandotolken med förhöjda rättigheter
   2. Körning

      Certutil -view -restrict “Certifikatmall= Mall” -out “Serienummer,InteEfter,UtmärktNamn,VanligtNamn”> c:\Malltyp.txt

      Obs: Ersätt mallen med rätt mallnamn

      

   3. Granska utdata på TemplateType.txt och dokumentera alla certifikat som kräver omedelbar åtgärd (vilket kräver utfärdande från den nya CA-infrastrukturen om det behövs, till exempel webbservercertifikat)
   4. Rådgör med programadministratörer som använder certifikaten för att avgöra den bästa metoden för att ersätta certifikaten om det behövs.
9. Dokumentcertifikat baserade på anpassade certifikattyper
   1. Öppna konsolen för certifieringsutfärdare
   2. Högerklicka på Certifikatmallaroch klicka på Hantera

      

   3. Dubbelklicka på certifikatmallen och klicka på fliken "Tillägg".

   

   4. Klicka på "Information om certifikatmall"

   

   5. Kopiera objektidentifieringsnumret (OID) – numret kommer att se ut ungefär så här

      1.3.6.1.4.1.311.21.8.5363900.15781253.12798358.11444918.12080715.141.12736713.11129372

   6. Öppna kommandotolken med förhöjda rättigheter
   7. Körning

      Certutil -view -restrict “Certifikatmall = 1.3.6.1.4.1.311.21.8.5363900.15781253.12798358.11444918.12080715.141.12736713.11129372″ -out “Serienummer,InteEfter,UtmärktNamn,VanligtNamn”> c:\CustomMallType.txt

      Obs: Ersätt OID-numret med numret som identifierades i steg 5

      

   8. Undersök resultatet av c:\Anpassadmalltyp.txt och dokumentera alla certifikat som kräver omedelbara åtgärder (vilket kräver utfärdande från den nya CA-infrastrukturen om det behövs, till exempel anpassade SSL-certifikat).
   9. Rådgör med programadministratören som använder certifikaten för att avgöra den bästa metoden för att ersätta certifikaten om det behövs.
10. Aktivera certifikatmallar som behövs baserat på resultaten av steg 7 till 9 på den nya utfärdande certifikatutfärdaren.
    1. Logga in på ny utfärdande CA.
    2. Högerklicka på "Certifikatmallar", klicka på Nytt och klicka på "Certifikatmallar att utfärda".

       

    3. Välj alla certifikatmallar som behövs i fönstret ”Aktivera certifikatmallar” och klicka på > OK.

       

Valideringskontroller efter migrering

Kör dessa kontroller innan du anser migreringen vara klar:

• Hämta de nya CDP- och AIA-URL:erna direkt från en klient utanför CA:s eget nätverk (webbläsare eller curl -I) och bekräfta att båda returnerar giltiga, aktuella .crl- och .crt-filer.
• Körning certutil -verify mot ett certifikat som nyligen utfärdats av den nya CA:n och bekräfta att kedjebyggen och återkallningsstatusen åtgärdas utan varningar.
• Jämför den nya CA:ns lista över utfärdbara mallar med den dokumenterade utdata från certutil -catemplates från den gamla CA:n och bekräfta att ingenting saknas.
• Kontrollera CA-händelseloggen på båda CA:erna (Händelseloggen > Program- och tjänstloggar > Microsoft > Windows > CertificateServicesClient) för registrerings- eller återkallningsfel under migreringsfönstret.
• Bekräfta att den gamla certifikatutfärdarens CRL fortfarande är nåbar och inte har löpt ut tills det senaste certifikatet som den utfärdade löper ut, även efter att publiceringen har stoppats.

Vanliga fel och felkoder

• CRL_E_REVOCATION_OFFLINE (0x80092013): en klient kan inte nå den nya CDP:n; vanligtvis en brandväggsregel, DNS-post eller IIS-omdirigering som inte uppdaterades.
• "Nekad av policymodul" (0x80094800): Den begärda certifikatmallen har ännu inte aktiverats på den nya certifikatutfärdaren; kontrollera mallförteckningen från steg 7 igen.
• Åtkomst nekad (0x80070005): certutil Kommandon kördes utan en förhöjd kommandotolk eller så saknar kontot CA-administratörsrättigheter.
• "CertUtil: -crl-kommandot MISSLYCKADES: 0x8007052e": CA-tjänstkontot har inte behörighet att publicera CRL:n; verifiera tjänstkontot och fildelningsbehörigheterna.
• Inaktuell AIA-kedja i applikationer: ett program cachar fortfarande den gamla certifikatutfärdarens certifikatsökväg efter omdirigeringen; rensa programmets certifikatcache eller starta om den beroende tjänsten.

Återställningssteg

Om valideringen misslyckas någon gång, gå tillbaka innan du trycker på nästa steg:

1. Markera rutan "Publicera Delta CRL" igen och återställ det ursprungliga CRL-publiceringsintervallet om du inaktiverade det och den nya CA:n inte är klar.
2. Återställ den gamla CA:ns CDP/AIA-registervärden från din dokumenterade certutil -getreg utdata om en omdirigering bryter återkallningskontrollen.
3. Ta bort eller inaktivera IIS-omdirigeringsregeln eller DNS CNAME och peka klienter tillbaka till den gamla certifikatutfärdarens ursprungliga slutpunkter.
4. Återaktivera certifikatmallarna på den gamla certifikatutfärdaren om den måste fortsätta utfärda medan en saknad mall läggs till i den nya certifikatutfärdaren.
5. Återställ CA-databasen från ögonblicksbilden före migreringen endast som en sista utväg, eftersom detta också återställer eventuella certifikat som utfärdats efter ögonblicksbilden.

Migreringsreferenstabell

Använd den här tabellen som en snabb sammanfattning av varje migreringsfas.

Förutsättning	Kommando / Konfiguration	Valideringskontroll	Vanligt fel	rollback	Ägare
Ny CA-server etablerad med den utfärdande CA-rollen installerad	Installera och konfigurera certifikatutfärdarrollen på den nya servern	certutil -viewstore bekräftar den nya CA:ns certifikatkedja	0x80070005 (åtkomst nekad) om den inte körs med förhöjda begränsningar	Ta bort CA-rollen; ingen produktionstrafik är ännu beroende av den	PKI-administratör
Gamla CA:s CDP/AIA-poäng dokumenterade	certutil -getreg CA\CACertPublicationURLs / CRLPublicationURLs	HTTP-slutpunkter matchar och returnerar giltiga .crt/.crl-filer	0x80092013 CRL_E_REVOCATION_OFFLINE om den inte kan nås	Återställ ursprungliga registervärden från dokumenterad utdata	PKI-administratör
Delta CRL inaktiverad och en ny lång CRL publicerad	Avmarkera "Publicera Delta CRL"; kör certutil -crl	Ny tidsstämpel och giltighetsperiod för CRL-filen bekräftad	"CertUtil: -crl-kommandot MISSLYCKADES: 0x8007052e"	Återaktivera Delta CRL och återställ det tidigare publiceringsintervallet	PKI-administratör / Säkerhetsarkitekt
Gammal CA:s CDP/AIA omdirigerad till den nya platsen	IIS-omdirigeringsregel eller DNS CNAME-post	curl -I mot den gamla slutpunkten returnerar en omdirigering till den nya CDP/AIA	Klienter rapporterar en ogiltig AIA-kedja om den är felkonfigurerad	Ta bort omdirigeringen/CNAME och peka klienter tillbaka till de ursprungliga slutpunkterna	Plattformsteamet
Certifikatmallar dokumenterade och återaktiverade på den nya certifikatutfärdaren	Certutil -catemplates > c:\catemplates.txtaktivera via konsolen för certifikatmallar	Varje produktionsmall visas i den nya CA:ns utfärdbara lista	0x80094800 “Nekad av policymodul” om en mall saknas	Aktivera den saknade mallen; ingen återställning behövs på den gamla CA:n	PKI-administratör / Compliance
Gammal utfärdande CA avvecklad	Stoppa CA-tjänsten efter att det senast utfärdade certifikatet har löpt ut	Certifikatinventeringen bekräftar att inga aktiva certifikat refererar till den gamla certifikatutfärdaren	Avbrott i beroende applikation om ett certifikat missades under identifiering	Starta om den gamla CA-tjänsten och publicera dess CRL tills det missade certifikatet utfärdas på nytt.	PKI-administratör / CISO-signering

Certifikatlivscykelhantering och PKI-modernisering

Migrering av utfärdande CA:er är en del av en större praxis för hantering av certifikatlivscykeln. Att centralisera certifikatidentifiering och maskinidentitetsinventering innan migreringen gör det mycket enklare att fånga upp varje certifikatmall och beroende applikation – CertSecure Manager automatiserar hanteringen av certifikatlivscykeln, inklusive certifikatautomation för registrering och förnyelse, över lokala och molnbaserade CA:er. Organisationer som helt och hållet tar ur bruk en självhostad utfärdande CA bör utvärdera PKI-as-a-Service för PKI-modernisering med mindre driftskostnader.

Om denna migrering är en del av en bredare insats för kryptoagilitet, utforska PQC Center of Excellence för praktisk postkvanttestning och kör en PQC-beredskapsbedömning innan du slutför din nya CA:s certifikatmallar. Koppla båda med CBOM Secure för att upprätthålla en aktuell kryptografisk inventering så att nästa CA-migrering startar från dokumenterade data istället för en manuell granskning.

För mer information om den omgivande livscykeln, se Vilka är stegen i en certifikatlivscykel? och Hur man undviker certifikatavbrott.

Mätning av framgång och pågående revisioner

Spåra dessa signaler i minst 90 dagar efter övergången: noll CRL/AIA-hämtningsfel i webbserver- eller brandväggsloggar, 100 % av produktionscertifikatmallarna utfärdade från den nya certifikatutfärdaren och inga händelseloggfel i certifikatutfärdaren kopplade till den gamla certifikatutfärdarens roll i certifikattjänster. Ett felfritt godkännande på alla tre innebär att migreringen är slutförd och att den gamla certifikatutfärdaren säkert kan schemaläggas för avveckling.

Detta är en procedurmässig, leverantörsanpassad guide, så verifiera CDP/AIA- och certifikatmallens steg kvartalsvis mot aktuella CA/Browser Forum-krav, och verifiera den fullständiga genomgången minst var sjätte månad även om ingen policyändring har skett.

Slutsats

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från Hur man migrerar från en gammal CA till en ny utfärdande CA?

Den viktigaste slutsatsen är att migreringen av en CA endast lyckas när den gamla utfärdande CA:ns certifikat förblir giltiga under deras naturliga utgångsdatum, medan den gamla CA:n hindras från att utfärda något nytt, CDP/AIA-punkter omdirigeras utan att återkallningskontrollen avbryts och varje certifikatmall återaktiveras på den nya CA:n före övergången, så att ingen klient, server eller applikation som förlitar sig på dessa certifikat någonsin misslyckas med en valideringskontroll.

Varför är detta viktigt för PKI-team på stora företag?

Företags-PKI-team kör ofta en utfärdande certifikatutfärdare under dussintals beroende tjänster, från TLS-slutpunkter till kodsignering och enhetsautentisering, så en felaktigt hanterad migrering kan omedelbart avbryta återkallningskontroll eller certifikatregistrering i hela miljön. Att få CDP/AIA-omdirigering och mallinventering rätt från början undviker ett avbrott som påverkar alla applikationer som litar på den certifikatutfärdaren.

Vilka risker ökar om detta ämne hanteras manuellt?

Manuella migreringar ökar risken för missade certifikatmallar, inaktuella CRL-distributionspunkter som klienter inte längre kan nå och överblivna certifikat som ingen dokumenterade innan den gamla certifikatutfärdaren togs ur bruk. DigiCerts Trust Pulse-undersökning från 2025 visade att nästan hälften av företagen hade ett certifikatrelaterat avbrott under det senaste året, och manuell spårning var bland de främsta orsakerna som angavs av respondenterna.

Vilka lag borde ta över den här förändringen?

PKI-administratörer ansvarar för den tekniska överföringen, säkerhetsarkitekter godkänner CDP/AIA och malldesignen, plattformsteam uppdaterar eventuella automatiserings- eller CI/CD-pipelines som refererar till de gamla CA-slutpunkterna, och efterlevnadsteam bekräftar att ändringen uppfyller revisions- och certifikatpolicykraven innan den gamla CA:n tas ur drift.

Hur kopplas detta till hantering av certifikatlivscykeln?

Att migrera en utfärdande certifikatutfärdare är en händelse i hanteringen av certifikatens livscykel: det omfattar identifiering (dokumentation av varje utfärdat certifikat och mall), utfärdande (återaktivering av mallar på den nya certifikatutfärdaren) och pensionering (avaktivering av den gamla certifikatutfärdaren först efter att dess sista certifikat har löpt ut). Att behandla det som ett engångsskript istället för en livscykelprocess är det som orsakar de flesta migreringsavbrott.

Hur bör organisationer mäta framgång?

Framgång innebär noll certifikatvalideringsfel under och efter övergången, 100 % av aktiva certifikatmallar återaktiverade på den nya certifikatutfärdaren, en fullständigt omdirigerad CDP/AIA-kedja som matchas från varje klientsegment och en dokumenterad, tidsstämplad inventering av alla certifikat som fanns på den gamla certifikatutfärdaren innan den avvecklades.

Vad bör granskas eller övervakas regelbundet?

Organisationer bör övervaka CA-händelseloggar för registrerings- och återkallningsfel, bekräfta CRL-publiceringsintervall och Delta CRL-inställningar under migreringen, granska certifikatmallistan på båda CA:erna fram till avveckling och spåra certifikatvolym och utgångsdatum genom en centraliserad inventering snarare än kalkylblad per server.

Hur påverkar detta ämne moln-, hybrid- eller multi-CA PKI?

Moln- och hybrid-PKI-distributioner lägger till extra CDP/AIA-slutpunkter, lastbalanserare och hanterade CA-integrationer som alla måste omdirigeras konsekvent, och hierarkier med flera CA-certifikat kräver att samma mall och CRL-granskning upprepas för varje utfärdande CA i kedjan, vilket är anledningen till att de flesta företag hanterar detta via en plattform för certifikatlivscykelhantering snarare än manuellt.

Vilka förutsättningar krävs innan implementering?

Innan migreringen sker behöver teamen en ny server som är konfigurerad och installerad som utfärdande certifikatutfärdare, en dokumenterad lista över den gamla certifikatutfärdarens CDP/AIA-distributionspunkter, en fullständig export av certifikatmallar som för närvarande är publicerade och en återställningsplan med en säkerhetskopierad ögonblicksbild av certifikatutfärdarens databas som tas innan några register- eller malländringar börjar.

Vilka vanliga fel bör administratörer vara uppmärksamma på?

Håll utkik efter CRL_E_REVOCATION_OFFLINE (0x80092013) när klienter inte kan nå den nya CDP:n, "Nekad av policymodul" (0x80094800) när en mall ännu inte är aktiverad på den nya certifikatutfärdaren, felmeddelanden om nekad åtkomst (0x80070005) från att certutil körs utan utökade behörigheter och inaktuella AIA-kedjor när ett program fortfarande cachar den gamla certifikatutfärdarens certifikatsökväg.