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,

Thank you so much for posting here.

During the process of Root CA configuration, it is necessary to publish the CRL and the Root CA certificate to Active Directory. We could use the below commands to publish Root CA CRL and AIA to Active Directory.

Publish CRL: certutil -dspublish -f <CRLFile> <CAName>

Publish CA certificate: certutil -dspublish -f <CACertificateName>

In my environment, the certificate is already in DS store. So the output is shown as below.

If the certificate is published to the DS store, the domain-joined servers will automatically get the certificate. We could kindly have a check whether it is published to DS store.

For any question, please feel free to contact us.

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,

Thank you all for your help on tracking down this information. I was able to find my answer under the following link: https://www.sysadmins.lv/blog-en/certificate-autoenrollment-in-windows-server-2016-part-2.aspx

"The Autoenrollment Process
This section describes a detailed process performed by autoenrollment each time it is activated.

Autoenrollment timing
The autoenrollment process is normally triggered by a set of built-in scheduled tasks which are stored under Task Scheduler Library\Microsoft\Windows\CertificateServicesClient container in Task Scheduler:

Autoenrollment triggers in Task Scheduler

Figure 10: Autoenrollment triggers in Task Scheduler

This container stores several scheduled tasks that can activate autoenrollment for machines and users. By default, autoenrollment is triggered at reboot for machines, or at logon for users, and is refreshed every eight hours. The refresh interval can be configured using Group Policy. Autoenrollment is also triggered by an internal timer that activates every eight hours after the last time autoenrollment was activated. Autoenrollment trigger for computer and user contexts can be activated manually, by running the following commands:

Certutil -pulse
Certuil -user -pulse
Unlocking the workstation does not trigger autoenrollment.

Forcing re-enrollment
An administrator may force all users to re-enroll for a given template by updating the major version number of the template. When Active Directory is queried during logon for required certificate templates, the version number is examined. If the version number has incremented, the certificate template is considered to be updated and the user must re-enroll for that template.

To manually force the template version to be updated (thereby forcing re-enrollment): right-click the template and select Reenroll All Certificate Holders (Figure 11):

Manually Forcing Certificate Re-Enrollment

Figure 11: Manually Forcing Certificate Re-Enrollment

This procedure will increase template’s Major Version attribute. Autoenrollment client will handle this attribute to force existing certificate renewal when Major Version is changed. When modifying certificate template, its Minor Version is incremented, but it doesn’t force client certificate reenrollment.

Templates are not updated automatically. By default, templates are updated at a minimum interval of 10 minutes.

Renewal intervals
Windows clients will perform automatic renewal of certificates as specified on a per-template basis. Renewal intervals are dictated by the certificate template, which is set to six weeks (before expiration) by default. When certificate renewal is performed, the old (previous) certificate enrollment is always archived on the client machine, and the user directory object is updated. Even if “Delete revoked or expired certificates” checkbox is selected in certificate template settings. In this case, previous certificate will be deleted after expiration or revocation. Important certificate renewal criteria include the following:

Automatic certificate renewal will only occur when 80 percent of the certificate lifetime has passed, or when the renewal interval period specified on the template has been reached whichever timeframe is smaller.
If the renewal period is greater than 20 percent of the certificate lifetime, autoenrollment will not automatically attempt certificate renewal until the 80 percent threshold has been reached.
Autoenrollment task sequence
This section describes the process and operation sequence during autoenrollment initialization. Depending on autoenrollment configuration not all steps are performed. Each subsection provides conditions when particular task is executed.

Initialize autoenrollment options
In this step, autoenrollment feature examines local configuration storage (which is updated via Group Policy and/or manually by a computer administrator) to determine the process behavior. If autoenrollment state is set to Disabled, the process terminates, otherwise it continues with the next step. Autoenrollment initialize Enroll, Manage and RetrievePending flags.

Update certificates and object identifiers from Active Directory
This step is performed only by domain members. Workgroup members skip this step.

Autoenrollment automatically downloads and manages trusted root certificates, cross-certificates, and NTAuth certificates from Active Directory into the local machine registry for domain-joined machines. All users who log on to the machine inherit the trust and downloaded certificates that are downloaded and managed by autoenrollment. The following stores are located under the following DS path: CN=Public Key Services, CN=Services, {ConfigurationNamingContext}:

Local Certificate Storage

Certificates MMC container

Corresponding Active Directory container

Cert.Roots

Trusted Root Certification Authorities

CN=Certification Authorities

Certs.CAs

Intermediate Certification Authorities

CN=AIA

Certs.KRA

N/A

CN=NTAuthCertificates

Additionally, autoenrollment fetches object identifier (OID) registration information and writes it to the local cache. Administrators use Active Directory to register object identifiers for new application policies (enhanced key usages or EKU), certificate policies and certificate templates. OID information is downloaded from the following Active Directory container:

CN=OID, CN=Public Key Services, CN=Services, {ConfigurationNamingContext}
Update local stores
During this step, autoenrollment initializes runtime stores: Cert.CurrentCertificates, Cert.ToBeAdded, Cert.ToBeDeleted. Cert.CurrentCertificates will include all the certificates from client’s Personal store and, optionally, from additional stores if such are configured in local configuration. Other runtime stores are initialized to empty lists."