Uwe Gradenegger – Seite 17 – Uwe Gradenegger

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle

Immer wieder kommt in Diskussionen zur Sicherheit einer Zertifizierungsstelle auf, dass ein Missbrauch der Zertifizierungsstelle durch deren Sicherheitseinstellungen eingedämmt werden könnte.

Dass die Integrität einer Zertifizierungsstelle jedoch unmittelbar an ihr Schlüsselmaterial gebunden ist und sie somit durch dieses auch kompromittiert werden kann, ist auf den Ersten Blick nicht offensichtlich.

Muss man sich die Zertifizierungsstellen-Software als eine Art Management um das Schlüsselmaterial herum vorstellen. Die Software bietet beispielsweise eine Online-Schnittstelle für die Zertifikatbeantragung an, kümmert sich um die Authentifizierung der Antragsteller, um die automatisierte Durchführung von Signaturoperationen (Ausstellen von Zertifikaten und Sperrlisten) und deren Protokollierung (Zertifizierungsstellen-Datenbank, Auditprotokoll, Ereignisprotokoll).

Signaturoperationen benötigen jedoch nichts weiter als den privaten Schlüssel der Zertifizierungsstelle. Nachfolgend wird anhand eines Beispiels aufgezeigt, wie ein Angreifer, wenn er Zugang zum privaten Schlüssel der Zertifizierungsstelle erhält, Zertifikate erzeugen und ausstellen kann, ohne dass die Zertifizierungsstellen-Software und deren Sicherheitsmechanismen dies mitbekommen würden.

Mit einem solchen Zertifikat wäre es im schlechtesten Fall sogar möglich, die Active Directory Gesamtstruktur unerkannt zu übernehmen.

Verschieben der Zertifizierungsstellen-Datenbank in ein anderes Verzeichnis oder auf ein anderes Laufwerk

Im Betrieb einer Zertifizierungsstelle mag man feststellen, dass es erforderlich ist, den Speicherpfad für die Zertifizierungsstellen-Datenbank nachträglich zu ändern. Beispielsweise möchte man die Datenbank vielleicht auf eine andere Partition/ein anderes Laufwerk verschieben.

Microsoft Outlook: Einsehen, welcher Algorithmus für eine S/MIME verschlüsselte oder signierte E-Mail verwendet wurde

Nachfolgend wird beschrieben, an welcher Stelle eingesehen werden kann, welcher symmetrische Algorihmus für die Verschlüsselung einer erhaltenen E-Mail verwendet wurde, und welcher Hashalgoritmus für eine signierte E-Mail verwendet wurde.

Microsoft Outlook: Den verwendeten Verschlüsselungsalgorithmus für S/MIME steuern

Stellt man S/MIME Zertifikate aus, beinhalten diese üblicherweise eine Zertifikaterweiterung "S/MIME Capabilities". Diese Zertifikaterweiterung ist in RFC 4262 spezifiziert und kann von kompatiblen E-Mail Programmen dazu verwendet werden, die vom Empfänger einer verschlüsselten Nachricht unterstützten symmetrischen Algorithmen zu spezifizieren. Der Absender sollte dann den jeweils stärksten vom Empfänger unterstützen Algorithmus wählen.

Microsoft Outlook verwendet (sofern vorhanden und erforderlich) die Informationen in der "S/MIME Capabilities" Erweiterung eines Zertifikats. Nachfolgend wird beschrieben, auf welche Weise die Verwendung erfolgt, und welche Algorihmen ausgewählt werden.

Die "S/MIME Capabilities" Zertifikaterweiterung

Stellt man S/MIME Zertifikate aus, beinhalten diese üblicherweise eine Zertifikaterweiterung "S/MIME Capabilities". Diese Zertifikaterweiterung ist in RFC 4262 spezifiziert und kann von kompatiblen E-Mail Programmen dazu verwendet werden, die vom Empfänger einer verschlüsselten Nachricht unterstützten symmetrischen Algorithmen zu spezifizieren. Der Absender sollte dann den jeweils stärksten vom Empfänger unterstützen Algorithmus wählen.

Unter Anderem wird die Erweiterung von Microsoft Outlook ausgewertet und verwendet, um den symmetrischen Algorithmus für eine verschlüsselte E-Mail zu bestimmen.

Die "S/MIME Capabilities" Zertifikaterweiterung in ausgestellten Zertifikaten um die Cryptography Next Generation (CNG) Algorithmen erweitern

Stellt man S/MIME Zertifikate aus, beinhalten diese üblicherweise eine Zertifikaterweiterung "S/MIME Capabilities". Diese Zertifikaterweiterung ist in RFC 4262 spezifiziert und kann von kompatiblen E-Mail Programmen dazu verwendet werden, die vom Empfänger einer verschlüsselten Nachricht unterstützten symmetrischen Algorithmen zu spezifizieren. Der Absender sollte dann den jeweils stärksten vom Empfänger unterstützen Algorithmus wählen.

Wirft man einen Blick auf die in einem solchen Zertifikat enthaltenen symmetrischen Algorithmen, wird man jedoch vermutlich feststellen, dass die Liste eher veraltete Algorithmen enthält – der "stärkste" dieser Algorithmen ist der mittlerweile als übrholt geltende Triple-DES (3DES).

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.

Deutsch