Zertifikat-Benutzung – Seite 19 – Uwe Gradenegger

Die Ausstellungsrichtlinien (Issuance Policies) für Trusted Platform (TPM) Key Attestation in ein Zertifizierungsstellen-Zertifikat aufnehmen

Installiert man eine ausstellende Zertifizierungsstelle (Issuing CA) und beantragt nicht explizit eine Ausstellungsrichtlinie (Issuance Policy) beinhaltet das resultierende Zertifizierungsstellen-Zertifikat keine Ausstellungsrichtlinien.

Möchte man die Ausstellungsrichtlinien (Issuance Policies) für Trusted Platform (TPM) Key Attestation in das Zertifizierungsstellen-Zertifikat aufnehmen, muss wie folgt vorgegangen werden.

Ermitteln und Exportieren eines Trusted Platform Module (TPM) Endorsement Zertifikats

Möchte man die Trusted Platform Module (TPM) Key Attestation verwenden, hat man die Option, das TPM unter Anderem über das Endorsement-Zertifikat (EkCert) zu attestieren. Nachfolgend wird beschrieben, wie man an diese Information herankommt.

Die Prüfsumme (Hash) eines Trusted Platform (TPM) Endorsement Key ermitteln

Möchte man die Trusted Platform Module (TPM) Key Attestation verwenden, hat man die Option, das TPM unter Anderem über den Endorsement-Key (EkPub) zu attestieren. Nachfolgend wird beschrieben, wie man an diese Information herankommt.

Häufig verwendete erweiterte Schlüsselverwendungen (Extended Key Usages) und Ausstellungsrichtlinien (Issuance Policies)

Nachfolgend eine Auflistung von häufig genutzten erweiterten Schlüsselverwendungen (Extended Key Usage) und Ausstellungsrichtlinien (Issuance Policies), die in der Praxis immer wieder verwendet werden, um Zertifizierungsstellenzertifikate zu beschränken.

Die Anmeldung via Smartcard schlägt fehl mit Fehlermeldung "The revocation status of the authentication certificate could not be determined."

Folgendes Szenario angenommen:

Ein Benutzer verfügt über ein Smartcard Logon Zertifikat und meldet sich mit diesem an der Active Directory Domäne an.
Die Anmeldung schlägt fehl. Folgende Fehlermeldung wird dem Benutzer an seinem Computer zurückgegeben:

The revocation status of the authentication certificate could not be determined.

Die Registration Authority (RA) Zertifikate für den Registrierungsdienst für Netzwerkgeräte (NDES) erneuern

Ist NDES einige Zeit in Betrieb (typischerweise zwei Jahre), steht man vor der Herausforderung, die Registration Authority (RA) Zertifikate zu erneuern. Dieser Prozess ist leider nicht unbedingt intuitiv gelöst und wird daher in diesem Artikel näher beschrieben.

Der Registrierungsdienst für Netzwerkgeräte (NDES) protokolliert die Fehlermeldung "The Network Device Enrollment Service cannot retrieve one of its required certificates (0x80070057). The parameter is incorrect."

Folgendes Szenario angenommen:

Ein NDES Server ist im Netzwerk konfiguriert.
Bei Aufruf der NDES-Beantragungs-Webseite (mscep) und der NDES-Administrations-Webseite (certsrv/mscep_admin) wird der HTTP-Fehler 500 (Internal Server Error) gemeldet.
Es werden die Ereignisse Nr. 2 und 10 im Anwendungs-Ereignisprotokoll hinterlegt:

The Network Device Enrollment Service cannot be started (0x80070057). The parameter is incorrect.

The Network Device Enrollment Service cannot retrieve one of its required certificates (0x80070057). The parameter is incorrect.

Erstellen einer virtuellen Smartcard in einem Hyper-V Gastsystem

Für Testumgebungen ist es oft hilfreich, mit Smartcards arbeiten zu können. Nachfolgend eine kurze Anleitung, wie eine virtuelle Smartcard in einem Hyper-V Gast mit Hilfe eines virtualisierten Trusted Platform Moduls (TPM) eingerichtet werden kann.

Domänencontroller-Zertifikatvorlagen und Smartcard Anmeldung

Damit Domänencontroller Smartcard Anmeldungen verarbeiten können, benötigen sie Zertifikate, welche diese Funktion bereitstellen.

(Neu-) Installieren der Microsoft Standard Zertifikatvorlagen

Es kann Fälle geben, in welchen es notwendig ist, die Standard Microsoft-Zertifikatvorlagen zu installieren, bevor die erste Active Directory integrierte Zertifizierungsstelle (Enterprise Certification Authority) installiert wird, oder die Vorlagen neu zu installieren, beispielsweise weil sie beschädigt oder anderweitig verändert wurden.

Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus

Vereinfacht ausgedrückt kann man Public Key Kryptographie auf die Annahme reduzieren, dass der private Teil eines jeden Schlüsselpaares nur dessen Inhaber bekannt ist.

Eine Zertifizierungsstelle ist für die korrekte Identifikation von Benutzern, Computern oder Ressourcen zuständig. Ihren ausgestellten Zertifikaten wird deshalb ein Vertrauensstatus eingeräumt, weil alle Teilnehmer der Annahme sind, dass ihr privater Schlüssel nur ihr bekannt ist.

Gelingt es einem Angreifer, Kenntnis des privaten Schlüssels einer Zertifizierungsstelle zu erlangen, oder zumindest Signaturen mittels des privaten Schlüssels durchzuführen, ist die Integrität der Zertifizierungsstelle nicht länger gewährleistet.

Grundlagen: Einschränken der erweiterten Schlüsselverwendung (Extended Key Usage, EKU) in Zertifizierungsstellen-Zertifikaten

Eine sinnvolle Härtungsmaßnahme für Zertifizierungsstellen ist das Einschränken der Zertifizierungsstellen-Zertifikate, sodass diesen nur für die tatsächlich ausgestellten erweiterten Schlüsselverwendungen (Extended Key Usage) vertraut wird.

Im Fall einer Kompromittierung der Zertifizierungsstelle ist der Schaden dann (immerhin) auf die definierten Extended Key Usages beschränkt.

Das für viele Angriffe interessante Smart Card Logon Extended Key Usage (in Verbindung mit der Mitgliedschaft der Zertifizierungsstelle in NTAuthCertificates) wäre dann nur in dem Zertifizierungsstellen-Zertifikat derjenigen Zertifizierungsstelle, die auch tatsächlich solche Zertifikate ausstellt, vorhanden.

Welche Schlüssellängen sollten für Zertifizierungsstellen und Zertifikate verwendet werden?

Bei der Planung einer Public Key Infrastruktur kommt naturgemäß die Frage auf, welche Schlüssellängen für Zertifizierungsstellen- und Endzertifikate gewählt werden sollten.

Erzeugen einer RFC 2818 konformen Zertifikatanforderung für SSL Zertifikate

Google ist mit dem Chromium Projekt und darauf basierenden Produkten wie Google Chrome und Microsoft Edge dazu übergegangen, das im Jahr 2000 verabschiedete RFC 2818 zu erzwingen und Zertifikaten nicht mehr zu vertrauen, welche das RFC nicht mehr erfüllen.

Für uns ist folgender Satz von großer Brisanz:

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead
https://tools.ietf.org/html/rfc2818

Gerätevorlage für den Registrierungsdienst für Netzwerkgeräte (NDES) konfigurieren

In der Standardeinstellung beantragt der Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) Zertifikate von der Vorlage "IPsec (Offline Request)". Diese Zertifikatvorlage stammt aus Windows 2000 Zeiten und kann nicht bearbeitet werden. Darum ist es empfehlenswert, die Standardeinstellungen zu verändern und eigene Zertifikatvorlagen zu verwenden, die die persönlichen Anforderungen bedienen.

Deutsch