Internal PKI and certificate authority migration playbook: moving platforms without losing control

Moving an internal certificate authority to a new platform is a trust migration, not a server move: every device, workload and user that trusts the old hierarchy, and every certificate it has issued, has to keep working while trust is shifted to new keys, new revocation endpoints and new enrolment paths. Organisations migrate internal PKI when the CA software or operating system reaches end of life, when they move from an on-premises CA to a managed or cloud-hosted CA, when hardware security modules are refreshed, after a merger, or when a weak hierarchy (SHA-1 roots, 1024-bit keys, an online root) has to be replaced. This playbook covers the decision between moving the existing CA keys and building a new hierarchy, the trust store and revocation work that decides whether the cutover is quiet, the enrolment paths and identities that keep issuing certificates, and how to retire the old CA without stranding anything. It is vendor-neutral and based on IETF PKIX standards, RFC 3647 and NIST guidance. Designing a hierarchy from scratch is covered in the Enterprise PKI Design and CA Hierarchy Guide, and the certificate lifecycle itself in the Machine Identity, PKI and Certificate Lifecycle Guide.

Key takeaways

• Decide early: move the keys or build a new hierarchy. Moving CA keys preserves trust but carries the old design and any doubt about the old keys; a new hierarchy is cleaner but means every relying party needs the new root.
• Distribute the new root first. Nothing issued by the new CA works until the new root is in every trust store that matters, so trust distribution starts weeks before the first certificate is issued.
• Revocation endpoints outlive the old CA. Certificates carry their CRL and AIA URLs for life; the old CA must keep publishing CRLs at those URLs until its last certificate expires or is replaced.
• Re-issue by renewal, not by big bang. Point renewals at the new CA and let certificates move at their next renewal, with targeted early re-issue only where lifetimes are long.
• Old CA keys must be retired deliberately. A decommissioned CA whose private key still exists, and whose root is still trusted, is a standing forgery risk.

What an internal CA migration actually moves

Choosing a migration strategy

The link certificate model is long established. RFC 9810, which obsoletes RFC 4210 for the Certificate Management Protocol, describes root CA key update in section 4.4: a new-with-new self-signed certificate plus optional link certificates, new-with-old (the new public key signed with the old private key) and old-with-new (the old public key signed with the new private key), so relying parties holding either key can validate certificates during the transition. RFC 5280 section 3.2 notes that self-issued certificates exist to support changes in policy or operations, which is exactly this case.

If CA keys must move

• Use the HSM's own key transfer: move keys between hardware modules using the vendor-supported wrapped backup or cloning mechanism, never as a plaintext export.
• Use multiple custodians (our recommendation): require two or more named people with split credentials, a written key ceremony script, and a witness who signs the log.
• Prove there are no other copies: list every backup of the CA key (tapes, HSM backup tokens, software keystores) and decide which survive. If you cannot account for every copy, choose a new hierarchy.
• Treat doubt as a reason to re-key: if the old CA key was ever held in software on a domain-joined server, a new hierarchy is safer than moving it.

Trust distribution and revocation continuity

Two things decide whether a CA migration is quiet: whether relying parties already trust the new root when the first new certificate arrives, and whether relying parties can still check revocation for old certificates after the old platform is gone.

Trust distribution

1. Inventory trust stores: operating system stores (pushed by directory policy or device management), language runtime stores, container base images, network appliances, load balancers, VPN and wireless controllers, mobile devices and third parties that trust your internal CA.
2. Distribute the new root and intermediates: through the normal configuration channels, and rebuild base images so new workloads include it.
3. Verify, do not assume: test path building from a sample of each client type against a test certificate from the new CA before issuing anything production-facing.
4. Remove the old root last: only after its last certificate has expired or been replaced, and after a waiting period. The detail is in the Certificate trust stores and root CA management guide.

Revocation continuity

Every certificate carries its CRL Distribution Points (RFC 5280 section 4.2.1.13) and Authority Information Access (section 4.2.2.1, with caIssuers and ocsp locations) for its whole life. These URLs cannot be changed on certificates already issued. RFC 5280 section 5.1.2.5 requires conforming CRL issuers to include nextUpdate in every CRL, so once the old CA stops publishing, its last CRL goes stale and clients that enforce revocation checking start failing. Section 4.1.2.5 adds that if an issuer cannot keep status information until a certificate's notAfter date, it must make sure no valid certification path exists after maintenance ends.

• Keep the old CA signing CRLs: run it in a reduced, issue-nothing mode until its last certificate expires, or pre-sign long-lived CRLs only as a deliberate, documented decision.
• Keep old URLs resolving: move CRL and AIA hosting to a highly available web endpoint under a DNS name you control, independent of either CA platform.
• Delegated OCSP responders: RFC 6960 section 4.2.2.2 requires a delegated responder certificate carrying id-kp-OCSPSigning to be issued directly by the CA it answers for, so each CA, old and new, needs its own responder certificate. Section 4.2.2.2.1 warns that a responder key compromise with id-pkix-ocsp-nocheck is as serious as a CA key compromise for that certificate's validity, so keep those certificates short-lived.

Revocation mechanics are covered in the Certificate Revocation Guide.

Templates, enrolment and issuance policy

The old CA's templates and enrolment permissions are often the weakest part of the estate. Migration is the cheapest moment to fix them, because every template is being rebuilt anyway.

• Translate by intent: for each template record its purpose, key usage, extended key usage, maximum lifetime, key algorithm and size, how the subject is built, who may enrol and whether approval is required. Drop templates with no issuance in the last year (our recommendation).
• Close subject supply by requester: templates that let the requester supply any subject or subject alternative name, combined with a client authentication EKU, allow impersonation. These misconfigurations are described in the How to audit AD CS certificate templates guide; do not carry them across.
• Constrain the new CA: where the platform and clients support it, add a nameConstraints extension to the issuing CA certificate. RFC 5280 section 4.2.1.10 requires conforming CAs to mark it critical and applies it only to CA certificates.
• Recreate enrolment paths: ACME for servers and workloads, EST or SCEP for network devices and mobile management, CMP where it is already in use, and directory auto-enrolment for domain-joined machines. See the ACME and Automated Certificate Management Guide and the IoT and Device Certificate Provisioning (EST, SCEP) Guide.
• Update the CP and CPS: RFC 3647 provides the outline; its key changeover, compromise and disaster recovery, and CA or RA termination topics (section 4.5.6 to 4.5.8) are exactly what a migration changes. The policy framework is in the ISO/IEC 27099 PKI Practices and Policy Framework Guide.

Where identity fits

An internal CA is a machine identity factory: most certificates it issues authenticate servers, workloads, devices and service accounts. The migration also creates new, very powerful identities of its own.

• Enrolment agents and registration authorities: accounts or certificates that can request certificates on behalf of others. Recreate them with the narrowest template scope and list them by name.
• Automation credentials: ACME account keys, EST client certificates, SCEP challenge secrets and API tokens used by certificate lifecycle tools. Issue new ones for the new CA rather than copying old secrets, and revoke the old ones at cutover.
• CA administrators: separate CA administrators, certificate managers and auditors (NIST SP 800-53 AC-5), and require phishing-resistant MFA from a privileged access workstation for console access.
• Authentication certificates: where certificates authenticate users or machines to a directory, the new CA must be trusted for that purpose before users depend on it. See the Kerberos PKINIT and Certificate Mapping Guide.

Attackers who can enrol for authentication certificates, or steal a CA key, gain durable access (MITRE ATT&CK T1649, Steal or Forge Authentication Certificates). The old CA remains a target until its key is destroyed.

The phased playbook

1. Inventory: list every CA, its keys and where they live, templates, enrolment endpoints, CRL and AIA URLs, and the issued-certificate database. Build a certificate inventory from the CA databases plus network discovery, because certificates issued years ago may still be deployed. The Certificate Inventory Register Template gives a structure.
2. Decide the strategy: lift keys, new issuing CA under the existing root, or new hierarchy. Record the reason and the evidence about old key custody.
3. Build the target: offline root in an HSM, issuing CAs, stable CRL and AIA URLs on platform-independent hosting, OCSP responders, rebuilt templates and enrolment endpoints. Run a key ceremony with a signed script.
4. Distribute trust: push the new root and intermediates to all trust stores, rebuild images, and confirm path building on every client type.
5. Pilot: issue to one low-risk service and one device type end to end, including renewal, revocation, CRL and OCSP checks from clients that enforce revocation, and a rehearsed rollback.
6. Switch renewals: point automated renewal at the new CA in waves. Stop new issuance on the old CA by disabling its templates and enrolment endpoints, but keep it publishing CRLs.
7. Re-issue long-lived certificates: certificates that would otherwise stay on the old CA for years, such as device and appliance certificates, get a planned early re-issue.
8. Retire the old CA: when the inventory shows no valid certificates from it, publish a final CRL, remove the old root from trust stores after a waiting period, archive logs and the database, and destroy or zeroise the old CA keys and HSM partitions following NIST SP 800-88 Rev. 2.

Rollback: until the old CA's templates are deleted and its keys destroyed, rollback means re-enabling issuance on the old CA and pointing renewals back to it. Keep the old CA able to issue for at least one full renewal cycle after the switch (our recommendation). Certificates already issued by the new CA keep working as long as its root stays trusted, so rollback never requires removing the new root.

Small and large organisations: a small estate with one two-tier hierarchy and a few hundred certificates can often move in a single quarter with a new hierarchy and renewal-driven re-issue. A large estate with several hierarchies, appliances and third-party relying parties should expect the old CA to stay in CRL-only mode for the longest certificate lifetime it ever issued, and may need link certificates.

Detection and measurement

Log CA events (requests, issuance, revocation, template and permission changes, CA configuration changes, key use) from both CAs to the same place for the whole migration, and keep them for the period your CP requires.

Common failure patterns

• Old CRLs going stale: the old CA is switched off, its CRL passes nextUpdate, and every client enforcing revocation fails at once, often months after the "finished" migration.
• Issuing before the root is trusted: new certificates go live while appliances, containers or language runtime trust stores still only know the old root.
• Carrying risky templates across: requester-supplied subjects and broad enrolment rights move to the new platform unchanged.
• Old CA key never destroyed: a retired CA key that still exists and is still trusted can sign anything. The Microsoft Storm-0558 key breach showed the impact of an old signing key that remained trusted and usable long after it should have been out of play.
• Hostname-bound URLs: CRL and AIA URLs pointing at the old server's name, which is then decommissioned or reused.
• Forgotten automation secrets: SCEP challenge passwords and enrolment API tokens for the old CA left valid after cutover.

Framework mapping

T1553.004 (Install Root Certificate) is relevant because the trust store changes a migration requires use the same channels an attacker would abuse: restrict who can push trust anchors and alert on unexpected additions.

Practitioner checklist

• Record the strategy decision (lift keys, new issuing CA, new hierarchy) and the evidence about old key custody.
• Inventory trust stores by client type and confirm the new root is present before production issuance.
• Host CRL and AIA on stable, platform-independent URLs and alert before any CRL nextUpdate passes.
• Keep the old CA publishing CRLs until its last valid certificate is gone.
• Rebuild templates by intent; remove requester-supplied subjects on authentication templates.
• Issue new automation credentials for every enrolment path and revoke the old ones at cutover.
• Separate CA administrator, certificate manager and auditor roles in the new platform.
• Re-issue long-lived device and appliance certificates on a planned schedule.
• Remove the old root only after a waiting period, then destroy old CA keys and sanitise HSMs.
• Update the CP and CPS and archive both CAs' logs and databases.

Standards and references

• IETF: RFC 5280, Internet X.509 PKI Certificate and CRL Profile
• IETF: RFC 9810, Certificate Management Protocol (CMP)
• IETF: RFC 6960, Online Certificate Status Protocol (OCSP)
• IETF: RFC 3647, Certificate Policy and Certification Practices Framework
• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
• NIST: SP 1800-16, Securing Web Transactions: TLS Server Certificate Management
• NIST: SP 800-88 Rev. 2, Guidelines for Media Sanitization
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: Internal PKI and certificate authority rollout playbook · Securing the internal PKI and certificate authority itself · CA Compromise and Mass Certificate Replacement Playbook · Certificate lifecycle manager migration playbook · AD CS Security Guide