Summary
When a CA server is uninstalled or crashes beyond recovery some objects are left in Active Directory. It’s good practice to remove these obsolete objects.
Background
When you install a version of Certificate Authority that is Active Directory-integrated (i.e. Enterprise Root or Enterprise Subordinate) the following 6 objects are created/modified in the Active Directory database:
Name: <CA Common Name>
Type: certificateAuthority
LDAP Path: CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com
Used for: Contains CA certificates that clients can fetch when validating a certificates chain. Certificates can point to this location via the Authority Information Access (AIA) certificate extension.
Name: <CA Common Name>
Type: crlDistributionPoint
LDAP Path: CN=<CAServerName>,CN=CDP,CN=Public Key Service,CN=Services,CN=Configuration,DC=example,DC=com
Used for: Contains CRLs (base and delta) that CAs has published in the AD. Certificates can point to this location via the CRL Distribution Point (CDP) certificate extension.
Name: <Root CA Common Name>
Type: certificationAuthority
LDAP Path: CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com
Used for: Root CA certificates placed here are automatically trusted by all domain members. An AD-integrated CA places their certificate here during installation. You can import other Root CA certificates here manually.
Name: <CA Common Name>
Type: pKIEnrollmentService
LDAP Path: CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com
Used for: Contains CA certificates from CAs that can issue certificates in the AD.
Name: <CA Common Name>
Type: msPKI-PrivateKeyRecoveryAgent
LDAP Path: CN=KRA,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com
Used for: Contains the certificates for any key recovery agents. Key recovery agents must be manually configured on the CA.
Name: NtAuthCertificates
Type: certificationAuthority
LDAP Path: CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com
Used for: Contains CA certificates from CAs whos smart card and domain controller certificates are trusted for Windows logon. AD-integrated CAs are added here automatically duing installation.
Note! This object is created by the first AD-integrated CA, but subsequent CAs modifies this object instead of creating new uniqe objects. More information on this later in this article.
When you later uninstall the CA role from the server only one AD object is actually removed, the pKIEnrollmentService object. When that object is removed clients will no longer try to enroll certificates from that CA. The other PKI-related objects are left intact, because any issued non-revoked certificates will have problems if they do not exist.
If you are sure that all issued certificated from that CA server are either expired or revoked you can/should remove these CA-related objects from AD.
Steps
Important note: Make sure that you do not delete any objects related to other PKI installations than the CA you are about to clean up!
Start Active Directory Sites and Services
Note! You can also do some of these steps with Manage AD Containers in the Enterprise PKI snap-in , but there are some issues there (KRA entrys aren’t shown), so I’d stick to Active Directory Sites and Services.
If you don’t see the Services node, make sure Show Services Node is checked:
Expand Services/Public Key Services/AIA, right-click the object in the right pane matching the CA server in question and click Delete, confirm with Yes:
Select the container CDP, right-click the container in the right pane matching the CA server in question and click Delete, confirm with Yes twice:
Select the container Certification Authorities. Make sure you should delete this object. If you are removing information about a Subordinate CA this object is likly your Root CA and there might be other dependencies to this certificate. If you are removing information about a Enterprise Root CA you can delete it. To do that, right-click the object in the right pane matching the CA server in question and click Delete, confirm with Yes:
Select the container KRA, right-click the object in the right pane matching the CA server in question and click Delete, confirm with Yes:
Select the container Enrollment Services, make sure that the CA role uninstallation wizard removed the object here. If the CA server for any reason never was correctly uninstalled you must also manually remove the pKIEnrollmentService object. To do so, right-click the object in the right pane matching the CA server in question and click Delete, confirm with Yes:
Now we have to delete the CA-server from the NtAuthCertificates object. This is however a bit different, since this is not a separate object, but rather a value in an existing AD object.
To delete information about the CA-server from the NtAuthCertificates object, run the following certutil command (you must run this as Enterprise Admin):
certutil -viewdelstore “ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=tomdemo,DC=se?cACertificate?base?objectclass=certificationAuthority”
Change the highlighted Forest Root information according to your environment first.
You will be prompted with a list of certificates in the NtAuthCertificates object:
Make sure you have selected the correct CA certificate (the screenshot only shows one certificate, you might see one or more) and then click OK. Choosing Cancel aborts any deletion attempts.
There you go, all information about the CA has been removed from the Active Directory. You are now ready to implement a new, fresh PKI-solution!
Microsoft Security Solutions 
THANK YOU!!! Had to rebuild my PKI deployment and was beating my head against the wall trying to figure out where the old certs were coming from.
Glad it helped!
+1
you’re the best
Hello ,
We have only one CA ( Ent. Root CA) issuing all certs.I have setup a new Ent. subordinate CA , and when I requested computer cert from a member server , the request was going to Sub CA instead of Root CA..
When i disable computer template on the subordinate CA , and submit new request from member server , the request is failing saying template is not published on sub CA …BUT the template is published on Root CA.
How do we tell domain member servers to request cert from Root CA , when template is not available on Sub CA.
I was planning to set the registry flag to enable SAN certs on subordinate CA , and disable standard templates and configure computer template to require CA approval.. but with the above behavior that may break the auto enroll process for computer and user certs , as member servers are requesting certs from Sub CA instead of Root CA
Is the above behavior expected ? Any suggestions ?
Hello,
It is VERY unusual to have both a Root CA and an Issuing CA online and both giving out leaf certificates. Any reason for doing it this way? The most common PKI setup is to have one offline Root CA that ONLY signs SubCA certificate requests from one or more online Issuing CAs. There are of course even more complex PKI setups as well.
That being said, when a client wants to autoenroll it looks in AD to see which templates they have permission to autoenroll from. Then they look in the “Enrollment Services” container in AD to see which CAs actually publish those templates. If more than one CA publish the same template they chose only one of the CAs, they never enroll a certifikate from a template they already have a valid certifivate from. So the fact that the computer cert was coming from the SubCA was probably random, it could also have come from the RootCA.
If you manually enroll a certificate via MMC you should be able to choose which of the CA-servers (that are publishing the template in question) you want to enroll from.
Did you delete the old computer certificate, revoke it on the CA or try to re-enroll from the existing certificate?
I would NOT recommend modifying the CA server to enable the flag EDITF_ATTRIBUTESUBJECTALTNAME2. This can be abused, see this blog post:
https://blog.css-security.com/blog/hidden-dangers-certificate-subject-alternative-names-sans
The CA can still issue certificates with SAN, by using certificate extensions instead of request attributes. See more detailes here:
https://technet.microsoft.com/en-us/library/ff625722(WS.10).aspx
Tom
I have had an issue with an 2012 server that has a domain migrated from a previous sbs 2011 server. They never uninstalled the CA role before they decommissioned the sbs and drpromo’d to remove from AD. Now the 2012 server and clients are looking for a long gone DC to renew Certs and causing Errors for CertificateServiceClient-AutoEnrollment Event ID 6 and 13.
The old DC is long gone years ago, so can these steps be used to safely remove all the references to the CERT that should have been reomoved properly? If so will it affect AD or the clients in anyway? I have a few windows 10 pcs that no say Certificate expired when they start up.
thanks
Yes, these steps could be used to remove any remains of a no-longer-existing CA server, regardless of if it was installed on a DC, SBS or a dedicated server. Be sure NOT to remove any object related to a any new CA servers though.
The affect it will have on the clients/servers is that they will no longer find references to that server during auto enrollment process and will therefor no longer try (and fail).
Expired certs is natural, since you have not renewed or issued them for a long time. But do they say it with some sort of dialog, or is it just in the event log?
Feel free to share your results here 🙂
Thanks for this – I replaced an old SBS server with a plain old DC and Exchange setup – but that SBS had been an unused CA, and although I removed that before demoting and removing it, the other DCs were creating warnings constantly trying to re-register their certs.
Glad it helped!
Great article. Helped me a lot in getting rid of those old certificates in the enterprise ca certificate store.
We had an SBS server that was removed (and correctly according to MS intructions), and replaced with 2008 R2 DC and separate Exchange, the only certificate on the new DC is the old SBS certificate, is it ok to remove this and have no AIS PKS on the DC?
Hi David.
It’s hard to be sure without more information. What type of certificate is present on the new DC?
My advice would be to make a backup of the certificate (including the private key), just in case, and then delete it. IF issues occur, just reimport it again.
What do you mean by AIS PKS?
Can you delete all of the entries in the OID container as well? I have some entries in there that go back quite a few years (and this is a new “test” PKI deployment that I want to rebuild). Thanks
The OID container contains many default OIDs, such as Server Authentication, Client Authentication etc. Sure, you should be able to delete them and recreate the default ones with the command certutil -installdefaulttemplates, but I have never done this.
Hi Tom,
Many thanks for this. I have a question relating to the NtAuthCertificates object – if you do certutil -viewstore would you expect to see the certificate you’re looking to remove in the list? Only when I do this, the certificate from our dead CA isn’t listed, equally I’d expect to see a cert relating to our new CA, that’s not displayed either
Many thanks
Martin
Hi Martin!
The Enterprise CA certificate is added to the NtAuthCertificates container in AD during CA install. Domain Controllers then look in that AD container during smart card logon verification. But that certificate is not propagated to the NtAuthCertificates container locally on clients/servers. That certificate will however be propagated to the Intermediate Certification Authorities container on clients.
To view/edit the NtAuthCertificates container in AD, start pkiview.msc, right-click Enterprise PKI, choose Manage AD Containers and select the tab NTAuthCertificates.
Hope that helped!
Hi Tom,
Many thanks for the prompt reply – doing as you suggested only shows the cert for the new CA server so it looks like there’s nothing else to clean up
Thanks once again!
Martin
I followed the procedure outlined in this article. We too had a CA that had long since been decommissioned. All of the issued Certs (Root, Intermediate and machine) are expired. I have not yet installed a new CA. I notice in AD Sites and services that there are 31 objects in the Certificate Templates folder in AD Sites and Services. Is it OK to delete the objects? There is also an object called “NTAuthCertificates” in the root of the Public Key Services folder. Can this object be deleted?
Lastly, am I free to delete all existing Computer, Intermediate and Root Certs that were issued by the old decommissioned CA?
Hi Todd!
I generally do NOT delete objects in the Certificate Templates container. I rather install a new Issuing CA (without loading the default templates), and only publish the Certificate Templates that I know I want to use. Remeber that certificate templates are not stored by CA servers but rather by AD, and each Issuing CA then choose which of them they publish. There is no way to use a certificate template that no Issuing CA is publishing.
By technically you can delete them. A new CA installation will re-add them, or you can add them manually by running “certutil -installdefaulttemplates”.
If you are absolutley sure that there are no more certificates stored in the object called NTAuthCertificates, you could delete it, but if you do not see any certificates by running pkiview.msc, right-clicking Enterprise PKI, choosing Manage AD Containers and select the tab NTAuthCertificates, there is no need to delete the object.
Since the old Root CA certificate has expired, all issuing and leaf certificate will also have expired. So yes, you can delete anything that chains to that expired Root CA.
Tom,
I really want to thank you for your prompt reply!
I have now installed a non-domain joined Root CA and created Root CRL and Cert for my domain. (This Root CA will then be shut down) I will then install a domain joined Sub-Ca, copy the Root Cer and CRL to it, and publish the Root CRL and AIA to Active directory. When the new Sub-CA starts publishing, will it simply overwrite the old certs in my AD?
Thank you in advance!
Hi,
You do not actually need to copy the Root CA cert and CRL files to the Issuing CA server, any domain joined computer will work (including the Issuing CA).
When the Sub-CA is installed it will publish its own certificate and CRL to AD (you need to copy the files to any HTTP locations you configure, this is not automatic).
No certificates in AD will be overwritten, it will only add its own.
Hello ,
We have one Ent. Root CA issuing all certs. I have setup a new Ent. subordinate CA , and when I requested computer/user cert from another server or Domain controller itself , the request is going to Root CA instead of Sub CA.
What could be the issue and how can I rectify it
You need to delete certificate templates on the CA that no longer shall issue certificates based on them:
https://technet.microsoft.com/en-us/library/cc772358(v=ws.11).aspx
Note that this does not delete the template itself, it only deletes the publication of it on that CA. Unpublish is a better word.
Don’t forget to publish them on the new CA.
You guys are the Angels of the IT world; sharing such a valuable knowledge with such details. We say God bless u when someone do something as nice as u have; so God Bless you. Thanks a Million.
Greetings, I’m glad I stumbled across this article in my scouring of the interwebs!
I have the standard 1 offline root CA and two online subCA setup. I need to decommission one of the subCAs since that location is closing. All of the certs issued on custom templates will be decommissioned as well, so I’m not worried about those, but I have workstations with certs issued on the server I need to retire on the Computer (Machine) Template that is fed via domain. I’d like to know, what is the impact to these workstations when I uninstall Certificate Services from the subCA? Is there a graceful way to push them to re-request a domain cert from the remaining subCA? Can I remove the retiring subCA cert entry from ADS&S > Services > Public Key Services > Enrollment Services to force the workstations to re-request?
Hi Jess!
If you remove a CA that has issued certificates that are still valid, it can no longer issue fresh CRLs for these, and they will soon become untrusted (at least on platforms where CRL checks are performed).
The first step is to make sure that the Template is published on the CA server that will remain.
Then you could choose to “Reenroll all certificate holders” for that Template. This means that anyone that has a certificate based on this template will re-enroll for a new one at the next check-in. But this also means that those who enrolled from this template on the remaining CA will renew as well. And some computers might not be on-prem to enroll, but still needs the current certificate to be valid.
To manage this you can issue a CRL on the CA that will be removed, with a validity that is longer than any issued certificates from it. This way the certificates from the old CA will be valid until they expire (but you won’t be unable to revoke any certificates). Make sure that the CRL is still available at the old CDP (might need to reconfigure DNS, depending on where you store it today).
Alos, be sure to backup the old CA (including keys) before you remove it, you never know if you might need to restore it for some reason.
I hope this answers your question?
Hi Jess,
we have installed a new PKI in our AD domain. I think we have replaced all relevant certificates off the old PKI with those from the new PKI. Since there are thousands off old certificates and not only Microsoft-devices I want to be sure what will happen, when I remove the old CA i.e. if I forgot any device.
Is there a possibility to simulate the removal of the old PKI?
Thanks in advance
Bernd
I had a customer ask me the following:
In AD Sites & Services they have an orphaned Domain Controller that is long gone that used to be a CA (Not sure what type)
They asked if it was ok to delete the orphaned DC and if it would not have any impact on any certificates that it had issued?
My first thought is no, but I can’t seem to find anything to validate this. Does anyone have any thoughts or know the definite answer?
Hi tom,
how to remove one certificate in the domain?
i have one domain, and i installed radius server, but i install roll AD CS, an generate the certificate, how to remove only one certificate from the domain (pcs, servers etc)
could you help me ?
thanks regards
Hi Omar!
I need more information to be able to help. I do not understand “Remove one certificate from domain”.
What certificate (CA, RAS?), and from where exactly?
Omar,
If you mean invalidating one domain issue cert, you need to that from your issuing ca, then issue a new cert if one is needed. If its removing an old issuing CA cert for your domain, I suggest you follow tom’s article above. Good luck.
Thanks sooo much for this article. Who knew along with the sites and services you had to also remove the certs from the cert store in AD. I cleaned up using the Sites and services but kept on seeing two trusted cert server certificates in each pc I joined to the domain I couldn’t figure out why, now I know….thanks so much the article was great!
Really glad it helped 🙂
THANK YOU!!! VERY MUCH APPRECIATED!!
You’re very welcome! Glad it helped.
I accidently deleted the correct / New CA created through the certutil -viewdelstore “ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=mydc,DC=local?cACertificate?base?objectclass=certificationAuthority”
How do i restore the Root CA server certificate back or reinstall it?
Here is a guide on how to add third party certificates to that store, but you can use it for your own certificate:
https://support.microsoft.com/en-us/help/295663/how-to-import-third-party-certification-authority-ca-certificates-into
Hi. Great post and very useful. I have a question though. I have just build a new 2-tier PKI system using an offline non-ddomain joined Root CA and then an online domain joined Sub CA. We still have an existing Enterprise CA in place. This doesn’t seem to be a problem at the moment and I will make steps to remove the old CA soon.
My issue is that the new Sub CA isn’t appearing in the Certification Authorities section of AD Sites and Services. It is appearing in AIA, CDP, Enrollment Services and KRA though. Is this going to cease an issue and should I take an steps to fix it?
Thanks.
Hello, when new computers are added to our local network, they pick up root certificates from a deactivated CA server. These certs were created years ago using SHA1, and they were renewed on a new server using SHA256. Now both show on new computers. Also, items listed in AD sites and services is different from what shows within the PKIView’s AD Containers tabs. Is there a way to block the SHA1 certs from arriving on new PC’s?
I am unaware of any (simple) way of blocking SHA1 Root certificates, but you should investigate how the deprecated cert is still populated to new clients. Trusted Root CA certs are pushed to clients either via the Certification Authorities container or via Group Policies. I wrote a quick-n-dirty PowerShell script to find all PKI-related GPOs, you can find it here: https://mssec.wordpress.com/2017/03/27/quickly-find-all-gpos-with-pki-settings/
Good luck!
Thanks for the information. It’s puzzling because we do not use GPO, and in A.D. Sites and Services, under Certificate Authorities, within Public Key Services, there is only the new certificate referenced.
If you enable Physical certificate stores in the certificate snap-in /View / Ooptions) you might get some more clues where it comes from.
See example here: https://imgur.com/a/jh0h0Tw
Hi,
I have an record in CDP for an old decommissioned AD CA server. We migrated to a new AD CA server some years ago and this CDP object is still in ADSI. Am I safe to delete the old CA record?
It depends. If the old CA issued certificates that are still time valid, they may depend on that CRL to check validity (note that even if the issuing CA is gone, issued certs are still valid). Check the time stamp on the CRL (Next Update). If it’s old it should be ok to remove, if it is still valid maybe you should wait. You can also check the latest Issuing CA cert, if you have that. A CA can never issue certain longer than it’s own validity.
The latest sentence should say “certificates”, not “certain”.
I think Service,CN=Services,CN=Configuration,DC=DC=example,DC=com is wrong and should be
Service,CN=Services,CN=Configuration,DC=example,DC=com, omitting ‘ DC=’
Niels
Ha, you’re right! I wrote this blogpost over 9 years ago, it has 44 comments, but you’re the first to notice. Cred to you 👍
Great article – stood the test of time for sure. Must have helped so many people!
Question for you, I have an enterprise root CA for which the root cert has expired. Internal Certs are no longer used in the domain for anything as far as i can see (and if they were then they would all be broken/expired now!) The physical location where this old enterprise root ca server is located is decommissioning.
I believe I have these options:
1. Just leave it as is. Shutdown the old enterprise root CA server and forget about it. Backup CertSvc registry key and the CA using its backup wizard and archive.
if Ent cert services are ever needed (unlikely) then I would cleanup AD as per your article and install a new root CA.
2. try to renew the root cert on the expired Ent Root CA, if it works then migrate the Ent CA to new location using proper process as documented by MS.
3. uninstall CA and use the process above to clean up.
any advice much appreciated!
Hi!
I would choose option number 3. Having metadata in AD about a CA that is no longer there might cause unneccecary queries and delays in all sorts of situations. It’s like keeping road signs to a place that isn’t there anymore 🙂
Note that uninstalling should remove most of the meta data, while just powering off the CA will not. But I would still verify metadata after uninstallation, just in case.
Good luck!