How to migrate from old CA to a new Issuing CA

Issuing CA often needs to be decommissioned for a variety of reasons, such as

• The operating system is reaching the end of its life
• CA might be compromised
• CA is having operational issues and is too complicated to clean up.

No matter the reason, migrating to a new issuing CA can seem easy. Still, it can come with new challenges, such as mitigating risks, minimizing operational impact, etc.

While migrating issuing CAs, we need to ensure,

1. The current certificates that are issued remain operational until their validity runs out.
2. The old issuing CA should not issue any more certificates.
3. We can move to other CDP/AIA points according to the required changes, but the issuing CA would have a minimal operation and no impact on the PKI infrastructure.

Quick Answer: How to Migrate to a New Issuing CA

Migrating to a new issuing CA means standing up a replacement CA, redirecting CDP/AIA distribution points, disabling Delta CRL publishing on the old CA, documenting and re-enabling certificate templates on the new infrastructure, and decommissioning the old CA only after every certificate it issued has expired or been reissued, with zero disruption to certificate validation.

Last updated: August 2026 · Last verified: August 2026 · Recommended refresh cadence: re-verify the CA/Browser Forum validity-period references quarterly, and re-verify the full walkthrough at least every 6 months since this is an evergreen procedural guide.

Executive Summary: Key Takeaways

• Keep certificates valid: existing certificates issued by the old CA stay valid until their natural expiration; only the old CA’s ability to issue new certificates is shut off.
• Redirect, don’t delete: CDP and AIA distribution points are redirected to the new CA’s endpoints so revocation checking never breaks mid-migration.
• Inventory every template: every certificate template in use on the old CA is documented and re-enabled on the new CA before cutover.
• Validate before decommissioning: the old CA is retired only after CRL/AIA checks succeed against the new infrastructure and zero active certificates still depend on it.
• Rollback is built in: each phase (Delta CRL, redirects, templates) has a documented rollback so a failed step doesn’t turn into an outage.

Who Should Care About This Migration

An issuing CA migration touches more than the PKI team running the commands. Here is what each role should own.

PKI Administrators

Own the technical cutover: run the CDP/AIA audit, execute the certutil steps, document every certificate template, and hold the decommission timeline for the old CA.

Security Architects

Design the CDP/AIA layout for the new CA, approve the certificate template inventory, and confirm the new CA supports the crypto agility the organization will need for future algorithm changes.

Platform Teams

Update CI/CD pipelines, automation scripts, load balancers, and DNS/IIS redirect rules that still reference the old CA’s endpoints before the old CA is stopped.

Compliance Teams

Confirm the change satisfies the organization’s Certificate Policy/Certification Practice Statement (CP/CPS), keep an audit trail of the decommissioning decision, and retain the certificate inventory for the required records-retention period.

CISOs

Track outage risk across the migration window, sign off on the old CA’s decommissioning, and ensure the change is logged as a governance event rather than an undocumented infrastructure task.

Why This Matters: Data and Deadlines

According to DigiCert’s Trust Pulse survey (published July 2, 2025), nearly half of enterprises experienced a certificate-related outage in the past year, and 37.5% specifically traced an outage to an expired certificate; 18.5% of affected organizations reported losses over $250,000. A rushed or undocumented issuing CA migration is exactly the kind of change that produces this failure mode.

The CA/Browser Forum’s Ballot SC-081v3 (approved April 11, 2025) locks in a phased reduction of maximum TLS certificate validity: 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. Shorter certificate lifetimes mean any issuing CA, old or new, reissues certificates far more often, which raises the operational cost of a manual, undocumented CDP/AIA or template migration.

On the cryptography side, NIST finalized its first three post-quantum standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), on August 13, 2024. Any new issuing CA stood up today should be evaluated for crypto agility against these algorithms so it doesn’t need a second migration once PQC-ready certificate profiles become mandatory.

Prerequisites

Before you begin, confirm the following are in place:

• A new server provisioned, configured, and installed with the issuing CA role.
• Administrative access to both the old and new Certification Authority consoles and an elevated command prompt on each.
• A backup of the old CA’s database and registry CDP/AIA values taken before any changes begin, so the migration can be rolled back at any step.
• Change-control and downtime-window approval if the environment enforces certificate policy governance.

Step-by-Step Migration Procedure

These steps will help organizations migrate to new issuing CA.

If CDP/AIA points are not being changed, steps 2, 4, and 5 are optional and shouldn’t be followed.

1. Log onto the old Issuing CA
2. Identify CDP/AIA Distribution Points (optional)
   1. Open command prompt
   2. Type the command

      certutil -getreg CA\CACertPublicationURLs

      

   3. Document the HTTP AIA points. Ignore LDAP and C:\%windir%

      As per the screenshot, the AIA point is http://pki.encon.com/CertEnroll/%1_%3%4.crt

      %1 refers to ServerDNSName

      %3 refers to CaName

      %4 refers to Certificate Name

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

   4. Type the command

      certutil -getreg CA\CRLPublicationURLs

      

   5. Document the HTTP CDP Points. Ignore LDAP and C:\%windir%

      As per the screenshot, the CDP point is http://pki.encon.com/CertEnroll/%3%8%9.crl

      %3 refers to CaName

      %8 refers to CRLNameSuffix

      %9 refers to DeltaCRLAllowed

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



3. Disabling the Delta CRL and issue a new long Certificate Revocation List (CRL)
   1. Open Certificate Authority Console

      

   2. Right-click on Revoked Certificates, and then click properties

      

   3. Uncheck “Publish Delta CRL”

      

   4. Edit the “CRL publication interval” to 99 years

      

      Click OK

   5. Open command prompt as administrator
   6. Type the following command

      certutil -crl

      

4. Copy old CA’s certificate (crt) and Certificate Revocation List (CRLs) files to new CDP/AIA Points (optional)
   1. Navigate to %windir%\System32\CertSrv\CertEnroll
   2. Copy the old CA’s crt and CRL files to new CDP/AIA Points

      

5. Redirect AIA and CDP points of old CA to the new location

   This can be done using an

   1. IIS redirect, or
   2. DNS CNAME

      redirecting the AIA and CRL of the old Certification Authority.

6. Document all certificate templates and stop certificate publishing on old Issuing CA
   1. Open the command line with elevated privileges
   2. Run

      Certutil -catemplates > c:\catemplates.txt

      and document all certificate templates published at the old Certification Authority

      

      In total, certificate templates are present.

   3. Launch the Certification Authority console
   4. Navigate to “Certificate Templates”
   5. Highlight all templates in the right pane, right-click and then click “Delete”

      

      The old Certification Authority cannot issue any certificates and has all of its AIA and CRLs redirected to a new CRL Distribution point. The next steps will detail how users can document the certificates templates published on the old issuing CA and how to make them available at the new issuing CA.

7. Sort Certification Authority Database, identify and document all certificates issued based on certificate templates
   1. Open Certificate Authority Console.
   2. Highlight Issued Certificates.
   3. Move to the right and sort by “Certificate Templates.”

      

   4. Identify the certificates that are issued by default certificate template types.
   5. Document the certificates issued by custom certificate templates i.e. any template other than the default certificate templates.



8. Document certificates based on default certificate template types
   1. Open command prompt with elevated privileges
   2. Run

      Certutil -view -restrict “Certificate Template=Template” -out “SerialNumber,NotAfter,DistinguishedName,CommonName”> c:\TemplateType.txt

      Note: Replace the Template with the correct template name

      

   3. Review the output on TemplateType.txt and document all certificates that need immediate action (requiring issuance from the new CA infrastructure if needed, such as Web Server Certificate)
   4. Consult with application administrators using the certificates to determine the best approach to replace the certificates if needed
9. Document certificates based on custom certificate types
   1. Open Certification Authority Console
   2. Right click on Certificate Templates, and click Manage

      

   3. Double-click the certificate template and click on the “Extensions” tab

   

   4. Click on “Certificate Template Information”

   

   5. Copy the Object Identifier (OID) number – the number will look similar to

      1.3.6.1.4.1.311.21.8.5363900.15781253.12798358.11444918.12080715.141.12736713.11129372

   6. Open the command prompt with elevated privileges
   7. Run

      Certutil -view -restrict “Certificate Template= 1.3.6.1.4.1.311.21.8.5363900.15781253.12798358.11444918.12080715.141.12736713.11129372″ -out “SerialNumber,NotAfter,DistinguishedName,CommonName”> c:\CustomTemplateType.txt

      Note: Replace the OID number with the number identified in step 5

      

   8. Examine the output of c:\CustomTemplateType.txt and document all the certificates needing immediate action (requiring issuance from the new CA infrastructure if needed, such as custom SSL certificates).
   9. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed
10. Enable certificate templates needed on the results of steps 7 to 9 on new Issuing CA
    1. Login to new Issuing CA.
    2. Right-click on “Certificate Templates,” click New, and click “Certificate Templates to Issue.”

       

    3. Choose all certificate templates needed in the “Enable Certificate Templates” windows and click >OK.

       

Validation Checks After Migration

Run these checks before you consider the migration complete:

• From a client outside the CA’s own network, fetch the new CDP and AIA URLs directly (browser or curl -I) and confirm both return valid, current .crl and .crt files.
• Run certutil -verify against a certificate freshly issued by the new CA and confirm the chain builds and revocation status resolves without warnings.
• Compare the new CA’s issuable template list against the documented output of certutil -catemplates from the old CA and confirm nothing is missing.
• Check the CA event log on both CAs (Event Viewer > Applications and Services Logs > Microsoft > Windows > CertificateServicesClient) for enrollment or revocation errors during the migration window.
• Confirm the old CA’s CRL is still reachable and unexpired until the last certificate it issued expires, even after publishing stops.

Common Errors and Error Codes

• CRL_E_REVOCATION_OFFLINE (0x80092013): a client can’t reach the new CDP; usually a firewall rule, DNS record, or IIS redirect that wasn’t updated.
• “Denied by Policy Module” (0x80094800): the requested certificate template hasn’t been enabled on the new CA yet; re-check the template inventory from step 7.
• Access denied (0x80070005): certutil commands were run without an elevated command prompt or the account lacks CA administrator rights.
• “CertUtil: -crl command FAILED: 0x8007052e”: the CA service account doesn’t have permission to publish the CRL; verify the service account and file share permissions.
• Stale AIA chain in applications: an application still caches the old CA’s certificate path after the redirect; clear the application’s certificate cache or restart the dependent service.

Rollback Steps

If validation fails at any point, roll back before touching the next step:

1. Re-check the “Publish Delta CRL” box and restore the original CRL publication interval if you disabled it and the new CA isn’t ready.
2. Restore the old CA’s CDP/AIA registry values from your documented certutil -getreg output if a redirect breaks revocation checking.
3. Remove or disable the IIS redirect rule or DNS CNAME and point clients back to the old CA’s original endpoints.
4. Re-enable the certificate templates on the old CA if it must keep issuing while a missing template is added to the new CA.
5. Restore the CA database from the pre-migration backup snapshot only as a last resort, since this also rolls back any certificates issued after the snapshot.

Migration Reference Table

Use this table as a quick-reference summary of each migration phase.

Prerequisite	Command / Configuration	Validation Check	Common Error	Rollback	Owner
New CA server provisioned with the issuing CA role installed	Install and configure the Certification Authority role on the new server	certutil -viewstore confirms the new CA’s certificate chain	0x80070005 (access denied) if not run elevated	Remove the CA role; no production traffic depends on it yet	PKI Administrator
Old CA’s CDP/AIA points documented	certutil -getreg CA\CACertPublicationURLs / CRLPublicationURLs	HTTP endpoints resolve and return valid .crt/.crl files	0x80092013 CRL_E_REVOCATION_OFFLINE if unreachable	Restore original registry values from documented output	PKI Administrator
Delta CRL disabled and a new long CRL published	Uncheck “Publish Delta CRL”; run certutil -crl	New CRL file timestamp and validity period confirmed	“CertUtil: -crl command FAILED: 0x8007052e”	Re-enable Delta CRL and restore the prior publication interval	PKI Administrator / Security Architect
Old CA’s CDP/AIA redirected to the new location	IIS redirect rule or DNS CNAME record	curl -I against the old endpoint returns a redirect to the new CDP/AIA	Clients report an invalid AIA chain if misconfigured	Remove the redirect/CNAME and point clients back to the original endpoints	Platform Team
Certificate templates documented and re-enabled on the new CA	Certutil -catemplates > c:\catemplates.txt; enable via Certificate Templates console	Every production template appears in the new CA’s issuable list	0x80094800 “Denied by Policy Module” if a template is missing	Enable the missing template; no rollback needed on the old CA	PKI Administrator / Compliance
Old issuing CA decommissioned	Stop the CA service after the last issued certificate expires	Certificate inventory confirms zero active certificates reference the old CA	Dependent application outage if a certificate was missed during discovery	Restart the old CA service and re-publish its CRL until the missed certificate is reissued	PKI Administrator / CISO sign-off

Certificate Lifecycle Management and PKI Modernization

Issuing CA migration is one piece of a larger certificate lifecycle management practice. Centralizing certificate discovery and machine identity inventory before you migrate makes it far easier to catch every certificate template and dependent application — CertSecure Manager automates certificate lifecycle management, including certificate automation for enrollment and renewal, across on-premises and cloud CAs. Organizations retiring a self-hosted issuing CA altogether should evaluate PKI-as-a-Service for PKI modernization with less operational overhead.

If this migration is part of a broader crypto agility effort, explore the PQC Center of Excellence for hands-on post-quantum testing, and run a PQC readiness assessment before finalizing your new CA’s certificate templates. Pair both with CBOM Secure to maintain a current cryptographic inventory so the next CA migration starts from documented data instead of a manual audit.

For more on the surrounding lifecycle, see What Are the Stages in a Certificate Lifecycle? and How to Avoid Certificate Outages.

Measuring Success and Ongoing Audits

Track these signals for at least 90 days after cutover: zero CRL/AIA fetch failures in web server or firewall logs, 100% of production certificate templates issued from the new CA, and no CA event log errors tied to the old CA’s certificate services role. A clean pass on all three means the migration is complete and the old CA is safe to schedule for decommissioning.

This is a procedural, vendor-adjacent guide, so re-verify the CDP/AIA and certificate-template steps quarterly against current CA/Browser Forum requirements, and re-verify the full walkthrough at least every 6 months even if no policy change has occurred.

Conclusion

Frequently Asked Questions

What is the main takeaway from How to migrate from old CA to a new Issuing CA?

The main takeaway is that CA migration succeeds only when the old issuing CA’s certificates stay valid through their natural expiration while the old CA is stopped from issuing anything new, CDP/AIA points are redirected without breaking revocation checking, and every certificate template is re-enabled on the new CA before cutover, so no client, server, or application relying on those certificates ever fails a validation check.

Why does this matter for enterprise PKI teams?

Enterprise PKI teams often run one issuing CA underneath dozens of dependent services, from TLS endpoints to code signing and device authentication, so a mishandled migration can break revocation checking or certificate enrollment across the environment at once. Getting the CDP/AIA redirect and template inventory right the first time avoids an outage that touches every application trusting that CA.

What risks increase if this topic is handled manually?

Manual migrations increase the risk of missed certificate templates, stale CRL distribution points that clients can no longer reach, and orphaned certificates nobody documented before the old CA was retired. DigiCert’s 2025 Trust Pulse survey found nearly half of enterprises had a certificate-related outage in the past year, and manual tracking was among the leading causes cited by respondents.

Which teams should own this change?

PKI administrators own the technical cutover, security architects sign off on the CDP/AIA and template design, platform teams update any automation or CI/CD pipelines that reference the old CA endpoints, and compliance teams confirm the change satisfies audit and certificate-policy requirements before the old CA is decommissioned.

How does this connect to certificate lifecycle management?

Issuing CA migration is a certificate lifecycle management event: it touches discovery (documenting every issued certificate and template), issuance (re-enabling templates on the new CA), and retirement (decommissioning the old CA only after its last certificate expires). Treating it as a one-off script instead of a lifecycle process is what causes most migration outages.

How should organizations measure success?

Success means zero certificate validation failures during and after cutover, 100% of active certificate templates re-enabled on the new CA, a fully redirected CDP/AIA chain that resolves from every client segment, and a documented, time-stamped inventory of every certificate that existed on the old CA before it was decommissioned.

What should be audited or monitored regularly?

Organizations should monitor CA event logs for enrollment and revocation errors, confirm CRL publication intervals and Delta CRL settings during migration, audit the certificate template list on both CAs until decommissioning, and track certificate volume and expiration dates through a centralized inventory rather than per-server spreadsheets.

How does this topic affect cloud, hybrid, or multi-CA PKI?

Cloud and hybrid PKI deployments add extra CDP/AIA endpoints, load balancers, and managed-CA integrations that all need to be redirected consistently, and multi-CA hierarchies require the same template and CRL audit to be repeated for every issuing CA in the chain, which is why most enterprises manage this through a certificate lifecycle management platform rather than manually.

What prerequisites are required before implementation?

Before migrating, teams need a new server configured and installed as the issuing CA, a documented list of the old CA’s CDP/AIA distribution points, a full export of certificate templates currently published, and a rollback plan with a backed-up CA database snapshot taken before any registry or template changes begin.

What common errors should administrators watch for?

Watch for CRL_E_REVOCATION_OFFLINE (0x80092013) when clients cannot reach the new CDP, “Denied by Policy Module” (0x80094800) when a template is not yet enabled on the new CA, access-denied errors (0x80070005) from running certutil without elevated privileges, and stale AIA chains when an application still caches the old CA’s certificate path.