Understanding Certificate Authority Errors in Windows Active Directory

Problem Diagnosis

We have a Certificate Authority (CA) that was moved from an old, now-retired server over six months ago. However, the migration wasn’t fully completed, and critically, the revocation database didn’t make the jump. Now, we’re hitting problems. Certificates issued by that original server can’t be renewed because of this missing revocation database.

So here’s the crux of it:

1. What’s the best way to tackle this situation moving forward?
2. Specifically, how do we redirect renewal requests to the new server when those existing certificates are still tied to a revocation database that no longer exists?
3. And looking ahead, if we decide to migrate the current CA again to a fresh server, what happens to the certificates already issued by the current setup?

Resolution

Below is a field-tested sequence that PKI admins use when a CA migration was botched and the revocation database (CertSrv edb + log files) is missing.
I’ve assumed the machine in question is an Enterprise Root CA running Active Directory Certificate Services (AD CS).
If yours is a subordinate CA, the same steps apply—just add “renew the subordinate-CA certificate with the (offline) root” to the plan.

1. Stop, take a breath, and inventory what you still have 🔍

Needed to salvage the CA	Do you have it?	Notes
CA private key (.p12 from certutil –backupkey or the machine’s CSP/KSP)	✔ / ✖	Without it the CA’s name cannot be resurrected.
CA certificate (<CAname>.crt)	✔ / ✖	Should be in CertEnroll or in AD (CN=Certification Authorities,CN=Public Key Services,Configuration,…).
CA database (Certsrv\CertEnroll\*.edb + *.log)	✔ / ✖	Holds all issued-cert records, serial numbers, and revocation entries.
Registry config (HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CAname>)	✔ / ✖	Drives CRL/AIA paths, templates, etc.
The last CRL / ΔCRL files	✔ / ✖	Lets you publish a “bridge” CRL if no database can be recovered.

You have a copy of system32\certsrv and a “CA backup that was already restored once.”
That strongly suggests the database is in there—it just wasn’t restored correctly.

---

2. Try a clean, offline restore of the CA (preferred path)

1. Spin up a throw-away VM with the same Windows Server major version the old CA ran (2012 R2, 2016 etc.).
   Join it to the domain if the CA was Enterprise, and give it the same computer name the retired CA had (this avoids having to edit every AIA/CRL URL embedded in existing certs).
2. Install AD CS, choose “Certification Authority” only, but do not proceed past the role-wizard “Private Key” page—just cancel. This lays down the service and folder structure without creating a brand-new CA.
3. Stop the CertSvc service:

Stop-Service certsvc

4.Copy in the backup:

• Certsrv\CertEnroll\ → %SystemRoot%\System32\Certsrv\CertEnroll
• Certsrv\CertLog\ (or wherever the .edb lives) → same path on the new VM
• Restore the registry hive you exported (regedit /s backup.reg).

5.Import the CA private key and certificate:

certutil -installcert <full-path-to-CAcert.crt>
certutil -restorekey <folder-with-pfx>

6.Tell AD CS where the database is (if it isn’t already in the default folder):

certutil -setreg CA\DBDirectory "C:\Windows\System32\CertLog"

7. Start CertSvc and verify:

Start-Service certsvc
certutil -crl          # publishes a fresh CRL
certutil -getconfig    # should display "<CAComputerName>\<CAName>"
pkiview.msc            # green across the board = success

If this works, you have a fully resurrected CA, CRL and all.
Now migrate it to a production box using the supported Microsoft procedure (backup, move, restore) and keep the computer name or add a CNAME that matches the old name so renewal traffic still finds it.

3. If the database really is unrecoverable 😬

You have two realistic choices:

A. Retire the old CA gracefully and build a new hierarchy

1. Publish one last CRL with a very distant NextUpdate (e.g., +10 years):

certutil -crl
# then edit the CRL validity with certutil -setreg CA\CRLPeriod "Years" etc.

1. Distribute that CRL to every CDP URL so that existing certs continue to validate (they do not need the database—only the CRL).
2. Stand up a brand-new root/issuing CA pair, push the new root cert via GPO, and re-enroll all templates from the new issuing CA.
3. Adjust Autoenrollment GPO so clients stop asking the dead CA for renewals.

Downside: every existing certificate must be replaced before it naturally expires.

B. Replace the CA but reuse the exact CA key and name

If you still have the CA private key but no DB:

1. Build a new server, install AD CS, choose “Use existing private key > Import.”
2. Because the serial-number counter is lost, you must publish a Base CRL that covers all certs you think you may need to revoke going forward (or accept that you cannot revoke prior certs).
3. This keeps the trust chain intact, so most clients won’t care that serial numbers start over at “01”.

4. Common questions

“What about the root certificate of the current one?”
Keep it. As long as you restore/migrate using the same CA cert (same public key, same subject and serial), the trust chain is unchanged.

“How do I point renewal requests to the new server?”
Clients look at the CA configuration string embedded in their existing certificate template (e.g., oldCA\Contoso-IssuingCA).
• If you keep the machine name or add a DNS alias with that old name, no change is needed.
• Otherwise use a CNAME in DNS (oldCA.contoso.local -> newca.contoso.local) and make sure DCOM port 135 plus the dynamic RPC range is allowed.

“Can the revocation DB just be imported?”
Yes—if you have the edb + *.log files. That’s exactly what the “clean restore” above does.

“What happens to currently issued certs if I build a brand-new CA?”
Nothing breaks immediately, but those certs chain to the old root; you’ll be running two parallel chains until every old cert is replaced or expires. Plan a phased re-enrollment.

5. Quick decision tree

Have CA private key? ────┐
                        │
                        ├─ No → Stand up a new CA hierarchy; de-trust the old root when safe.
                        │
Have edb/logs? ────┐    │
                   │    │
                   ├─ Yes → Offline restore, republish CRL, then migrate cleanly (best).
                   │
                   └─ No  → Import key, publish ultra-long CRL, accept no past revocations
                               OR retire old root and build new hierarchy.

TL;DR

Try the offline restore first. It almost always works if you still possess the CA keys and the CertSrv folder you mentioned. Once the CA service starts and you can publish a CRL, finish the migration properly or decommission it on your own terms—not because the revocation database vanished.