I recently encountered the phenomenon that due to a faulty request logic, several users had made new certificate requests at regular intervals.
The certificate template was configured to have incoming certificate requests released by a certificate manager, i.e. the certificates were not issued automatically. The certificate requests were to be checked by a separate code and then released.
One would now expect that (since all certificate requests would eventually be approved) users would now find multiple certificates of the same type in their certificate store (and the applications that use it). However, this was not the case.
Test setup
Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.
To mimic the scenario, a certificate template was created and configured to require approval by a certificate manager.
Subsequently, certificate requests were triggered repeatedly.
(1..20) | ForEach-Object -Process { certreq -q -enroll "ADCSLaborBenutzerTest" }
These were now visible in the local store for certificate requests.
Certificate requests had also now accumulated on the certification authority and were approved manually.
The certificates were retrieved by the User autoenrollment task. A corresponding Group policy with setting "Renew expired certificates, update pending certificates, and remove revoked certificates". was set up.
certutil -pulse -user
First the shock moment, all certificate requests were picked up and found in the user's certificate store.
However, after a re-run of the user autoenrollment task, all certificates except the newest one were archived, leaving only one.
The option "Renew expired certificates, update pending certificates, and remove revoked certificates" is also responsible for this.
The reason why archiving took place only during the second run of the user autoenrollment task is that only during the second run all fetched certificates were available to determine the newest one.
Related links:
- Basics of manual and automatic Certificate Enrollment via Lightweight Directory Access Protocol (LDAP) and Remote Procedure Call / Distributed Common Object Model (RPC/DCOM)
- Programmatically trigger the autoenrollment process for the logged-in user
- Troubleshooting for automatic certificate request (autoenrollment) via RPC/DCOM