Schlagwort: Subject Alternative Name (SAN)

„Details zum Ereignis mit ID 53 der Quelle Microsoft-Windows-CertificationAuthority“ weiterlesen

„Details zum Ereignis mit ID 22 der Quelle Microsoft-Windows-CertificationAuthority“ weiterlesen

„Details zum Ereignis mit ID 30 der Quelle Microsoft-Windows-NetworkDeviceEnrollmentService“ weiterlesen

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

Auch bei einer vermeintlich simpel zu konfigurierenden Zertifikatvorlage für Domänencontroller gibt es einiges zu beachten.

„Konfigurieren einer Zertifikatvorlage für Domänencontroller“ weiterlesen

Nachfolgend wird beschrieben, welche Schritte erforderlich sind, um den Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) für die Verwendung mit einem Alias zu konfigurieren.

„Den Network Device Enrollment Service (NDES) für die Verwendung mit einem Alias konfigurieren“ weiterlesen

Es gibt Fälle, in welchen man Remotedesktop-Zertifikate nicht von einer Zertifizierungsstelle in der eigenen Active Directory Gesamtstruktur beziehen kann oder möchte, beispielsweise wenn das betreffende System kein Domänenmitglied ist.

In diesem Fall ist die Verwendung von Zertifikatvorlagen nicht möglich, und man muss manuell einen Zertifikatantrag (Certificate Signing Request, CSR erstellen).

„Manuelle Beantragung eines Remotedesktop (RDP) Zertifikats“ weiterlesen

Folgendes Szenario angenommen:

• Es werden Zertifikate für Domänencontroller von einer Active Directory integrierten Zertifizierungsstelle (Enterprise CA) ausgestellt
• Die hierfür verwendete Zertifikatvorlage wurde selbst erzeugt
• Die ausgestellten Zertifikate enthalten im Subject Alternative Name (SAN) nur den vollqualifizierten Computernamen des jeweiligen Domänencontrollers, jedoch nicht den vollqualifizierten Namen und den NETBIOS Namen der Domäne

„Zertifikate für Domänencontroller enthalten nicht den Domänennamen im Subject Alternative Name (SAN)“ weiterlesen

Grundsätzlich erlaubt das RFC 5280 die Verwendung beliebiger Zeichenketten im Subject Distinguished Name (DN) eines Zertifikats. Gängige Felder sind im Standard X.520 beschrieben. Die Längenbeschränkungen werden ebenfalls von der ITU-T empfohlen . Die heute gängigen Abkürzungen entstammen überwiegend dem RFC 4519 .

Die Microsoft Active Directory Certificate Services erlauben in der Standardeinstellung jedoch nur bestimmte RDNs.

Folgende Relative Distinguished Names (RDNs) werden in der Standardeinstellung von der Active Directory Certificate Services (ADCS) Zertifizierungsstelle angenommen:

„Erlaubte Relative Distinguished Names (RDNs) im Subject Distinguished Name (DN) ausgestellter Zertifikate“ weiterlesen

Oft möchte man eine Zertifikatanforderung vor der Übermittlung an eine Zertifizierungsstelle - oder vor der Ausstellung des Zertifikats - überprüfen, ob sie die gewünschten Werte beinhaltet.

Nachfolgend wird beschrieben, wie man dies erreichen kann.

„Eine Zertifikatanforderung (CSR) inspizieren“ weiterlesen

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

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

„Erzeugen einer RFC 2818 konformen Zertifikatanforderung für SSL Zertifikate“ weiterlesen

Im Netz kursieren leider viel zu viele Anleitungen (auch die großen Player sind hiervon nicht ausgenommen , nicht einmal Microsoft selbst oder der Großmeister Komar ), welche fatalerweise empfehlen, dass das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 auf der Zertifizierungsstelle gesetzt werden sollte - angeblich damit man in der Lage wäre, für manuell gestellte Zertifikatanforderungen Zertifikate mit Subject Alternative Name (SAN) Erweiterung ausstellen zu können.

Leider ist diese Vorgehensweise nicht nur unnötig, sie hat auch einige unangenehme Nebenwirkungen, welche einem Angreifer im schlechtesten Fall dazu verhelfen können, die gesamte Active Directory Gesamtstruktur zu übernehmen.

„Gefährdung der Active Directory Gesamtstruktur durch das Flag EDITF_ATTRIBUTESUBJECTALTNAME2“ weiterlesen

Es gibt Fälle, in welchen man Domain Controller Zertifikate nicht von einer Zertifizierungsstelle in der eigenen Active Directory Gesamtstruktur beziehen kann oder möchte.

In diesem Fall ist die Verwendung von Zertifikatvorlagen nicht möglich, und man muss manuell einen Zertifikatantrag (Certificate Signing Request, CSR erstellen).

„Manuelle Beantragung eines Domänencontroller-Zertifikats“ weiterlesen