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)
„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)"“ weiterlesen

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.

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

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: Einsehen, welcher Algorithmus für eine S/MIME verschlüsselte oder signierte E-Mail verwendet wurde“ weiterlesen

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.

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

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“ weiterlesen

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).

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

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.

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

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.

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

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.

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

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.

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

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 32 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center“ weiterlesen

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.
„Details zum Ereignis mit ID 200 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center“ weiterlesen

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

Ereignisquelle:Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID:21 (0x80000015)
Ereignisprotokoll:System
Ereignistyp:Warnung
Ereignistext (englisch):The client certificate for the user %1\%2 is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they’re attempting to use for smartcard logon. The chain status was : %3
Ereignistext (deutsch):Das Clientzertifikat für den Benutzer %1\%2 ist nicht gültig. Das Ergebnis war ein Fehler bei der Smartcard-Anmeldung. Wenden Sie sich an den Benutzer, um weitere Informationen über das Zertifikat zu erhalten, das für die Smartcard-Anwendung verwendet werden soll. Kettenstatus: %3
„Details zum Ereignis mit ID 21 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center“ weiterlesen

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

Ereignisquelle:Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID:302 (0x12E)
Ereignisprotokoll:Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational
Ereignistyp:Information
Ereignistext (englisch):The Key Distribution Center (KDC) uses the below KDC certificate for smart card or certificate authentication. Kdc Certificate Information: Issuer Name: %1 Serial Number: %2 Thumbprint: %3 Template: %4
Ereignistext (deutsch):Das Schlüsselverteilungscenter (KDC) verwendet das folgende Zertifikat für die Smartcard- oder Zertifikatauthentifizierung. KDC-Zertifikatinformationen: Ausstellername: %1 Seriennummer: %2 Fingerabdruck: %3 Vorlage: %4
„Details zum Ereignis mit ID 302 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center“ weiterlesen

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

Ereignisquelle:Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID:19 (0x80000013)
Ereignisprotokoll:System
Ereignistyp:Warnung
Ereignistext (englisch):This event indicates an attempt was made to use smartcard logon, but the KDC is unable to use the PKINIT protocol because it is missing a suitable certificate.
Ereignistext (deutsch):Dieses Ereignis zeigt an, dass ein Versuch unternommen wurde, die Smartcard-Anmeldung zu verwenden, aber der KDC kann das PKINIT-Protokoll nicht verwenden, weil ein geeignetes Zertifikat fehlt.
„Details zum Ereignis mit ID 19 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center“ weiterlesen
de_DEDeutsch