Zertifikat-Benutzung – Seite 14 – Uwe Gradenegger

Beantragen eines durch ein Trusted Platform Modul (TPM) geschütztes Zertifikat – ohne ein TPM zu besitzen

Seit Windows 8 ist es möglich, dass private Schlüssel für Zertifikate mit einem – sofern vorhanden – Trusted Platform Modul (TPM) geschützt werden. Dadurch ist eine Nichtexportierbarkeit des Schlüssels – auch mit Werkzeugen wie mimikatz – gegeben.

Auf den Ersten Blick ist allerdings nicht ersichtlich, dass nicht garantiert werden kann, dass auch wirklich ein TPM zum Einsatz kommt. Zwar wird keine Beantragung über die Microsoft Management Console oder AutoEnrollment möglich sein, wenn der Computer über kein TPM verfügt.

Es handelt sich jedoch bei der Konfiguration in der Zertifikatvorlage lediglich um eine Voreinstellung für den Client. Die Zertifizierungsstelle wird bei Beantragung nicht explizit prüfen, ob auch wirklich ein Trusted Platform Modul verwendet wurde.

Somit können – wenn die Zertifikatbeantragung abseits der MMC erfolgt, beliebige Parameter für den privaten Schlüssel verwendet werden.

Die Beantragung eines Zertifikats ist nicht möglich, da die Zertifikatvorlage nicht angezeigt wird. Die Fehlermeldung lautet "Can not find a valid CSP in the local machine."

Folgendes Szenario angenommen:

Es wird für einen Benutzer oder einen Computer ein Zertifikat von einer Zertifizierungsstelle über die Verwaltungskonsole für Zertifikate (certlm.msc oder certmgr.msc) beantragt.
Autoenrollment beantragt kein Zertifikat von der gewünschten Zertifikatvorlage, obwohl es aktiviert ist und die Berechtigungen entsprechend gesetzt sind.
Die gewünschte Zertifikatvorlage wird bei manueller Beantragung über die Microsoft Management Konsole (MMC) nicht angezeigt. Aktiviert man das Kontrollkästchen "Show all templates", wird für die gewünschte Zertifikatvorlage folgende Fehlermeldung angezeigt:

Cannot find object or property.
Can not find a valid CSP in the local machine.

Konfigurieren einer Zertifikatvorlage für die Verwendung des Microsoft Platform Crypto Provider, um Schutz des privaten Schlüssels durch ein Trusted Platform Module (TPM) zu ermöglichen

Seit Windows 8 ist es möglich, dass private Schlüssel für Zertifikate mit einem – sofern vorhanden – Trusted Platform Modul (TPM) geschützt werden. Dadurch ist eine echte Nichtexportierbarkeit des Schlüssels gegeben.

Nachfolgend wird der Prozess zur Einrichtung einer Zertifikatvorlage, die ein Trusted Platform Modul verwendet, beschrieben.

Die Beantragung eines Trusted Platform Module (TPM) geschützten Zertifikats schägt fehl mit Fehlermeldung "The requested operation is not supported. 0x80090029 (-2146893783 NTE_NOT_SUPPORTED)"

Folgendes Szenario angenommen:

Es ist eine Zertifikatvorlage für die Verwendung des Microsoft Platform Crypto Provider konfiguriert, sodass der bei der Beantragung des Zertifikats erzeugte private Schlüssel mit einem Trusted Platform Module (TPM) geschützt ist.
Die Beantragung von Zertifikaten schlägt jedoch mit folgender Fehlermeldung fehl:

An error occurred while enrolling for a certificate.
A certificate request could not be created.
Url: CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1
Error: The requested operation is not supported. 0x80090029 (-2146893783 NTE_NOT_SUPPORTED)

Google Chrome und Microsoft Edge prüfen Sperrstatus von Zertifikaten nicht

Immer mehr Unternehmen setzen als Standardbrowser auf der Windows-Plattform den Google Chrome Browser oder den neuen auf Chromium basierenden Microsoft Edge (Codename Anaheim) ein.

Bei der Verteilung eines dieser beiden Browser sollte beachtet werden, dass sie sich in Hinsicht auf Zertifikate teils abweichend zu andere Browsern verhalten.

Nebst der Tatsache, dass Chromium im Gegensatz zum Internet Explorer und dem vorigen Edge (Codename Spartan) das RFC 2818 erzwingt, verhält er sich auch bei der Prüfung von Sperrinformationen anders.

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.

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.

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.

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.

Details zum Ereignis mit ID 32 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center

Ereignisquelle:	Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID:	32 (0x80000020)
Ereignisprotokoll:	System
Ereignistyp:	Warnung
Ereignistext (englisch):	The Key Distribution Center (KDC) uses a certificate without KDC Extended Key Usage (EKU) which can result in authentication failures for device certificate logon and smart card logon from non-domain-joined devices. Enrollment of a KDC certificate with KDC EKU (Kerberos Authentication template) is required to remove this warning.
Ereignistext (deutsch):	Vom Schlüsselverteilungscenter (Key Distribution Center, KDC) wird ein Zertifikat ohne erweiterte Schlüsselverwendung (Extended Key Usage, EKU) für das KDC verwendet. Dies kann bei Gerätezertifikatanmeldungen und Smartcardanmeldungen von Geräten ohne Domänenzugehörigkeit zu Authentifizierungsfehlern führen. Die Registrierung eines KDC-Zertifikats mit KDC-EKU (Kerberos-Authentifizierungsvorlage) ist erforderlich, um diese Warnung zu beseitigen.

Details zum Ereignis mit ID 200 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center

Ereignisquelle:	Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID:	200 (0xC8)
Ereignisprotokoll:	Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational
Ereignistyp:	Warnung
Ereignistext (englisch):	The Key Distribution Center (KDC) cannot find a suitable certificate to use. This KDC is not enabled for smart card or certificate authentication.
Ereignistext (deutsch):	Das Schlüsselverteilungscenter (KDC) kann kein geeignetes Zertifikat finden. Dieses KDC ist nicht für die Smartcard- oder Zertifikatauthentifizierung aktiviert.

Deutsch