I was recently working at a client, implementing wireless.  As in many Enterprise Wireless projects, we needed an Enterprise Certificate Authority (CA).  Imagine my surprise, that when we went to create an Enterprise Root CA, that one already existed.  And when we went to take a closer look at that Root CA, when we found that the server was retired - dead and gone, I got that sinking feeling and realized we might be on a trip down the project-over-run rabbit hole.

While you can certainly inventory all the certificates issued and active on a Certificate Authority, if the CA is gone there isn't a good way to do that.  So while you can easily delete a Root CA from Active Directory, once you delete it, that CA is no longer in the list of Trusted Roots.  All the Certificates issued by it will be invalid, and in this case nobody really was sure what that CA was put in to do.  So what we needed was an idea of what the impact of deleting that CA might be.

Then I remembered the story I wrote a while back on Microsoft certutil ( https://isc.sans.edu/diary/11962 ).  With a bit of playing, I was able to use certutil and psexec ( from Mark R's excellent  Sysinternals Utilities) to inventory the "Local Computer" certificate store of every machine in the domain.  

Luckily, in this case we only needed to worry about machines in the Active Directory Domain, so this survey got the job done for us.

What we needed to run was a short script like this, on each machine in the domain:

REM ============== getiss.cmd ==============
echo ========================== >> \\utilserver\sharename\certs.txt
hostname >> \\utilserver\sharename\certs.txt
certutil -store my | find "Issuer" >> \\utilserver\sharename\certs.txt

The first 2 lines (the echo and hostname commands) just break up the output, and identify the machine being evaluated in each test.  The last line is where all the action is - we're dumping the local certificate store, only looking at the Local Machine store.  In this case all we're only interested in is which server issued the certificate, so we're looking for the word "Issuer" in the output.  Since we're looking anyway, I'm not going to parse this out further, I'll happily look at *all* the issuers in the domain to see if we've got any other issuer-based certificate problems in our domain.

Now I'll call this little script for every computer in the domain:

psexec \\* -u domainname\adminuser -p adminuserspassword -cf getiss.cmd

Our output looks like:

==========================
KMS
Issuer: CN=CA01-CA, DC=domain, DC=com
==========================
SERVERNAME2
==========================
BACKUPS
==========================
SERVERNAME5
==========================
SERVERNAME6
==========================
SERVERNAME7
Issuer: CN=SERVERNAME7, L=1720207907, OU=SharePoint, O=Microsoft
Root Certificate: Subject matches Issuer
==========================

... and so on.

So what did we find?  The old CA hadn't issued any certificates that were currently in play on anything in the domain.   We also found a number of self-signed certificates (where the Issuer matched the hostname).  So, with this in hand, we can delete that old CA from the Domain and know in our hearts that we're not going to mess up any of the critical services in the organization (Sharepoint or Exchange for instance).  Details on doing this, now that the impact has been assessed, can be found at these and many other links on microsoft.com ( http://support.microsoft.com/kb/555151  , http://support.microsoft.com/kb/889250 ,  http://blogs.technet.com/b/pki/archive/2011/10/07/how-to-decommission-a-windows-enterprise-certification-authority-and-how-to-remove-all-related-objects.aspx )

Scripting saves the day again, in about 10 minutes no less !

If you've had a similar experience, or if you've got a simpler or more elegant scripting approach for this type of problem, by all means use our comment form and share.

===============
Rob VandenBrink
Metafore