Troubleshooting for automatic certificate request (autoenrollment) via RPC/DCOM

Author Uwe GradeneggerPosted on Categories Function test, TroubleshootingTags , , , , , , , , ,

Assume the following scenario:

  • A certificate template is configured for automatic certificate request (autoenrollment).
  • The certificate template is published on a certification authority (Enterprise Certification Authority) integrated into Active Directory.
  • However, the users or computers configured for automatic Certificate Enrollment do not apply for certificates as intended.

The following is a troubleshooting guide.

This article describes the troubleshooting of Autoenrollment via RPC/DCOM. Many of the statements can also be applied to the Requesting certificates via WSTEP (CEP/CES) transferred.

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.

Narrowing down the problem area

First, it must be clarified in which context the error occurs.

  • Does it occur for certificates of a user?
  • Does it occur for certificates of a computer?

For troubleshooting when applying for user certificates, it is usually necessary to join the user in question in their session. If the error occurs in the context of a computer, it is often possible to work without the user on the system with an administrative identifier.

Remote troubleshooting capabilities

The following methods of accessing the system in question thus result for troubleshooting:

  • Screen sharing, together with and in the context of the end user.
  • Administrative / Interactive Login (Console/Remote Desktop)
  • Administratively / via remote console using PSExec Remoting (not recommended)
  • Administratively / via remote console using PowerShell Remoting

It is generally not recommended to log on to a client system with an administrative domain account because of the high risk of credential theft.

Since the lowest common denominator is often the command line, the following troubleshooting is also done with this.

Classification of the error pattern

Basically, autoenrollment errors can be divided into the following areas, which are described in more detail below:

  • The certificate request is not made
  • The certificate request is made but does not arrive at the certification authority
  • The certificate request is made, also arrives at the Certification Authority, but is rejected there

The certificate request is not made

If the certificate requirement is not made at all, the following points should be illuminated:

  • Does a certificate of the certificate template in question already exist?
  • Is Autoenrollment enabled on the client?
  • Is the autoenrollment process triggered?
  • Is the account in question eligible to apply for a certificate?
  • Can the client establish the chain of trust to the certificate authority?
  • Can the client generate a key pair?

Details: Does a certificate of the certificate template in question already exist?

For the user context:

certutil -user -store my

For the computer context:

certutil -store my

This command also displays archived certificates. Therefore, it is clearer to use the Windows PowerShell.

For the user context:

Get-ChildItem -Path Cert:\CurrentUser\My

For the computer context:

Get-ChildItem -Path Cert:\LocalMachine\My

Details: Is Autoenrollment enabled on the client?

If autoenrollment is not enabled on the client, this usually manifests itself by no certificate request taking place despite the unique triggers.

The configuration for autoenrollment is usually set by group policy. However, just because a group policy exists, is configured, and linked does not mean that it has reached the client.

A possible cause could be, for example, lack of domain connectivity or filtering based on a security group or other criterion.

Please also note that no group policies are applied when a process is executed via RunAs and therefore under certain circumstances (e.g. when logging in for the first time via RunAs) no auto-enrollment takes place.

  • Activating the autoenrollment process ("Configuration model") first causes a replica of the "Public Key Services" object to be loaded from the Active Directory configuration partition. It must at least be activated so that the further options can be used.
  • The "Renew expired certificates, update pending certificates, and remove revoked certificates" causes expired certificates to be renewed automatically if they were issued by an Active Directory integrated certificate authority. In addition, approved certificate requests are fetched from certification authorities if they are available. Revoked certificates are archived.
  • The "Update certificates that use certificate templates"causes certificates to be automatically requested which are enabled for autoenrollment for the applicant. It must therefore be activated on the client so that certificates can be requested automatically.

The autoenrollment configuration is stored locally in the registry:

For the user context:

HKCU\Software\Policies\Microsoft\Cryptography\AutoEnrollment\AEPolicy

For the computer context:

HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment\AEPolicy

The individual configuration options for "AEPolicy" are described below.

ValueDescriptionResult
0x00000000 or not availableAutoEnrollment process is activates
„Update certificates that use certificates templates" is deactivated		none automatic request for certificates
none Automatic renewal of expired certificates
none Automatic collection of approved certificate requests
none Automatic archiving of revoked certificates
0x00000001AutoEnrollment process is activates
„Update certificates that use certificates templates" is activates
„Renew expired certificates, update pending certificates, and remove revoked certificates" is deactivated		automatic request for certificates
none Automatic renewal of expired certificates
none Automatic collection of approved certificate requests
none Automatic archiving of revoked certificates
0x00000006AutoEnrollment process is activates
„Update certificates that use certificates templates" is deactivated
„Renew expired certificates, update pending certificates, and remove revoked certificates" is activates		none automatic request for certificates
Automatic renewal of expired certificates
Automatic collection of approved certificate requests
Automatic archiving of revoked certificates
0x00000007AutoEnrollment process is activates
„Update certificates that use certificates templates" is activates
„Renew expired certificates, update pending certificates, and remove revoked certificates" is activates		automatic request for certificates
Automatic renewal of expired certificates
Automatic collection of approved certificate requests
Automatic archiving of revoked certificates
0x00008000AutoEnrollment is deactivatednone automatic request for certificates
none Automatic renewal of expired certificates
none Automatic collection of approved certificate requests
none Automatic archiving of revoked certificates

In order for the automatic certificate request to take place, "AEPolicy" must therefore have the value 0x1 or better the value 0x7 have. The value can be queried with the following command line commands.

For the user context:

reg query HKCU\Software\Policies\Microsoft\Cryptography\AutoEnrollment /v AEPolicy

For the machine context:

reg query HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment /v AEPolicy

Alternatively, the value can also be queried via Windows PowerShell.

For the user context:

(Get-ItemProperty -Path HKCU:\Software\Policies\Microsoft\Cryptography\AutoEnrollment).AEPolicy

For the machine context:

(Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Cryptography\AutoEnrollment).AEPolicy

The settings can also be created without a group policy using the following commands. The value from the sample code may need to be adjusted using the table above.

For the user context:

New-Item -Path HKCU:\Software\Policies\Microsoft\Cryptography\AutoEnrollment
Set-ItemProperty -Path HKCU:\Software\Policies\Microsoft\Cryptography\AutoEnrollment -Name AEPolicy -Value 0x7 -Force

For the machine context:

New-Item -Path HKLM:\Software\Policies\Microsoft\Cryptography\AutoEnrollment
Set-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Cryptography\AutoEnrollment -Name AEPolicy -Value 0x7 -Force

Details: Is the autoenrollment process triggered?

The triggers for running the autoenrollment process on domain members 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.

In the task planner, corresponding tasks are located under "Microsoft" - "Windows" - "CertificateServicesClient".

It is therefore quite possible that no trigger for the Certificate Enrollment has been triggered yet (see also article "No certificate is requested via autoenrollment if a user is connected via Virtual Private Network (VPN)„).

Manually the process can be triggered with the following commands.

For the user context:

certutil -pulse -user

For the computer context:

certutil -pulse

You can determine if the process has been triggered by looking at the status of the tasks in the Task Scheduler. This can also be done via Windows PowerShell:

For the user context:

Get-ScheduledTask `
-TaskPath \Microsoft\Windows\CertificateServicesClient\ `
-TaskName UserTask | Select-Object -Property State

For the computer context:

Get-ScheduledTask `
-TaskPath \Microsoft\Windows\CertificateServicesClient\ `
-TaskName SystemTask | Select-Object -Property State

Please note: It is also possible that the process runs permanently and is never terminated. This is the case, for example, when manual user intervention is necessary, but the user does not perform this interaction.

The last execution time and the result of the task can also be viewed via Windows PowerShell.

For the user context:

Get-ScheduledTaskInfo `
-TaskPath \Microsoft\Windows\CertificateServicesClient\ `
-TaskName UserTask

For the computer context:

Get-ScheduledTaskInfo `
-TaskPath \Microsoft\Windows\CertificateServicesClient\ `
-TaskName SystemTask

Details: Is the account in question eligible to apply for a certificate?

In order for a certificate request to be made, the user or computer must be authorized in two places:

  • In the security permissions of the certificate template in question
  • In the security settings of the certification authority that provides the certificate template

Both pieces of information are stored in the Active Directory. If the user is not authorized, no certificate request is made.

Be careful when using security groups to grant permissions: Just because the user or computer is a member of a security group in Active Directory does not mean that it has already been applied in the Kerberos ticket. If the user has not yet logged in or restarted the computer since being added to the group, the group membership has not yet been applied.

The autoenrollment client does not inspect the local Kerberos ticket, but the access permissions in Active Directory. Therefore, the phenomenon would occur here that a certificate request is triggered, but the certificate request would be rejected by the certification authority due to lack of authorization (Event no. 53 with error code CERTSRV_E_TEMPLATE_DENIED on the certification authority).

Whether the group membership has already been mapped locally can be checked with the following command line commands.

For the user context:

gpresult /R /Scope:User

For the computer context:

gpresult /R /Scope:Computer

Certificate request permissions can also be checked with the following command line command:

certutil -config "hostname-of-the-CA\common-name-of-the-CA" -catemplates

The authorization to request certificates on the certification authority is ensured in the default setting via a corresponding entry for "Authenticated Users".

This information is synchronized into the Active Directory. Accordingly, clients can already find out about their authorizations before submitting a request. If they are not authorized, no certificate request is made.

Typical causes of missing permissions on the certification authority are described in the following articles:

Details: Can the client establish the chain of trust to the certificate authority?

If one tries to request the certificate through the Microsoft Management Console (certmgr.msc for the user context and certlm.msc for the computer context), and the certificate template is displayed but is not selectable 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.", it is possible that the client does not know the corresponding issuing certification authority, i.e. cannot establish the chain of trust.

In this case, the following should be checked:

  • Is the root CA stored in the corresponding repository for trusted root CAs?
  • Are all intermediate CAs (if any) stored in the intermediate CA certificate store? (This store is automatically populated on domain clients from the "AIA" object of the Public Key Services container in Active Directory. Accordingly, it should be checked whether the certificates are also stored there).

See also:

Details: Can the client generate a key pair?

The key pair cannot be generated, e.g. because the Cryptographic Service Provider or Key Storage Provider is not present or does not work (on the client, the Event no. 57 trigger).

Whether a particular key storage provider is usable on the client can be checked with the following command.

certutil -csp "Microsoft Platform Crypto Provider" -csptest

If successful, the following message would be generated:

CertUtil: -csptest command was executed successfully.

In case of an error, a message similar to the following one would be generated:

CertUtil: -csptest command FAILED: 0x80090030 (-2146893776 NTE_DEVICE_NOT_READY)
CertUtil: The device that is required by this cryptographic provider is not ready for use.

It is also possible to generate a self-signed certificate with Windows PowerShell using the appropriate Key Storage Provider:

New-SelfSignedCertificate `
-Provider "Microsoft Platform Crypto Provider" `
-KeyLength 2048 `
-Subject "CN=Test" `
-CertStoreLocation Cert:\CurrentUser\My

See also article "Requesting a certificate is not possible because the certificate template is not displayed. The error message is "Can not find a valid CSP in the local machine."„.

The certificate request is made but does not arrive at the certification authority

If the certificate request is made but does not arrive at the Certification Authority, the following issues should be illuminated:

  • Can the certification authority be reached and authenticated?
  • Can a certificate be requested manually from the certificate template in question?

Is the certification authority reachable and can it be authenticated?

Errors that may occur due to a problem with the network connection or authentication on the RPC/DCOM interface cause the error code RPC_S_SERVER_UNAVAILABLE.

See article "Certificate request fails with error message "The certificate request could not be submitted to the certification authority. Error: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)".„.

For the Certificate Enrollment Web Service (CES), the client issues the same error code if the server service is running but cannot connect to the certification authority. However, if the server service cannot start at all because the certification authority is not reachable at that time, the error code WS_E_ENDPOINT_FAILURE which in turn can be broken down to RPC_SERVER_UNAVAILABLE in most cases in the backend.

The following command sequence in Windows PowerShell can be used to easily validate the entire chain up to the certificate authority (via RPC/DCOM).

$ConfigString = "{hostname-of-the-certification-authority}\{common-name-of-the-certification-authority}"
$CertRequest = New-Object -ComObject CertificateAuthority.Request
$CertRequest.GetCAProperty($ConfigString, 0x6, 0, 4, 0)

The command should return the common name of the certification authority if successful.

For the computer context, you must first change to this (NT-AUTHORITY\SYSTEM). This can be done via psexec, for example:

psexec -s -i powershell.exe

Then the previous command can be executed in the context of the computer account.

Details: Can a certificate be requested manually from the certificate template in question?

The certificate request for a specific certificate template can be triggered manually (i.e. without autoenrollment) with the following command.

For the user context:

certreq -q -enroll "name-of-certificate-template"

For the computer context:

certreq -q -machine -enroll "name-of-the-certificate-template".

Calling the command without the -q parameter opens a GUI dialog. In a remote shell connection, this causes the process to halt.

If the certificate request fails with error code "CERTSRV_E_UNSUPPORTED_CERT_TYPE", see article "Certificate request fails with error message "The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)."„.

Other possible causes

The certificate request is made, also arrives at the Certification Authority, but is rejected there

If the certificate request arrives at the certification authority but is rejected there, it will log event #53. Possible causes and their solution are described in the corresponding article.

Increase logging level for autoenrollment on the client

To further isolate a problem, it can be helpful to increase the logging level for autoenrollment on the client (see also the article "Enable logging for automatic certificate request (autoenrollment)„).

The following command line command can be used to activate logging for both the user and the system context (all events of the types "Error", "Warning" and "Information" are output):

certutil -setreg Enroll\LogLevel 4

The changes become active directly without a new login or restart.

A certificate request can then be triggered. Corresponding events should now be found in the application event log.

Structure of a common event sequence

A common sequence looks like this:

SourceNumberEvent text
Microsoft-Windows-CertificateServicesClient-AutoEnrollment2Automatic certificate enrollment for %1 started.
Microsoft-Windows-CertificateServicesClient-AutoEnrollment4Automatic certificate enrollment for %1 invoked the enrollment API.
Microsoft-Windows-CertificateServicesClient1Certificate Services Client has been started successfully.
Microsoft-Windows-CertificateServicesClient3Certificate Services Client has detected network connectivity.
Microsoft-Windows-CertificateServicesClient-CertEnroll65Certificate enrollment for %1 is successfully authenticated by policy server %2 using authentication mechanism %5 (Credential: %4). Policy Id: %3
Microsoft-Windows-CertificateServicesClient-CertEnroll64Certificate enrollment for %1 successfully load policy from policy server %2
(further if necessary)
Microsoft-Windows-CertificateServicesClient-AutoEnrollment5Automatic certificate enrollment for %1 returned from the enrollment API.
Microsoft-Windows-CertificateServicesClient-AutoEnrollment3Automatic certificate enrollment for %1 completed.
Microsoft-Windows-CertificateServicesClient2Certificate Services Client has been stopped.

Events query

The following Windows PowerShell command can be used to read out the events:

Get-WinEvent -FilterHashtable @{
Logname='Application
ProviderName=@('Microsoft-Windows-CertificateServicesClient-AutoEnrollment','Microsoft-Windows-CertificateServicesClient','Microsoft-Windows-CertificateServicesClient-CertEnroll')
StartTime=(Get-Date -Hour 0 -Minute 0 -Second 0)
} | Sort-Object -Property TimeCreated -Descending

The following criteria are applied:

  • Source: Events of the three categories concerned
  • Period: The events of today
  • Sorting: Descending by date

Save events to a file

The events can also be easily saved in CSV format for analysis away from the faulty system:

... | Select-Object -Property TimeCreated,Id,LevelDisplayName,Message | Export-Csv -Path .\$($env:Computername)_ClientEvents.csv -Encoding Unicode -NoTypeInformation

Export to an .evt or .evtx file is no longer possible after filtering.

Related links:

External sources

en_USEnglish
de_DEDeutsch en_USEnglish