Why when I deploy my roots and intermediate CA Certificates to AD do some servers automatically download them and others do not?

Question

I am very confused by the process of publishing Root and Intermediate certificates to AD and how they deploy to servers across an enterprise. When I publish the Root and Intermediate CA certs to the AIA and Certification Authorities Containers in AD, some servers will pull the new certificates into their trust stores and others will not.

When looking for any documentation around this process, I cannot find much. Does anyone out there know the process from beginning to end? Also, does anyone have an idea of why some would pull the certs from AD and others would not?

Thank you to anyone who can shed light on these dark times.

Answer 1

Hello @Chamby112 ,

You are welcome. Thank you so much for your kindly reply.

If the root CA is an offline root CA (standalone root CA), we should publish the root certificate into AD using the above command. This will then distribute the certificate to the trusted root store of all domain joined clients. If the root CA is joined to the domain, this will eventually happen automatically, but it can take up to 8 hours (default GPO application time).

No GPO is configured to distribute the root certificate. If we manually deleted the root CA certificate from the local computer store, it would not come back if we updated policies using gpupdate /force or ran certutil -pulse.

There is a registry key that caches downloaded root CA certificate requests using auto enrollment.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache

To manually force a new download, delete the following registry key and all subordinate keys. It will cause the client to redownload the CA objects from the DC during the next GPO refresh.

In my test, I deleted the subordinate key and then ran certutil -pulse or gpupdate /force, the deleted Root CA certificate came back.

For more information, we could refer to:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb456981(v=technet.10)?redirectedfrom=MSDN#ECAA

https://social.technet.microsoft.com/Forums/Lync/en-US/dc4891be-e3ea-4321-972f-e66eee6ed1d1/how-does-a-root-ca-certificate-get-distributed-to-domain-clients?forum=winserversecurity

https://social.technet.microsoft.com/Forums/en-US/0026788d-34fe-4647-8e3b-ce5db9ba9a57/root-ca-certificate-not-being-readded-after-it-is-deleted?forum=winserversecurity

Hope the information is helpful. Thank you so much for your support.

Best regards,
Hannah Xiong

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Hi

You can follow the link below:

public-key-infrastructure-part-3-implement-pki-active-directory-certificate-services

Please don't forget to mark this reply as answer if it help you to fix your issue

Answer 3

Hi,

If you have installed enterprise PKI , all member machines will detect the certificate automatically when you restart it or run the following command manually:

certutil -pulse

If the client is unable to detect the root certification automatically, I think it may be network flow issue.

Please don't forget to mark this reply as answer if it help to fix your issue

Answer 4

This is where I'm getting to. This is not occurring on all of our systems. The large majority are, but I am seeing some that are not. I am trying to narrow down why they may not be updating on some. Are there instances others have seen where this is an issue? I.e. something disabled on the system, some GPO blocking this, etc.

I am trying to understand the whole process so I can try and isolate it to something specific, but I cannot find a detailed description of the process end-to-end.

Answer 5

Try one of the following actions:

• Check network flow
• Restart impacted servers and launch the following command certutil -pulse
• Rejoin impacted server to domain

Please don't forget to mark this reply as answer if it help to fix your issue