Introduction

A PKI migration can move certificate services to the new environment while issued certificates still tell clients to validate revocation status against the old CRL or OCSP endpoints. Browsers show revocation-check failures, appliances reject otherwise valid certificates, or one certificate profile works while another still depends on the retired PKI because revocation and AIA metadata are often embedded in certificates long before the backend changes.

Treat this as a certificate-metadata problem instead of assuming the new PKI is down. Start by checking what CRL distribution point, OCSP responder, and AIA URL an affected certificate actually contains, because migrations often update servers and publishing jobs while clients continue obeying the URLs baked into live certificates.

Symptoms

  • Certificate validation still tries the old CRL or OCSP endpoint after migration
  • Revocation checks fail only after the legacy PKI URLs are disabled
  • Newly deployed certificates work, but older ones still reference the previous PKI
  • One application validates successfully while another still depends on the retired responder
  • Browsers, VPNs, or appliances report revocation or chain retrieval errors after cutover
  • The issue started after moving certificate authorities, OCSP responders, CRL publication, or PKI web services

Common Causes

  • Certificate profiles still publish old CRL distribution point or OCSP URLs
  • AIA extensions still reference the retired issuing CA or certificate download path
  • Existing certificates were issued before the migration and still carry old revocation metadata
  • One CA template or subordinate CA was updated while another still issues certificates with the previous URLs
  • DNS, load balancers, or web publication keep serving old PKI hostnames from the wrong environment
  • Validation confirmed the new PKI endpoints were online but did not inspect the URLs embedded in real certificates

Step-by-Step Fix

  1. Export one affected certificate and record its CRL distribution points, OCSP URL, and AIA values, because the certificate metadata determines where clients actually validate status.
  2. Compare those embedded URLs with the intended post-migration PKI endpoints, because one stale extension value can keep large parts of the environment dependent on the retired infrastructure.
  3. Review certificate templates, CA extension settings, OCSP responder configuration, CRL publication jobs, and published PKI URLs for references to the old environment, because revocation validation spans issuance and hosting layers.
  4. Separate new certificates from pre-migration certificates during troubleshooting, because clients may behave differently depending on when the certificate was issued.
  5. Update the authoritative CA and publication settings so newly issued certificates contain the intended CRL, OCSP, and AIA paths, because moving the responder servers alone does not rewrite extension values.
  6. Reissue or replace affected certificates where necessary and confirm new samples contain only the intended PKI URLs, because healthy publication endpoints do not help if certificates still advertise the old ones.
  7. Verify the old revocation endpoints no longer receive validation traffic from migrated systems, because mixed certificate populations can hide dependency on the previous PKI.
  8. Review cache lifetimes, responder signing certificates, and intermediate-chain distribution if failures continue, because the metadata can be correct while revocation content or trust paths remain stale.
  9. Document which team owns CA extensions, certificate profiles, and revocation endpoint validation so future PKI migrations test the URLs embedded in live certificates before retiring the previous platform.