Forcing Certificate Re‑enrollment via Template Versioning in ADCS

I never had a requirement to use a redeployment of a current certificate template however after testing in a lab it revealed some interesting findings, which through the power of research and learning I thought I’d share this with a blog post.

When a Public Key Infrastructure (PKI) is deployed at scale, administrators can frequently need to replace all certificates issued from a particular template—whether due to updated cryptographic requirements, new issuance policies, disaster scenario's or potential key compromise. In Active Directory Certificate Services (AD CS), this is accomplished by selecting “Reenroll All Certificate Holders” on a certificate template.

Outline : Certificate Template Versioning

Every certificate template in AD CS carries two version fields embedded in the "certifiatetemplate" extension of issued certs:

• Major Version (manually incremented)
• Minor Version (automatic on any property change)

Clients compare the version in their existing certificate against the version published in AD CS (in the Configuration partition). A mismatch in major version signals that a full reenrollment—not a simple renewal—is required.

How do I trigger the "Reenroll All Certificate Holders"?

If you wish to trigger this option then you need to connect to the Certificate Authority then choose Certificates Templates then from this option right click and choose manage:

This will then load all the certificates templates stored in Active Directory, after a few moments the window with the templates will appear as below, find the template, right click and choose the reenroll option: 

If you choose an original template you will not get the option to "enrol" as the template version will be to old and this is not supported on the original templates as you can see below:

What Happens When You Click “Reenroll All Certificate Holders”

When the “Reenroll All Certificate Holders” action is triggered:

1. Major version of the template is incremented by 1.
2. Minor version is reset to 0.

3. The updated template object is written under:
   

   
   CN=Certificate Templates,CN=Public Key Services,CN=Services, CN=Configuration,DC=bear,DC=local
   
   
4. Changes replicate to all domain controllers, making the new version visible to clients.

Required Group Policy Settings

For Windows clients to detect and act on the version change, the following GPO must be configured:

Computer Configuration
 └── Policies
     └── Windows Settings
         └── Security Settings
             └── Public Key Policies
                 └── Certificate Services Client – Auto-Enrollment

• Policy : Enabled
• Renew expired certificates, update pending and remove revoked certificates
• Update certificates that use certificate templates 

Client‑Side Auto‑Enrollment Process Flow

Step 1: Trigger

• At boot, logon, or every ~8 hours (background)
• Or manually via certutil -pulse

Step 2: GPO Processing

• Client downloads Public Key Policies

• Cached under:
  

  
  HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment

Step 3: LDAP Query

• lsass.exe queries the Configuration partition’s Certificate Templates container
• Retrieves template OIDs, versions, ACLs

Step 4: Version Comparison

For each cert in Cert:\LocalMachine\My (or CurrentUser\My):

if ClientCert.Version < ADCS_Templ.Version:
    trigger reenrollment

Major‑version mismatch then this triggers a full reenrollment - exactly what we need in this situation.

Step 5: Key Generation & CSR

1. New key pair per template specs (RSA/ECC, CSP/KSP)
2. CSR signed with new key
3. Submitted to CA via Kerberos (machine or user context)

Step 6: Certificate Issuance

1. CA applies template policy, issues new cert
2. New cert installed locally; old cert remains until expiry or manual revocation

Step 7: Logging

• Check in Event Viewer under:

  Applications and Services Logs
    └── Microsoft
        └── Windows
            └── CertificateServicesClient-AutoEnrollment
  

• Key Event IDs: 6 (start), 13 (request submitted), 64 (issued)

Monitoring and Forcing Enrollment

• Manual trigger:

  # Machine
  certutil -pulse
  # User
  certutil -user -pulse
  

• Inspect certificates via PowerShell:

  Get-ChildItem Cert:\LocalMachine\My |
    Where-Object { $_.Extensions |
      Where-Object { $_.Oid.FriendlyName -eq "Certificate Template Information" } } |
    Select-Object Subject, Thumbprint, NotAfter
  

Specific Considerations for Intune SCEP Deployments

When using Simple Certificate Enrollment Protocol (SCEP) via NDES in Microsoft Intune, certificates are provisioned through a service account and a static SCEP profile. In this context:

1. Static Profile Binding
   
   Intune SCEP profiles reference a specific template name at creation. Devices will not detect a major‑version increment via AD CS alone; the profile remains bound to the original template.

2. No Automatic Version Detection
   
   Unlike native Windows auto enrollment (which checks template versions dynamically), Intune‑managed devices do not query AD for template version changes. Clicking “Reenroll All Certificate Holders” on the template will not trigger new SCEP enrollments

3. Forcing Reenrollment
   
   To ensure devices obtain fresh certificates:

   • Clone or create a new certificate template in AD CS (automatically incrementing its major version).

   • Edit the existing Intune SCEP certificate profile or create a new one to point to the new template name.

   • Reassign the updated profile to device groups.

   • Devices fetch the new profile on next policy sync and perform a new SCEP enrollment.

4. Revoking Old Certificates
   
   Old SCEP‑issued certificates remain valid until expiration unless manually revoked on the CA. To immediately invalidate them, perform a revocation in the Certification Authority console.