Introduction

A PKI migration can bring the new certificate authority online while domain-joined devices still request certificates from the old CA. New certificates keep showing the retired issuer, auto-enrollment fails after the legacy CA is shut down, or one OU gets the new chain while another still talks to the previous enrollment service because certificate templates, Active Directory publication, and GPO-based enrollment settings often move in stages.

Treat this as an enrollment-path problem instead of a generic certificate failure. Start by checking which CA an affected device actually contacts for auto-enrollment, because migrations often validate the new issuing CA and templates while clients continue following older AD-published enrollment data or policy.

Symptoms

  • Devices still auto-enroll against the old CA after migration
  • Newly issued machine or user certificates show the retired issuer
  • Auto-enrollment succeeds in one OU or site but not another
  • Certificate requests fail only after the old CA is decommissioned
  • Group Policy refresh completes, but devices still use the previous CA path
  • The issue started after moving Active Directory Certificate Services, templates, or enrollment policy

Common Causes

  • Auto-enrollment policy or GPO still references the old CA configuration
  • Certificate templates are still published on the retired CA but not the new one
  • Active Directory still advertises the old enrollment services object
  • One issuing CA was updated while another site or domain controller still publishes stale data
  • Cached certificate enrollment metadata or stale trust information survives the migration
  • Validation confirmed the new CA could issue certificates but did not verify which CA clients actually selected

Step-by-Step Fix

  1. Capture one affected device and record the issuer, enrollment event log entries, and CA configuration it actually uses, because the live enrollment target matters more than the migration diagram.
  2. Compare that active CA path with the intended post-migration PKI design, because one stale enrollment object or template publication can keep whole device groups tied to the retired authority.
  3. Review certificate template publication, auto-enrollment GPO settings, Enrollment Services objects in Active Directory, and CA permissions for references to the old CA, because client enrollment depends on directory, policy, and CA-layer data together.
  4. Check different OUs, sites, and domain controllers separately if behavior is inconsistent, because PKI migrations often fix one replication path while another still advertises the previous CA.
  5. Update the authoritative CA publication and auto-enrollment configuration so affected clients discover and request from the intended issuing CA, because standing up a new CA alone does not retarget existing enrollment decisions.
  6. Force a controlled policy refresh and auto-enrollment cycle on one affected device and confirm the new certificate chains to the intended CA, because a successful enrollment still does not prove the old authority is no longer in use.
  7. Verify the old CA no longer receives requests from migrated devices, because split enrollment can remain hidden while both authorities are online.
  8. Review CRL availability, template ACLs, and certificate validity overlap if devices still fail after retargeting, because the destination can be correct while issuance prerequisites remain broken.
  9. Document which team owns template publication, AD CS objects, and enrollment validation so future PKI migrations verify the actual issuing CA used by clients before retiring the previous service.