Enterprise CA Root died

We have an small internal Domain with our root Enterprise Server. A month ago the Enterprise CA died without a backup. I have another Enterprise Subordinate CA that was associated with the root CA. To add to the problem, the Subordinate CA service is refusing to start and giving out the following error: "The revocation function was unable to check revocation because the revocation server was offline. 0x80090213 (-2146885613)." Obviously due to the Root CA not being online.

I have prepared a new server with the same name as the root CA.

What options do I have so I can get the Certifactes up and running and in the same time trusting all the certificates that were previously distributed?
Who is Participating?
PberConnect With a Mentor Solutions ArchitectCommented:

You can try PKIview from the reskit and see if you can see where the CRL is pointing, but you may be out of luck.

It is of upmost importance that you have a backup of your Root CA.  Without going to backups you will not be able to recover just by using the same name as the old root CA.  Depending what you are doing with the certicates, they should be still valid until they expire as long as your computers have your CA as a trusted root.  This may give you time to rebuild your CA infrastructure.
Normally the design of choice is an offline Standard root CA that never, ever touches the network.  The reason for this is if your subordinate CA or a certificate ever becomes compromized, you can always revoke the certificates to make them invalid (required exporting and importing the CRL).  You can't do this if it happened to the actual Root CA.
 If at some time you did perform CA Backup, you may be able to do this.  Good to know for the future:
This is a good backup document:
 This is also a bit of a read, but it goes into CA best practice and the offline root CA thing:
ParanormasticConnect With a Mentor Cryptographic EngineerCommented:
how badly did the old CA fail?  are you able to boot to it and it has errors, or is the hard drive failed with no backup?

Just having a similarily named CA is not enough - you would need to have the root CA's private key and CA database in order to recover.  Since it sounds like you do not have this, then you can name the new root the same or whatever you would like.  The existing subordinate is going to have its CA certificate re-signed as well, which will mess with all of the certs that it has issued.

Since you are going through this anyways, I generally recommend using virtual machines and storing at least the root image on a removable hard drive for when it is powered down and easily locked up.  Backups of the image are easily done and will be hardware independent for future recoveries.  Can save an extra snapshot of the subordinate onto it as well, although obviously the sub would run from a different hard drive for production.  You can use the VM internal netwrok as long as you keep it unroutable to transfer the CRLs via script from the root to the sub CA.

Since the existing root CRL is already expired, you will need to decommission your existing PKI from AD.  If you had the luxury of planning a decommission you could issue an extended CRL, but this can't be done.  If you had access to the old root's private key you could re-sign the old CRL to extend the validity period.

Yes - this means you will need to re-issue all of the certificates.  You should export the CA database to .csv file (export from the Issued Certs folder in the CA MMC) - note that if it appears to time out that you may have an incomplete list - you may need to do this multiple times by filtering by certificate issuance date is < and > selected dates until you have the entire thing - the first export should give you a rough idea how long of a timeframe.  If you have less than a couple thousand certs issued (keeping in mind autoenrolled workstation certs, if users have multiple certs each, etc.) then you may get lucky and get it all the first shot.  This way you can make sure that everything is covered afterwards and prioritize (e.g. web server certs first).

How to decom a CA server properly from AD:

Let me know if there is anything you are unclear about.

After you install the new CA - go into the CA MMC and use the Backup CA option to backup the CA database and private key and lock these up somewhere - if you had this before you would be in a much nicer place right now with as much time as you needed to recover.
ParanormasticCryptographic EngineerCommented:
Also, when you do the new root CA - keep the root offline - don't join to the network or domain, its okay to install as a stand-alone CA (enterprise CA requires being on domain) - you can still have your sub CA online, connected to domain, and set up as enterprise.
ParanormasticCryptographic EngineerCommented:
Although tough to see next to the bold text, pber's "Without going to backups you will not be able to recover just by using the same name as the old root CA." is the main answer - that part probably should have been bolded or stated upfront, but regardless it was present.  He popped that out first, so he should get the Accept credit.

pber had some decent planning articles to point to, I talked more about the need to decom the old and the impact of the results, as well as some planning considerations along with a hopeful question about why the old CA died out so that maybe that could have been recovered although not expecting much to that end.  For that, I would aim for an assist.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.