Share via

Replacing PKI Enterprise CA (Root and Issuing CA on single server) with 2 Tier PKI Root CA and separate CA issuing server

Tim Gross 106 Reputation points
2026-05-13T16:27:54.16+00:00

We are looking to change our PKI implementation from a single server in the domain running the Root and Issuing CA server with a lot of defaults, to a best practices Infrastructure with a two tier PKI Root CA (non-domain) and Issuing CA (domain joined) and I'm not finding great articles regarding the specific scenario. The existing server is running Server 2012R2 and the new will be setup on Server 2025.

I don't really want to assume anything, since this is our opportunity to get things right, but of the list below, what am I looking at and what else would need to be done?

  1. Backup the Root/Issuing CA/ Private key and CA certificate, Certificate Database, Certificate Database log, and CA Registry.
  2. Edit the "CAServerName"="newservername.domain.com" in the registry.
  3. Restore CA Backup
  4. Import CA Registry Settings
  5. Remove AD Certificate Service roles from old Issuing CA/remove Issuing CA from domain
  6. Import Issuing CA/Issuing CA Registry - Edit the "CAServerName" to new server name
  7. Re-Deploy Certificate Templates (from old server or go with new templates?)

May be overthinking this due to the addition of the Root CA and the two tier model but I wanted to verify.

Windows for business | Windows Server | Directory services | Certificates and public key infrastructure (PKI)
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. HLBui 6,190 Reputation points Independent Advisor
    2026-05-13T17:11:50.0466667+00:00

    Good day Tim Gross

    Moving from a single-server PKI setup to a proper two-tier model is a smart move, and you’re right to want to get it right this time. The big picture is: your offline Root CA (non-domain joined) will only issue certs to your Issuing CA, and the Issuing CA (domain joined) will handle all the day-to-day cert requests. That separation is what gives you resilience and security

    About your checklist : backing up the Root/Issuing CA keys, certs, and databases is absolutely step one, no shortcuts there. Editing the CAServerName in the registry is valid, but I’d caution against relying solely on registry tweaks; Microsoft’s recommended approach is to properly migrate the CA role using backup/restore rather than manual edits. Restoring the CA backup and importing registry settings is fine, but make sure you test this in a lab first, because mismatched permissions or missing templates can bite you. Removing the old Issuing CA from the domain is correct, but don’t forget to clean up any lingering DNS/SPN entries tied to that server.

    For templates, I’d suggest re-deploying fresh ones where possible it’s a good chance to modernize and enforce updated security baselines instead of dragging old defaults forward. Also, plan for publishing the new CRL and AIA locations, since clients will need to trust the new hierarchy. Finally, document every step and keep your Root CA offline except when you need to issue or renew the Issuing CA cert. PKI migrations are tricky, and caution here is a virtue

    If this guidance proves helpful, feel free to click “Accept Answer” so we know we’re heading in the right direction and let me know if you need any assistance. Thank you!

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.