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.
„(Neu-) Installieren der Microsoft Standard Zertifikatvorlagen“ weiterlesenKategorie: Zertifikat-Benutzung
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.
„Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus“ weiterlesenGrundlagen: 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.
„Grundlagen: Einschränken der erweiterten Schlüsselverwendung (Extended Key Usage, EKU) in Zertifizierungsstellen-Zertifikaten“ weiterlesenWelche 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.
„Welche Schlüssellängen sollten für Zertifizierungsstellen und Zertifikate verwendet werden?“ weiterlesenErzeugen 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:
„Erzeugen einer RFC 2818 konformen Zertifikatanforderung für SSL Zertifikate“ weiterlesenIf 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.
„Gerätevorlage für den Registrierungsdienst für Netzwerkgeräte (NDES) konfigurieren“ weiterlesenSecure Sockets Layer (SSL) für den Registrierungsdienst für Netzwerkgeräte (NDES) aktivieren
In der Standardkonfiguration nimmt der Network Device Enrollment Service (NDES) nur unverschlüsselte Verbindungen via HTTP an. Es ist angeraten, dass zumindest die Administrations-Webseite von NDES für HTTP über TLS (HTTPS) konfiguriert wird, um Mitschnitte des Netzwerkverkehrs zu erschweren. Nachfolgend eine Anleitung.
Für eine nähere Betrachtung zur Notwendigkeit der Verwendung von SSL siehe Artikel "Sollte HTTPS für den Registrierungsdienst für Netzwerkgeräte (NDES) verwendet werden?".
„Secure Sockets Layer (SSL) für den Registrierungsdienst für Netzwerkgeräte (NDES) aktivieren“ weiterlesenEigene Registration Authority (RA) Zertifikatvorlagen für den Registrierungsdienst für Netzwerkgeräte (NDES) verwenden
Der Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) verwendet zwei Zertifikatvorlagen für seine interne Funktion, um ihn als Registrierungsstelle (Registration Authority, RA) wirken zu lassen. Diese werden während der Rollenkonfiguration des NDES Dienstes auf der konfigurierten Zertifizierungsstelle veröffentlicht und Zertifikate werden beantragt:
- CEP Encryption
- Exchange Enrollment Agent (Offline Request)
Bei diesen Zertifikatvorlagen handelt es sich um Standardvorlagen aus der Windows 2000 Welt (Version 1 Vorlagen), d.h. sie können nicht bearbeitet werden. Darüber hinaus ist die Exchange Enrollment Agent (Offline Request) Vorlage als Benutzervorlage gekennzeichnet, d.h. während der NDES Rollenkonfiguration wird das Zertifikat im Kontext des installierenden Benutzers beantragt und anschließend in den Maschinenspeicher importiert. Spätestens, wenn die Zertifikate nach zwei Jahren erneuert werden sollen, wird es hier kompliziert.
Daher bietet es sich an, eigene Zertifikatvorlagen für NDES zu verwenden. Diese können beispielsweise in Hinsicht auf ihre Schlüssellänge angepasst werden. Auch die Verwendung von Hardware Security Modulen (HSM) ist auf diese Weise möglich. Sogar eine automatische Erneuerung kann konfiguriert werden.
„Eigene Registration Authority (RA) Zertifikatvorlagen für den Registrierungsdienst für Netzwerkgeräte (NDES) verwenden“ weiterlesenDomänencontroller überprüfen erweiterte Schlüsselverwendung (Extended Key Usage) bei Smartcard Anmeldung nicht
Wer die Smartcard Logon Funktion im Unternehmen verwenden möchte, ist gut beraten, für eine möglichst starke Sicherheitshärtung seiner Zertifizierungsstelle zu sorgen. Hierzu zählen einige essentielle Maßnahmen:
- Entfernen aller nicht notwendigen Zertifizierungsstellen-Zertifikate aus dem NTAuthCertificates Objekt im Active Directory: Jede Zertifizierungsstelle, welche sich in diesem Speicher befindet, ist im Active Directory für die komplette Gesamtstruktur für die Ausstellung von Smartcard Logon Zertifikaten berechtigt.
- Verwenden von qualifizierter Subordinierung: Einschränken der Zertifizierungsstellen-Zertifikate, sodass diesen nur für die tatsächlich ausgestellten Extended Key Usages vertraut wird. Im Fall einer Kompromittierung der Zertifizierungsstelle ist der Schaden dann auf diese Extended Key Usages beschränkt. Das "Smart Card Logon" Extended Key Usage wäre dann nur in dem Zertifizierungsstellen-Zertifikat derjenigen Zertifizierungsstelle, die auch tatsächlich solche Zertifikate ausstellt, vorhanden.
Interessant bei diesen Gedanken ist jedoch, dass die Domänencontroller bei der Anmeldung via Smartcard die Extended Key Usages überhaupt nicht überprüfen.
„Domänencontroller überprüfen erweiterte Schlüsselverwendung (Extended Key Usage) bei Smartcard Anmeldung nicht“ weiterlesenWelche Voraussetzungen müssen auf Infrastruktur-Seite erfüllt sein, damit Smartcard-Anmeldungen möglich sind?
Damit eine Smartcard Anmeldung erfolgreich ist, müssen in der Active Directory Umgebung einige Voraussetzungen erfüllt sein:
Entfernen der ADCS-spezifischen Erweiterungen aus Zertifikaten
Verwendet man Active Directory Certificates, fällt auf, dass in den Zertifikaten der Zertifizierungsstellen und den von ihnen ausgestellten Zertifikaten bestimmte Erweiterungen vorkommen, die nicht in den einschlägigen RFCs definiert und spezifisch für AD CS sind.
Benötigte Firewallregeln für Active Directory Certificate Services
Implementiert man eine Active Directory integrierte Zertifizierungsstelle, ist oft eine Planung der im Netzwerk zu erstellenden Firewallregeln erforderlich. Nachfolgend eine Aufstellung der benötigten Firewallregeln und eventueller Fallstricke.
„Benötigte Firewallregeln für Active Directory Certificate Services“ weiterlesenBeschreibung des Flags EDITF_ADDOLDKEYUSAGE
Wenn man eine untergeordnete Zertifizierungsstelle installiert, stößt man unter Umständen auf folgendes Verhalten:
- Man beantragt eine Key Usage Erweiterung, die beispielsweise als kritisch markiert ist, oder nicht DigitalSignature beinhaltet.
- Das von der übergeordneten Zertifizierungsstelle ausgestellte Zertifikat beinhaltet jedoch DigitalSignature, und die Key Usage Erweiterung ist als nicht-kritisch markiert.
- Bei der übergeordneten Zertifizierungsstelle handelt es sich um eine Standalone-Zertifizierungsstelle, d.h. ohne Active Directory Integration.
Wie sicher ist die Einstellung "Allow private key to be exported" in den Zertifikatvorlagen?
PKI-Administratoren gehen häufig davon aus, dass die Option in der Zertifikatvorlage , den privaten Schlüssel nicht zum Export zu erlauben, verbindlich ist.
„Wie sicher ist die Einstellung "Allow private key to be exported" in den Zertifikatvorlagen?“ weiterlesenImportieren eines Zertifikats in eine Smartcard
Manchmal ist es erforderlich, ein Zertifikat, welches einen Software-Schlüssel verwendet, in eine Smartcards zu importieren.
Deutsch 
English