Die Beantragung eines Zertifikats schlägt fehl mit Fehlermeldung "The certificate request could not be submitted to the certification authority. Error: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)"

Folgendes Szenario angenommen:

Ein Benutzer beantragt ein Zertifikat von einer Active Directory integrierten Zertifizierungsstelle (Enterprise Certification Authority)
Die Beantragung des Zertifikats schlägt mit folgender Fehlermeldung fehl:

The certificate request could not be submitted to the certification authority. Error: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)

Alternativ könnte auch diese Fehlermeldung auftreten:

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)

Auch wenn eine auf IIS basierende Anwendung (Registrierungsdienst für Netzwerkgeräte (NDES), Zertifikatregistrierungs-Webdienst (CES), Zertifizierungsstellen-Webregistrierung (CAWE) oder eigene auf IIS basierende Entwicklungen) zum Einsatz kommt, kann der Fehlercode auf gleiche Weise auftreten.

Es gibt (eigentlich) nur zwei Gründe

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

Verallgemeinernd lässt sich sagen, dass der Fehlercode "RPC_S_SERVER_UNAVAILABLE" eigentlich nur aus genau zwei Gründen auftreten kann:

Die Verbindung zum RPC-Interface der Zertifizierungsstelle ist nicht möglich.
Die Verbindng zum RPC-Interface der Zertifizierungsstelle ist zwar möglich, aber es ist keine Authentifizierung an dieser möglich.

Den Ursachen für diese beiden Fälle wollen wir näher auf den Grund gehen.

Probleme mit der Firewall zeigen sich oft dadurch, dass die Zertifkatbeantragung lange "hängt", bevor der Fehler auf dem Client angezeigt wird (da nicht erlaubte Pakete in den meisten Fällen von den Firewalls verworfen werden, somit eine Antwort ausbleibt). Authentisierungsfehler hingegen zeigen sich in der Regel durch eine sehr schnelle Antwort.

Die beteiligten Komponenten bei einer DCOM Kommunikation mit der Zertifizierungsstelle

Nachfolgendes Diagramm sollte einen Überblick über die beteiligten Komponenten bei einer DCOM-basierten Kommunikation mit der Zertifizierungsstelle, also vom Client bis zum Zertifizierungsstellen-Dienst geben.

Wichtig für das Verständnis ist noch, dass exakt die gleiche Logik zum Einsatz kommt, wenn die Verbindung über einen der webbasierten Zusatzdienst für die PKI erfolgt (Registrierungsdienst für Netzwerkgeräte (NDES), Zertifikatregistrierungs-Webdienst (CES), Zertifizierungsstellen-Webregistrierung (CAWE) oder eigene auf IIS basierende Entwicklungen). Entsprechend findet man den gleichen Fehlercode häufig in deren Logs.

1. Netzwerkverbindung

Zunächst muss der Client in der Lage sein, über das Netzwerk mit der Zertifizierungsstelle zu kommunizieren.

Zunächst sollte überprüft werden, ob man den korrekten Hostnamen für den Zertifizierungsstellen-Server verwendet. Bei einer manuellen Verbindung wird dieser mit dem Kollandozeilenbefehl oder dem Programmaufruf mit angegeben. Bei einer Verbindung über die Microsoft Management Console oder Autoenrollment wird der Hostname auf dem pKIEnrollmenrService Objekt im Active Directory ausgelesen.

Angenommen, der Hostname ist korrekt, stellt sich als nächstes die Frage, ob die Namensauflösung korrekt arbeitet und den Servernamen korrekt auflöst. Insbesondere sollte danach Ausschau gehalten werden, ob vielleicht der Hostname der Zertifizierungsstelle wiederverwendet wurde und der DNS-Eintrag noch auf das alte Computerobjekt registriert ist.

Als nächstes kann nun eine Netzwerkverbindung zum Zertifizierungsstellen-Server hergestellt werden. Hierfür müssen (sofern vorhanden) die entsprechende Ports auf allen Firewalls auf dem Weg (Netzwerk-Firewalls und die Windows-Firewall auf dem Zertifizierungsstellen-Server) geöffnet sein.

Die benötigten Firewallregeln sind im Artikel "Benötigte Firewallregeln für Active Directory Certificate Services" beschrieben.

Auch sollte überprüft werden, ob es auf dem Weg eine "intelligente" Firewall gibt, die vielleicht (nicht ganz so intelligent) die RPC-Datenpakete beschädigt.

Ist der TCP-Port 135 zwar erreichbar, aber die "High Ports" 49152-65535 nicht, wird der Fehlercode wahrscheinlich "RPC_E_VERSION_MISMATCH" lauten.

Auch wenn es trivial klingt, sollte auch überprüft werden, ob der Zertifizierungsstellen-Server und der Zertifizierungsstellen-Dienst gestartet sind.

2. Das RPC-Interface

An der Zertifizierungsstelle angekommen, muss die erste Hürde in Hinsicht auf Authentifizierung am Remote Procedure Call (RPC) Interface genommen werden. Damit eine Verbindung hergestellt werden kann, muss das verbindende Konto die Berechtigung "Access this computer from the network" besitzen.

In der Standardeingstellung sind hier eingetragen:

Administrators
Backup Operators
Everyone
Users

BItte auch beachten, dass es auch ein gegenteiliges Recht "Deny access this computer from the network" gibt, in welchem das verbindende Konto ebenfalls nicht enthalten sein darf.

Schlägt die Authentisierung an dieser Stelle fehl, wird auf der Zertifizierungsstelle ein entsprechendes Audit-Ereignis zu finden sein.

Auch eine fehlerhafte Kerberos-Delegierung kann an dieser Stelle den gleichen Fehlercode verursachen. Ebenso der Umstand, wenn ein Benutzer mit einem abgelaufenen Anmeldetoken arbeitet.

Wenn das Benutzerkonto, mit welchem das Zertifikat beantragt wurde, sich in einer anderen Active Directory Gesamtstruktur befindet als die Zertifizierungsstelle, muss eine beidseitige Vertrauensstellung eingerichtet sein.

Wird bei Zertifikatbeantragung über Vertrauensstellungen hinweg (engl. Cross-Forest Autoenrollment) mit Selective Authentication gearbeitet, muss das beantragende Konto das "Allowed to Authenticate" Recht auf dem Computerobjekt der Zertifizierungsstelle besitzen.

3. DCOM Berechtigungen

Wurde die RPC-Hürde überwunden, wird eine Authentisierung an DCOM erfolgen. Für die Verwendung DCOM gibt es eine eigene Access Control List. Diese kann in der Verwaltungskonsole für Komponentendienste (dcomcnfg) unter "My Computer" eingesehen werden.

In der Kartekarte "COM Security" muss unter "Edit Limits" die Sicherheitsgruppe "Certificate Service DCOM Access" folgende Berechtigungen aufweisen:

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

In der lokalen "Certificate Service DCOM Access" (CERTSVC_DCOM_ACCESS) Sicherheitsgruppe befinden sich in der Standardeinstellung die "Authenticated Users".

Ein (hierdurch erklärbares) altbekanntes Kuriosum ist, dass – wenn man eine Zertifizierungsstelle auf einem Domänencontroller installiert (wovon nur abgeraten werden kann), keine uneingeschränkte Zertifikatbeantragung möglich ist. Dies ist darin begründet, dass Domänencontroller keine lokalen Sicherheitsgruppen kennen, und entsprechend die Domänengruppe "CERTSVC_DCOM_ACCESS" nachgepflegt werden muss.

Zu beachten ist, dass sich diese Einstellungen per Gruppenrichtlinie steuern lassen. In diesem Fall sind die Schaltflächen für "Edit Limits" ausgegraut und nicht benutzbar.

Die Einstellungen befinden sich unter "Security Settings" – "Local Policies" – "Security Options" und heißen:

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

Es kann vorkommen, dass durch gut gemeinte "Härtungsrichtlinien" die DCOM Berechtigungen entsprechend überschrieben wurden und die "Certificate Service DCOM Access" Sicherheitsgruppe entfernt wurde.

4. CertSrv Request Interface

Ist nun eine DCOM Anmeldung am Computer erlaubt, gibt es dann noch eine ACL am CertSrv Request Interface.

Unter "Component Services" – "Computers" – "My Computers" – "DCOM Config" befindet sich nun das CertSrv Request Interface, welches ebenfalls eine Access Control List (ACL) aufweist.

In der Kartekarte "Security" müssen folgende Berechtigungen gesetzt sein:

Launch and Activation Permissions: "Local Activation" und "Remote Activation" für "Everyone"
Access Permissions: "Local Access" und "Remote Access" für "Everyone".

5. Berechtigungen auf der Zertifizierungsstelle

Zu guter Letzt besitzt der Zertifizierungsstellen-Server-Prozess auch noch eine Zugangskontroll-Liste (engl. Access Control List, ACL).

Bitte auch bedenken, dass der Zertifizierungsstellen-Dienst natürlich auch gestartet sein und laufen muss.

Wenn es die Verbindung bis hierher geschafft hat, aber wegen falscher Berechtigungen abgelehnt würde, würde allerdings der Fehlercode CERTSRV_E_ENROLL_DENIED zurückgegeben.

Nach der Zertifizierungsstelle gibt es dann natürlich noch die Zertifikatvorlagen, welche auch noch einmal eine Access Control List besitzen. Ist keine Zertifikatbeantragung für eine bestimmte Zertifikatvorlage aufgrund fehlender Berechtigungen möglich, wird der Fehlercode CERTSRV_E_TEMPLATE_DENIED zurückgegeben.

Wird eine Zertifikatvorlage angefordert, welche der Zertifizierungsstelle nicht bekannt ist, ist es der Fehlercode CERTSRV_E_UNSUPPORTED_CERT_TYPE.

Für eine vollständige Liste der von der Zertifizierungsstelle im Falle einer abgelehnten Zertifikatanforderung zurückgegebenen Fehler siehe Ereignis mit ID 53 der Quelle Microsoft-Windows-CertificationAuthority.

Die Berechtigungen zum Beantragen von Zertifikaten auf einer Zertizierungsstelle werden auch in das entsprechende pKIEnrollmentService Objekt im Active Directory übertragen. So können diese Berechtigungen beispielsweise verwendet werden, um Eine Active Directory integrierte Zertifizierungsstelle (Enterprise Certification Authority) in den Wartungsmodus zu versetzen.

Ein einfacher Funktionstest

Ein Verbindungstest mit dem naheliegenden "certutil -ping" Befehl testet nicht, ob die TCP "High Ports" in der Firewall geöffnet sind und ist daher nicht aussagekräftig genug.

Mit der folgenden Befehlsabfolge in der Windows PowerShell kann einfach die gesamte Kette bis zur Zertifizierungsstelle validiert werden.

$ConfigString = "{Hostname-der-Zertifizierungstelle}\{Common-Name-der-Zertifizierungsstelle}"
$CertRequest = New-Object -ComObject CertificateAuthority.Request
$CertRequest.GetCAProperty($ConfigString, 0x6, 0, 4, 0)

Der Befehl sollte bei Erfolg den Common Name der Zertifizierungsstelle zurückmelden.

Weiterführende Links:

Externe Quellen

Certificate Enrollment – The RPC Server is unavailable (Microsoft TechNet Foren)
Dcomcnfg Edit Limits is grayed out (Microsoft TechNet Foren)
Certificate Services Architecture (Microsoft Corporation)
Description of the changes to DCOM security settings after you install Windows Server 2003 Service Pack 1 (Microsoft Corporation)