certutil - Page 3 - Uwe Gradenegger

View and clear the certificate enrollment policy cache for the Certificate Enrollment Policy Web Service (CEP).

After a certificate enrollment policy is configured and used by a subscriber, the results are cached locally (Enrollment Policy Cache).

If changes are now made to the infrastructure, for example by publishing or removing a new certificate template on a certification authority accessible via Certificate Enrollment Web Service (CES), these changes are not immediately visible to subscribers due to the cache.

For this reason, it may be helpful to view or clear the cache.

Manually running the autoenrollment process

By default, all domain members automatically replicate the Public Key Services object he Active Directory forest through the autoenrollment process. The triggers for this are:

When the user logs in (for computers, when the computer account logs in, i.e. at system startup).
By timer every 8 hours.
When updating group policies, assuming there has been a change.

If you do not want to wait for the autoenrollment to be triggered automatically, you can start it manually. The different ways to run the autoenrollment process are described below.

Inspect a certificate request (CSR)

Often, before submitting a certificate request to a certification authority - or before issuing the certificate - you want to verify that it contains the desired values.

The following describes how to achieve this.

Subsequently change the Subject Distinguished Name (DN) of a certificate request (CSR)

Sometimes it is necessary to change the Subject Distinguished Name (also called Subject, Subject DN, Applicant or Subject) of a certificate request before issuing the certificate.

Under certain circumstances, this is certainly possible, as described below.

(Re-)Installing the Microsoft Standard Certificate Templates

There may be cases where it is necessary to install the standard Microsoft certificate templates before installing the first Active Directory integrated certificate authority (Enterprise Certification Authority), or to reinstall the templates, for example because they have been corrupted or otherwise modified.

Active Directory forest compromised by EDITF_ATTRIBUTESUBJECTALTNAME2 flag

In net circulate unfortunately much at many Instructions (also the big players are not excluded from this, not even Microsoft itself or the Grand Master Komar), which fatally recommends that the EDITF_ATTRIBUTESUBJECTALTNAME2 flag should be set on the certification authority - supposedly to be able to issue Subject Alternative Name (SAN) extension certificates for manually submitted certificate requests.

Unfortunately, this approach is not only unnecessary, it also has some unpleasant side effects, which in the worst case can help an attacker to take over the entire Active Directory forest.

Description of the EDITF_ADDOLDKEYUSAGE flag

When installing a subordinate certificate authority, you may encounter the following behavior:

One requests a Key Usage extension that is marked as critical, for example, or does not include DigitalSignature.
However, the certificate issued by the parent certificate authority includes DigitalSignature, and the Key Usage extension is marked as non-critical.
The parent certification authority is a standalone certification authority, i.e. without Active Directory integration.

Importing a certificate into a smart card

Sometimes it is necessary to import a certificate that uses a software key into a smart card.

(Mass) deletion of entries in the certification authority database (certificates, requirements, revocation lists)

Sometimes it happens that the database of the certification authority becomes extremely large. Perhaps a large number of certificate requests have arrived unnoticed and have been rejected, or perhaps there are many certificates in the database that have been issued twice. Before the certification authority database compacts can be used, these entries must first be deleted in order to free up the storage space in the database.

Compacting (defragmenting) the certification authority database

Sometimes it happens that the database of the certification authority becomes extremely large. Perhaps a large number of certificate requests have arrived unnoticed and have been rejected, or perhaps there are many certificates in the database that have been issued twice. After the corresponding entries have been deleted from the Certification Authority database, the space now gained must (can) still be freed by compacting this in the server's file system.

Viewing the certificate authority database revocation list table

By default, the certification authority stores all revocation lists that have not yet expired in the certification authority database.

Under certain circumstances, e.g. due to a misconfigured script, a large number of blacklists are stored in the database in this way, which can lead to a corresponding growth of the database (e.g. if large blacklists are recreated very often).

certutil -dcinfo fails with error message "KDC certificates: Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)"

Assume the following scenario:

Domain controllers have certificates for LDAP over SSL.
The certificates do not include the Extended Key Usage "Smart Card Logon" or "Kerberos Authentication".
If you run certutil -dcinfo, the command reports the following error message:

0 KDC certificates for DC01
No KDC Certificate in MY store
KDC certificates: Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)

Manual publishing of a certificate revocation list (CRL) to Active Directory fails with error 0x8007202b (WIN32: 8235 ERROR_DS_REFERRAL)

Assume the following scenario:

An offline root certificate authority has been installed. The server on which the certificate authority is installed is not a domain member.
This is configured for Active Directory blacklist publications.
The blacklists are uploaded to the Active Directory using certutil -dspublish.
The operation fails with the following error message:

certutil -dspublish "ADCS Labor Root CA.crl"
 ldap:///CN=ADCS Lab Root CA,CN=ADCS Lab Root CA,CN=cdp,CN=Public Key Services,CN=Services,DC=UnavailableConfigDN?certificateRevocationList?base?objectClass=cRLDistributionPoint?certificateRevocationList
 ldap: 0xa: LDAP_REFERRAL: 0000202B: RefErr: DSID-03100835, data 0, 1 access points
         ref 1: 'unavailableconfigdn'
 CertUtil: -dsPublish command FAILED: 0x8007202b (WIN32: 8235 ERROR_DS_REFERRAL)
 CertUtil: A referral was returned from the server.

Requesting a certificate fails with the error message "A valid certification authority (CA) configured to issue certificates based on this template cannot be located, or the CA does not support this operation, or the CA is not trusted."

Assume the following scenario:

You try to apply for a certificate from an Active Directory-integrated certification authority (Enterprise Certification Authority).
To do this, use the Microsoft Management Console (MMC), either for the logged-in user (certmgr.msc) or for the computer (certlm.msc).
However, the desired certificate template is not displayed for selection, even though it has been correctly published on the certification authority.
The logged-in user (or computer) also has the necessary permissions to request certificates from the certificate template in question (enroll).
In the list of available certificate templates within the MMC, all certificate templates are displayed. At the desired certificate template is written:

A valid certification authority (CA) configured to issue certificates based on this template cannot be located, or the CA does not support this operation, or the CA is not trusted.