Well, you're in some kind of a mess, that's for sure. First, you do NOT install a CA on an exchange server, DC or, in fact, any machine that has other roles. That's a receipt for disaster. The proper setup of a CA is that you pick a server to be your root (preferably an offline root CA), and a second server to act as your intermediate CA for other needs.
You do it that way so that, in case something happen to the intermediate CA (like it happened to yours), you can revoke it from your root CA and build a new one without too many issue.
Now, you haven't specified what what type of CA you deployed (standalone of AD-integrated) but, from the problems you describe, I assume it's an AD-integrated one.
Assuming the above is correct, here is your situation: you have a CA that have been used to issue certificates that is now disabled. That CA is used by all your machine for automatic certificate enrollment and you further used these certificate for authentication.
Now, if you have the system setup properly, what you should have done is: revoke the old intermediate CA on the root, publish the new CRL, install another intermediate CA and re-issue the certificates. You might also have to use ADSI edit to re-target the enrollment service LDAP entry.
In your case, you cannot do this this way. You will have to either try to perform a migration of your authority (assuming you still have access to the private key linked to your root CA or can recover it) or start from scratch with a new authority.
If you decide to create a new authority, here is what you should do:
- If you can't use different servers for a root CA and intermediate CA, at least dedicate a machine to be your root. You can also opt to create a root CA using OpenSSL and use that CA to sign an AD-integrated Intermediate CA but be aware that you will have to manually generate new CRLs now and then for that root (you can, however, install that root on the same machine assuming you protect it properly). I would use a new server name to make sure you do not mix the new and old roots (which can cause problems and confusion) but you could reuse the same name if you want.
- Once you have a new CA hierarchy, distribute the new root using group policies to all the machines in your domain. Add the root to the "trusted root certificate authorities" store and the intermediate CA to the "Intermediate Certificate Authority" store (the second step is mostly a precaution).
- Locally force the old CA to be untrusted. For that, use group policies to add the public certificate to the "Untrusted Certificates" store.
- Re-target the enrollment services to your new server. For that, use adsiedit to navigate to Configuration / services / Public Key Services / Enrollment Services and remove the reference to the old CA server (the new one should already have been registered there).
- Re-issue all the certificates that you need. If you've setup the CA properly, any certificate that uses automatic enrollment will be re-generated automatically from the new CA and the old one will be discarded. Unless you're sure that these certificates have NOT been used for encryption, do NOT delete them fro the client machines/accounts.
(P.S. Don't feel too bad about not having set this up properly in the first place: CA management is hard and doing it wrong is extremely easy. MS made it even easier to mess it up by making certificate services so easy and quick to install: you're practically doomed to get it wrong the first time around unless you know exactly what you're doing).
