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 oder ein Computer 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 Verbindung 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 Zertifikatbeantragung 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 Zusatzdienste 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 Kommandozeilenbefehl oder dem Programmaufruf mit angegeben. Bei einer Verbindung über die Microsoft Management Console oder Autoenrollment wird der Hostname auf dem pKIEnrollmentService 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 entsprechenden 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 Standardeinstellung sind hier eingetragen:
- Administrators
- Backup Operators
- Everyone
- Users
Bitte hier auch die lokale Gruppe "Users" auf der Zertifizierungsstelle prüfen. In der Standardeinstellung sind hier die "Authenticated Users" eingetragen, diese könnten durch eine Härtungsmaßnahme entfernt worden sein. In diesem Fall kann es passieren, dass die Zertifikatbeantragung für Benutzer funktioniert, aber nicht für Computerkonten.
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 in den meisten Fällen auf der Zertifizierungsstelle ein entsprechendes Audit-Ereignis im Sicherheits-Ereignisprotokoll 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 von DCOM gibt es eine eigene Access Control List. Diese kann in der Verwaltungskonsole für Komponentendienste (dcomcnfg) unter "My Computer" eingesehen werden.
In der Karteikarte "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.
3.1 DCOM Härtung
Bedingt durch CVE-2021-26414 hat Microsoft ein Update zur Härtung der Schnittstelle veröffentlicht .
Versucht ein System, welches den Patch noch nicht installiert hat, mit einer Zertifizierungsstelle zu kommunizieren, die den Patch installiert hat, wird ebenfalls der Fehler RPC_S_SERVER_UNAVAILABLE ausgelöst, und die Zertifizierungsstelle protokolliert das (durch den Patch neu eingeführte) Ereignis Nr. 10036 der Quelle DistributedCOM im System-Ereignisprotokoll:
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 Karteikarte "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 Zertifizierungsstelle 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-Zertifizierungsstelle}\{Common-Name-der-Zertifizierungsstelle}"
$CertRequest = New-Object -ComObject CertificateAuthority.Request
$CertRequest.GetCAProperty($ConfigString, 0x6, 0, 4, 0)Es ist natürlich auch möglich, dass der angemeldete Benutzer sich erfolgreich authentisieren kann, das Computerkonto aber nicht. Darum kann es durchaus Sinn machen, auch einmal (z.B. mit psexec) in den Computerkontext zu wechseln und den Test von dort aus zu wiederholen.
Die Variable "$ConfigString" muss mit dem Konfigurations-String für die entsprechende Zertifizierungsstelle befüllt werden. Dieser kann einfach durch die Eingabe von "certutil" auf der Kommandozeile ermittelt werden.
Im Fehlerfall werden wir die bekannte Meldung hier wieder finden.
Im Erfolgsfall sollte der Befehl den "Common Name" der Zertifizierungsstelle zurückmelden.
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)