The request for a certificate fails with the error message "The certificate request could not be submitted to the certification authority. Error: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_SERVER_SERVER_UNAVAILABLE)"

Assume the following scenario:

A user requests a certificate from an Active Directory integrated certification authority (Enterprise Certification Authority)
The certificate request fails with the following 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)

Alternatively, this error message could also occur:

The encryption certificate for the certification authority (CA) could not be retrieved. Error: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)

Even if an application based on IIS (Network Device Registration Service (NDES), Certificate Enrollment Web Service (CES), Certification Authority Web Enrollment (CAWE) or own developments based on IIS) is used, the error code can occur in the same way.

There are (actually) only two reasons

Generalizing, it can be said that the error code "RPC_S_SERVER_UNAVAILABLE" can actually only occur for exactly two reasons:

Connection to the RPC interface of the certification authority is not possible.
The connection to the RPC interface of the certification authority is possible, but no authentication to it is possible.

We want to get to the bottom of the causes for these two cases in more detail.

Problems with the firewall are often indicated by the fact that the certificate request "hangs" for a long time before the error is displayed on the client (since packets that are not allowed are discarded by the firewalls in most cases, so there is no response). Authentication errors, on the other hand, are usually indicated by a very fast response.

The components involved in a DCOM communication with the certification authority

The following diagram should give an overview of the components involved in a DCOM-based communication with the certification authority, i.e. from the client to the certification authority service.

It is also important to understand that exactly the same logic is used when the connection is made via one of the web-based supplementary services for the PKI (Network Device Registration Service (NDES), Certificate Enrollment Web Service (CES), Certification Authority-Web registration (CAWE) or own developments based on IIS). Accordingly the same error code is often found in their logs.

1. network connection

First, the client must be able to communicate with the certificate authority over the network.

The first thing to check is that you are using the correct hostname for the certificate authority server. In case of a manual connection, this is specified with the collando line command or the program call. In case of a connection via Microsoft Management Console or Autoenrollment, the hostname is read from the pKIEnrollmenrService object in Active Directory.

Assuming the hostname is correct, the next question is whether the name resolution works correctly and resolves the server name correctly. In particular, look to see if perhaps the host name of the certification authority has been reused and the DNS record is still registered to the old computer object.

Next, a network connection to the certification authority server can now be established. For this (if available), the corresponding ports must be opened on all firewalls on the path (Network firewalls and the Windows firewall on the certification authority server) be open.

The required firewall rules are described in the article "Firewall rules required for Active Directory Certificate Services" described.

It should also be checked if there is an "intelligent" firewall on the way, which might (not so intelligently) corrupt the RPC data packets.

If TCP port 135 is reachable but the "high ports" 49152-65535 are not, the error code will probably be "RPC_E_VERSION_MISMATCH".

Although it sounds trivial, it should also be checked that the certificate authority server and the certificate authority service are started.

2. the RPC interface

Once at the certification authority, the first hurdle must be cleared in terms of authentication at the Remote Procedure Call (RPC) interface. In order for a connection to be established, the connecting account must have the authorization "Access this computer from the network".

In the default setting are entered here:

Administrators
Backup Operators
Everyone
Users

Please also note that there is also an opposite right "Deny access this computer from the network", in which the connecting account must not be included either.

If authentication fails at this point, a corresponding audit event will be found on the certification authority.

Also a faulty Kerberos delegation can cause the same error code at this point. Likewise the circumstance, if a user is working with an expired logon token.

If the user account with which the certificate was requested is located in a different Active Directory forest than the certification authority, a two-way trust relationship must be established.

If Selective Authentication is used for cross-trust autoenrollment, the requesting account must have the "Allowed to Authenticate" right on the certificate authority's computer object.

3. DCOM permissions

If the RPC hurdle was overcome, authentication to DCOM will take place. There is a separate Access Control List for the use of DCOM. This can be viewed in the component services management console (dcomcnfg) under "My Computer".

In the "COM Security" tab, under "Edit Limits", the "Certificate Service DCOM Access" security group must have the following permissions:

Access Permissions: "Local Access" and "Remote Access
Launch and Activation Permissions: "Local Launch" and "Remote Launch

The local "Certificate Service DCOM Access" (CERTSVC_DCOM_ACCESS) security group contains the "Authenticated Users" in the default setting.

A (hereby explainable) old known curiosity is that - if one installs a certificate authority on a domain controller (which can only be discouraged), no unrestricted Certificate Enrollment is possible. This is due to the fact that domain controllers do not know any local security groups, and the domain group "CERTSVC_DCOM_ACCESS" must be maintained accordingly.

Note that these settings can be controlled via group policy. In this case, the buttons for "Edit Limits" are grayed out and not usable.

The settings are located under "Security Settings" - "Local Policies" - "Security Options" and are called:

DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax

It may be that well-intentioned "hardening" policies have appropriately overridden the DCOM permissions and removed the "Certificate Service DCOM Access" security group.

4. certSrv request interface

If a DCOM login is now allowed on the computer, there is then another ACL on the CertSrv Request Interface.

Under "Component Services" - "Computers" - "My Computers" - "DCOM Config" you will now find the CertSrv Request Interface, which also has an Access Control List (ACL).

The following permissions must be set in the "Security" tab:

Launch and Activation Permissions: "Local Activation" and "Remote Activation" for "Everyone
Access Permissions: "Local Access" and "Remote Access" for "Everyone".

5. authorizations on the certification authority

Last but not least, the certificate authority server process also has an access control list (ACL).

Please also keep in mind that the certification authority service must of course also be started and running.

However, if the connection made it this far but was denied due to incorrect permissions, the error code CERTSRV_E_ENROLL_DENIED would be returned.

After the certification authority, there are of course the certificate templates, which also have an access control list. If it is not possible to request a certificate for a particular certificate template due to a lack of permissions, the error code CERTSRV_E_TEMPLATE_DENIED is returned.

If a certificate template is requested which is not known to the certification authority, it is the CERTSRV_E_UNSUPPORTED_CERT_TYPE error code.

For a complete list of errors returned by the certification authority in the case of a rejected certificate request, see the following Event with ID 53 of the source Microsoft-Windows-CertificationAuthority.

The authorizations to apply for certificates on a certification authority are also entered in the corresponding pKIEnrollmentService object in the Active Directory. For example, these permissions can be used to Putting an Active Directory integrated certification authority (Enterprise Certification Authority) into maintenance mode.

A simple function test

A connection test with the obvious "certutil -ping" command does not test whether the TCP "high ports" in the firewall are open and is therefore not meaningful enough.

The following command sequence in Windows PowerShell can be used to easily validate the entire chain up to the certificate authority.

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

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)".