November 2020 – Uwe Gradenegger

SSH (PuTTY) auf Windows mit einem Zertifikat / einer Smartcard verwenden

Zur sicheren Administration von Linux-System gehört, dass man SSH-Anmeldungen per Passwort vermeidet und stattdessen eine Anmeldung mit RSA Schlüsseln vornimmt.

Der de-facto Standard für SSH-Verbindungen auf Windows ist PuTTY. Hier ist eine Anmeldung mit RSA Schlüsseln zwar implementiert, jedoch können lediglich Schlüssel-Dateien verwendet werden, was den Nachteil hat, dass diese nahezu ungeschützt im Dateisystem liegen.

Eine tolle Option wäre doch sicherlich, RSA-Schlüssel aus der Windows-Welt, und vielleicht sogar gespeichert auf einer physischen oder virtuellen Smartcard einzusetzen.

Bei der Installation einer Active Directory integrierten Zertifizierungsstelle erscheint die Fehlermeldung "Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)"

Folgendes Szenario angenommen:

Es wird eine ins Active Directory integrierte Zertifizierungsstelle (Enterprise Certification Authority) per Windows PowerShell installiert.
Für die Installation der Zertifizierungsstelle werden delegierte Berechtigungen verwendet. Der installierende Benutzer ist also nicht Mitglied der Gruppe "Enterprise Administrators".
Nach Ausführen des Rollenkonfigurations-Assistenten wird eine oder mehrere der folgenden Fehlermeldungen auf der Kommandozeile ausgegeben:

Setup could not add the Certification Authority's computer account to the Pre-Windows 2000 Compatible Access security group. Certificate managers Restrictions feature will not work correctly on this Certification Authority. To fix this, an administrator must manually add the Certification's Authority's computer account to the Pre-Windows 2000 Compatible Access security group in Active Directory. Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Warning: Setup could not add the certification authority’s computer account to the cert Publishers Security Group. This Certification Authority will not be able to publish certificates in Active Directory. To fix this, an administrator must manually add the Certification Authority’s computer account to the Cert Publishers security group in Active Directory.  Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Die Installation eines Zertifizierungsstellen-Zertifikats schlägt fehl mit Fehlermeldung "Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)"

Folgendes Szenario angenommen:

Es wird eine ins Active Directory integrierte Zertifizierungsstelle (Enterprise Certification Authority) installiert.
Für die Installation der Zertifizierungsstelle werden delegierte Berechtigungen verwendet. Der installierende Benutzer ist also nicht Mitglied der Gruppe "Enterprise Administrators".
Nach der Ausstellung des Zertifizierungsstellen-Zertifikats durch die übergeordnete Zertifizierungsstelle wird dieses installiert, um die Rollenkonfiguration abzuschließen.
Die Installation des Zertifizierungsstellen-Zertifikats schlägt mit folgender Fehlermeldung fehl:

Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Die Installation eines Zertifizierungsstellen-Zertifikats schlägt fehl mit Fehlercode "NTE_PROVIDER_DLL_FAIL"

Folgendes Szenario angenommen:

Es wird eine Zertifizierungsstelle installiert.
Die Zertifizierungsstelle verwendet ein Gemalto/SafeNet Hardware Security Modul (HSM) mit dem SafeNet Luna Key Storage Provider.
Nach der Ausstellung des Zertifizierungsstellen-Zertifikats durch die übergeordnete Zertifizierungsstelle wird dieses installiert, um die Rollenkonfiguration abzuschließen.
Die Installation des Zertifizierungsstellen-Zertifikats schlägt mit folgender Fehlermeldung fehl:

An error was detected while configuring Active Directory Certificate Services.
The Active Directory Certificate Services Setup Wizard will need to be rerun to complete the configuration.
The new certificate public key does not match the current outstanding request.
The wrong request may have been used to generate the new certificate: Provider DLL failed to initialize correctly.
0x8009001d (-2146893795 NTE_PROVIDER_DLL_FAIL)

SSCEP: Subject of our request does not match that of the returned Certificate!

Folgendes Szenario angenommen:

Es wird eine Zertifikatbeantragung auf einem Linux-System (beispielsweise ein Thin Client) mittels SSCEP gegen einen Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) durchgeführt.
Die Zertifikatbeantragung schlägt mit folgender Fehlermeldung fehl:

sscep: Subject of our request does not match that of the returned Certificate!

Verwenden von nicht definierten Relative Distinguished Names (RDN) in ausgestellten Zertifikaten

Manchmal ist es erforderlich, Relative Distinguished Names (RDNs) in ausgestellten Zertifikaten zu erlauben, die nicht definiert sind und entsprechend auch nicht im SubjectTemplate Wert der Registrierung der Zertifizierungsstelle konfiguriert werden könnten.

Ein Beispiel hierfür ist der Organization Identifier mit Objektidentifizierer 2.5.4.97, der beispielsweise für Zertifikate benötigt wird, die zur eIDAS Verordnung konform sind.

Die Reihenfolge der Relative Distinguished Names (RDNs) im Subject Distinguished Name (DN) ausgestellter Zertifikate ändern

Microsoft Active Directory Certificate Services übernimmt Subjects aus Zertifikatanträgen für Vorlagen, in welchen dessen Angabe durch den Antragsteller erlaubt ist, nicht 1:1 in das ausgestellte Zertifikat.

Stattdessen ist sowohl definiert, welche Relative Distinguished Names (RDNs) erlaubt sind, als auch, in welcher Reihenfolge diese in ausgestellte Zertifikate geschrieben werden. Diese Reihenfolge kann allerdings verändert werden. Wie das gemacht wird, wird nachfolgend erläutert.

SSCEP für Linux (Debian Buster) installieren und Zertifikate über den Registrierungsdienst für Netzwerkgeräte (NDES) beantragen

Möchte man eine große Menge an Systemen mit Zertifikaten ausrüsten, ist eine manuelle Beantragung und Erneuerung der Zertifikate keine Option. Der einzige gangbare Weg ist Automatisierung.

Für Systeme, die nicht Mitglied der Active Directory Gesamtstruktur sind, ist eine automatische Zertifikatbeantragung über RPC/DCOM keine Option.

Für bestimmte Anwendungsfälle ist das Simple Certificate Enrollment Protocol (SCEP) eine interessante Alternative. Für dieses Protokoll gibt es nicht nur Clients für Windows, sondern mit SSCEP auch für Linux. SSCEP wird unter Anderem von Thin Clients mit dem eLux Betriebssystem verwendet.

Nachfolgend wird beschrieben, wie der SSCEP Client auf einem Debian Buster Linux System eingerichtet wird – entweder, um damit Server zu verwalten, oder das clientseitige Verhalten testen zu können.

Regelmäßige Passwortänderung bei Konfiguration des Registrierungsdienstes für Netzwerkgeräte (NDES) mit einem statischen Passwort

Angenommen, man betreibt einen Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES), welcher darauf konfiguriert ist, ein statisches Passwort zu verwenden. In diesem Fall ändert sich, im Gegensatz zur Standardkonfiguration, das Passwort für die Zertifikatbeantragung durch NDES-Clients niemals.

Vielleicht strebt man aber einen Zwischenweg an, beispielsweise eine tägliche Änderung des Passworts. Nachfolgend wird ein Weg beschrieben, wie die Änderung des Passworts automatisiert werden kann.

Zertifikatbeantragung für Windows-Systeme über den Registrierungsdienst für Netzwerkgeräte (NDES) mit Windows PowerShell

Möchte man Windows-Systeme mit Zertifikaten ausrüsten, welche nicht die Möglichkeit haben, direkt mit einer Active Directory integrierten Zertifizierungsstelle zu kommunizieren, oder die sich gar überhaupt nicht in der gleichen Active Directory Gesamtstruktur befinden, bleibt in den meisten Fällen nur die manuelle Installation von Zertifikaten.

Seit Windows 8.1 / Windows Server 2012 R2 befindet sich jedoch ein integrierter Client für das Simple Certificate Enrollment Protocoll (SCEP) an Bord. Serverseitig wird SCEP über den Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) in der Microsoft-PKI seit Windows Server 2003 implementiert.

Eine besonders interessante Eigenschaft von SCEP ist, dass das Protokoll eine Erneuerung eines Zertifikats unter Angabe eines bereits vorhandenen erlaubt. Was läge also näher, als diese Schnittstelle zu verwenden? Was noch fehlt, ist eine entsprechende Automatisierung über die Windows PowerShell.

Grundlagen Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES)

Das Simple Certificate Enrollment Protocol (SCEP) wurde in den frühen 2000er Jahren von Verisign für Cisco entwickelt, um eine vereinfachte Methode zum Beantragen von Zertifikaten verwenden zu können. Zuvor musste für Netzwerkgeräte manuell eine Zertifikatanforderung auf jedem Gerät erzeugt, zu einer Zertifizierungsstelle übermittelt und anschließend das ausgestellte Zertifikat wieder manuell auf dem entsprechenden Gerät installiert werden.

Beschreibung der verschiedenen Zertifikat-Formate

X.509 Zertifikate sind grundsätzlich im Distinguished Encoding Rules (DER) Format kodiert. Hierbei handelt es sich um ein binäres, maschinenlesbares Format.

DER-kodierte Zertifikate können jedoch mit dem BASE64 Verfahren auch in ein textbasiertes Format überführt werden, sodass sie beispielsweise in einem E-Mail Body übertragen werden können. BASE64 umschließt hierbei das DER-kodierte Format, d.h. das Zertifikat ist und bleibt in jedem Fall DER-kodiert.

Authentifizierung am Registrierungsdienst für Netzwerkgeräte (NDES) mit einem existierenden Zertifikat (Renewal-Modus)

Der Registrierungsdienst für Netzwerkgeräte (NDES) verfügt über die Möglichkeit, sich mit einem bereits ausgestellten Zertifikat zu authentifizieren, um ein inhaltlich gleiches Zertifikat erneut zu beantragen. Dies ist sehr praktisch für Erneuerungs-Operationen, da somit der Bedarf entfällt, vorher ein One-Time Passwort zu beantragen.