Update 26.03.2020: Updated conditions for Renew Manually Enrolled Certificates section

This is a second part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:

• Certificate Autoenrollment in Windows Server 2016 (part 1)

Certificate Autoenrollment Architecture

This section discusses the autoenrollment architecture, an analysis of the components of the autoenrollment process, and working with certificate authority interfaces.

Autoenrollment internal components

Autoenrollment consist of several components installed on each computer. Depending on environment (Active Directory or workgroup) some components may present or not present. The following diagram outlines autoenrollment components and their high-level interactions in both environments:

Figure 8: Autoenrollment component diagram. Blue color shows components available only in Active Directory environment

The meaning of each component is provided in next sections.

Group Policy client

This component is not available in workgroup environments.

Client module that is responsible for Group Policy retrieval and processing from domain controller, policy storage and policy maintenance on a local computer. Group Policy client updates local configuration with certificate enrollment policy (CEP) information.

Local configuration

System Registry storage that contains information about certificate enrollment policies (CEP). This information is then used to populate configuration for: Enrollment Policies, AE Options and Certificate Issuers components. Local configuration is stored in System Registry in HKLM and HKCU registry hives:

SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment\

Enrollment Policies

Contains a collection of CEPs. In Active Directory environment, a LDAP domain policy is added by default. XCEP policies must be configured by an administrator in Group Policy on domain controllers (available only in Active Directory) and/or using local configuration tools. Each policy contains the following notable properties:

• Enrollment stack. Can be either, WCCE or XCEP;
• URI. An URI to a policy server. If URI begins with LDAP:// prefix, Enrollment Stack is set to WCCE and CEP server is set to domain controller. If URI begins with HTTPS:// prefix, Enrollment Stack is set to XCEP and URI points to XCEP server.
• PolicyId. Allows the grouping of policy server end points that serve the same CEP together. It is also used to record which CEP contained a certificate template on which a particular certificate was based;
• Authentication method. Kerberos authentication is available only in Active Directory environment;
• IsDefault. Boolean flag used to identify default CEP. A default CEP is used to renew certificates for which the original PolicyId is unknown;
• Cost. Is used during CEP sorting;
• Templates. A list of certificate templates available to client for enrollment.

AE Options

Specifies options that control autoenrollment behavior. These options contain the following flags:

• Enabled — specifies the status of the autoenrollment feature. The value 1 enables autoenrollment feature, value 0 disables autoenrollment feature;
• Enroll — enroll and renew certificates based on certificate templates that have been set up for autoenrollment;
• Manage — renew certificates when the certificate templates are not set up for autoenrollment;
• RetrievePending — retrieve pending requests.

Certificate template is set up for autoenrollment when its settings are compatible with silent initial enrollment and renewal operations. Certificate is not set up for autoenrollment when its settings are not compatible with initial certificate enrollment, but allow silent certificate renewal operation.

Enroll setting is controlled by a “Update certificates that use certificate templates” checkbox in autoenrollment configuration dialog in GPO (see Configuring autoenrollment policy section below)

Manage and RetrievePending settings are controlled by a “Renew expired certificates, update pending certificates, and remove revoked certificates” checkbox in autoenrollment configuration dialog in GPO (see Configuring autoenrollment policy section below).

Local Certificate Storage

Autoenrollment requires the computer on which it is executing to provide some implementation-specific persisted local certificate storage that can be logically organized into groups of certificates.

Local Private Key Storage

Autoenrollment requires that the computer on which it is executing provide some implementation-specific persisted local private key storage where it could store private keys associated with the certificates it is requesting.

Certificates

• Cert.ToBeAdded: a list of certificates to be added to the local certificate storage after renewing existing and enrolling new certificates.
• Cert.ToBeDeleted: a list of certificates to be deleted when existing certificate gets successfully renewed.
• Cert.CurrentCertificates: a list of the current end entity certificates.
• Cert.Roots: a list of certificates that holds certificates from the Trusted Root CAs store.
• Cert.CAs: a list of certificates that holds certificates from the Intermediate CAs store.
• Cert.KRA: a list of certificates that holds CA certificates which are allowed to perform client private key archival in CA database. KRA feature is used only when certificate template requires private key archival in CA database. Private key material is transferred to CA in a secure way. Transfer security is accomplished by encrypting the key with CA Exchange certificate provided by a CA server. More details on key archival: Active Directory Certificate Services Longhorn Beta3 Key Archival and Recovery.

Balloon User Interface

For each request that requires user interaction as per the certificate template, the balloon user interface (UI) is invoked in system tray and is added in the notification center:

Figure 9: Certificate enrollment balloon user interface that requires user input

Balloon UI notification is displayed approximately 60 seconds after logon. If no user interaction is explicitly defined on the certificate template, no UI will be displayed to the user. This delay is incorporated to allow for speedy application and shell response times during the logon and booting of the client machine. If the 60-second delay is not desired, the following registry key may be added on a per-user basis:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEExpress

Using this key in a normal production environment is not recommended. If it is used, it must be created on a per-user basis.

Machine certificates do not support user interaction and must not be configured to require this setting.

The balloon UI waits for the user to see the balloon and is activated by a mouse click. Note that after approximately 15 seconds, the balloon pop-up window is replaced in the system tray by a certificate icon that may be activated by a mouse click. If no activation occurs within seven hours, the taskbar icon will disappear and the silent thread will re-activate at the next logon, machine reboot, or next autoenrollment trigger, whichever is first. Once the user activates the UI, the REQUEST store is checked first for pending requests.

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:

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):

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}:

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.

Initialize enrollment policies

During this step, autoenrollment uses local configuration to obtain information about CEP policies. Autoenrollment groups policies by PolicyId attribute. Groups are sorted by Cost attribute, then by Authentication attribute. Kerberos authentication has higher precedence. The rest groups are placed in arbitrary order.

After grouping and sorting CEPs, each CEP is queried. During the query, client obtains the following information:

• List of certificate templates available to client and their settings;
• List of certificate issuers supported by this CEP with a list of supported certificate templates by each issuer.

If CEP uses WCCE enrollment stack, then certificate templates and certificate issuers are downloaded from Active Directory, otherwise, this information is downloaded from XCEP server. Upon retrieval, every certificate issuer certificate is validated according to validation rules specified in RFC 5280. Certificate issuers that fail validation are excluded from processing.

After downloading certificate templates and certificate issuers, autoenrollment constructs a list of certificate templates applicable for autoenrollment. At a minimum, certificate template is considered applicable for autoenrollment when client has Autoenroll permissions on that template, and template is supported by any of certificate issuers in the current CEP group. Additional restrictions apply and will be covered in “Autoenroll based on certificate templates” section below.

Retrieve pending requests

If autoenrollment options has RetrivePending flag enabled, autoenrollment checks Certificate Enrollment Requests (REQUEST) local store for non-complete certificate requests. Pending requests are requests that require explicit CA manager approval. When client submits such request, it is placed in CA database and waiting for review and approval. CA manager can approve the request and issue the certificate, or cancel request.

For each pending request, autoenrollment checks the age of the request. If request is in pending state for 60 or more days, pending request is deleted from Certificate Enrollment Requests and excluded from further processing.

When stale pending requests are deleted, remaining pending requests are updated. Each pending request contains all relevant information to update request status. Autoenrollment contacts certificate issuer associated with the particular request and updates the request status. There are three possible outcomes:

1. If status is not changed (still pending) or autoenrollment failed to contact certificate issuer, the request entry is skipped;
2. If certificate was issued by certificate issuer, autoenrollment downloads issued certificate, links private key to it and moves completed request to Personal certificate store. Request entry is completed and removed from Certificate Enrollment Requests store.
   
   If request is renewal request (not initial) and certificate template requires to delete the renewal certificate, it is deleted from Personal store, otherwise, renewal certificate is marked as “archived”. Archived certificates are not added in the default certificate store view, but they still can be queried when asked by client application.
3. If CA manager declined the request, or CA failed to issue the certificate, error status is returned. Although the certificate was not issued, request is considered completed and removed from Certificate Enrollment Requests store.

When all pending requests are processed, autoenrollment performs existing certificates renewal.

Autoenroll based on certificate templates

If autoenrollment options has enabled Enroll flag, autoenrollment will perform a two-step Personal certificate store update. First step renews existing certificates (if applicable) and second step enrolls for certificates which don’t exist in certificate store, but are required by enrollment policy. These two steps are performed against certificate templates that have been set up for autoenrollment (support silent initial enrollment). Certificate autoenrollment consists of three steps:

1. Certificate renewal against certificate templates that are configured for autoenrollment;
2. New certificate requests against certificate templates that are configured for autoenrollment;
3. Certificate renewal against certificate templates that are not configured for autoenrollment.

Each step is described in the following sections

Automatic certificate renewal

In the first step, autoenrollment enumerates all existing certificates (from Personal and additional stores provided in the configuration) that use certificate templates and checks its validity by passing it to a certificate chaining engine. Certificate is validated according to validation rules as specified in in RFC 5280. If certificate fails validation checks, it cannot be renewed. Instead, a new certificate request is issued as described in next section. If existing certificate passes validation checks, autoenrollment examines whether certificate template is set up for autoenrollment. Certificate template is set up for autoenrollment if none of the following conditions are true:

• Client does not have Autoenroll permissions on certificate template;
• Certificate template is available to client, but it is not supported by any available certificate issuer;
• Certificate template requires private key archival in CA database and CA (that supports this template) certificate is not presented in the Certs.KRA local store or fails validation check;
• Certificate template requires multiple (2 or more) registration authority (RA) signatures in the Issuance Requirements tab. When this condition is true, the certificate is not renewed, instead a new certificate request procedure is initiated as described in the next section;
• Certificate template requires subject name to be supplied with request in the Subject Name tab;
• User interaction is required for machine certificate templates in the Request Handling tab;
• Certificate template is superseded by another template in the Superseded Templates tab.

If any of these conditions are true, existing certificate cannot be renewed, and autoenrollment will skip such certificate. Otherwise, autoenrollment checks passes the certificate to certificate chaining engine (CCE) to determine its validity.

Autoenrollment will ignore revocation errors if a CRL Distribution Point (CDP) extension does not exist in the CA certificate or if the revocation status is offline.

If certificate is valid according to chain validation rules (as described in RFC 5280) autoenrollment estimated validity of the existing certificate:

• 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.

If existing certificate’s validity meets renewal threshold, autoenrollment will submit renewal request to CA server.

If certificate lifetime hasn’t reached renewal threshold, autoenrollment checks certificate template Major Version attribute in existing certificate and certificate template obtained from XCEP server. If Major Version of certificate template is higher than Major Version in existing certificate, this will instruct autoenrollment to perform existing certificate renewal even if renewal threshold is not yet reached. Major Version attribute manipulation allows systems administrators to force existing certificate renewal when critical changes were made in certificate template settings.

Submitting a new request

After renewing existing certificates based on templates, autoenrollment examines a list of certificate templates that have been set up for autoenrollment (as described in previous section) and attempts to find a matching certificate in the Personal store. New request is not issued against certificate template if any of the following conditions are true:

• Valid and non-expired certificate is found;
• Certificate template is configured to check Active Directory for an existing certificate and valid and non-expired certificate is found in userCertificate Active Directory attribute of the current client account;
• RA signature count in certificate template’s Issuance Requirements tab is set to 2 or greater value;
• RA signature count in certificate template’s Issuance Requirements tab is set to 1 and no matching certificate to co-sign the request is found in Personal certificate store.

If no valid certificate is found, or certificate chaining engine failed to validate existing certificate, a new certificate request is issued.

When new certificate request is created, autoenrollment checks if CA servers provided by a default CEP policy supports specified certificate template. If at least one CA supports specified certificate template, a request will be sent to CA server with lower Cost value. If no CAs in the default CEP policy are found, autoenrollment arbitrary enumerates all available CAs that support specified certificate template. If at least one CA is found, a first (arbitrary selected) CA is used to submit certificate request. If no CAs that support specified certificate templates are found, certificate template is skipped.

Renew manually enrolled certificates

Some certificates require manual initial enrollment, but later can be automatically renewed. If autoenrollment options has Manage flag enabled, autoenrollment will examine current certificates in Certs.CurrentCertificates store to determine if any such certificates exist and attempt to renew them. Manually enrolled certificate renewal if none of the following conditions are true:

• Certificate has not passed 80% of its validity or the renewal interval period specified on the template has not been reached;
• Existing valid and non-expired certificate based on this certificate template is found;
• Requester doesn't have "Autoenroll" permissions on certificate template;
• Certificate template requires private key archival in CA database and CA (that supports this template) certificate is not presented in the Certs.KRA local store or fails validation check;
• Certificate issuer endpoint that supports certificate template is configured in “Renewal Only” mode. This configuration is possible only when using WSTEP enrollment stack;
• Certificate template requires subject name to be supplied in the request subject information from existing certificate retrieval is not allowed in the Subject Name tab;
• User interaction is required for machine certificate templates in the Request Handling tab;
• Certificate templates requires multiple RA (2 or more) signatures in the Issuance Requirements tab and no suitable RA signing certificate is found in Personal store.

Clients prior to Windows 8 and Windows Server 2012 do not support the use of existing name in the renewal certificate and autoenrollment against the template that requires the subject to be supplied in the request will fail.

If neither of these blocking conditions met, autoenrollment submits certificate request. If initial enrollment results in an issued certificate, it is installed in the Personal store. If request results in a pending state, client keeps request information in the Certificate Enrollment Requests store and will check its status upon next autoenrollment trigger.

Certificate store cleanup

This section describes the certificate store cleanup process after each successful certificate renewal or new certificate enrollment.

If certificate renewal for existing certificate occurred and resulted in an issued certificate, autoenrollment performs existing certificate cleanup in local storage. Cleanup will either, mark existing certificate as “archived” or delete it. Cleanup action is configured in the certificate template’s Request Handling tab. The following image illustrates cleanup setting:

Figure 12: Certificate cleanup setting in certificate template

If autoenrollment options has Manage flag enabled, autoenrollment deletes revoked certificates in the userCertificate attribute on the client object in Active Directory. Expired or superseded certificates are not deleted automatically from Active Directory, they must be deleted manually.

If certificate purpose is Encryption, existing certificate is always marked as “archived” and cannot be deleted by autoenrollment.