Zertifikat-Benutzung – Uwe Gradenegger

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) beim Etablieren digitaler Signaturprozesse im Unternehmen helfen kann

Viele Unternehmen möchten heutzutage auf papierlose Prozesse setzen, um interne Genehmigungs- und Signaturprozesse zu beschleunigen. In Zeiten, in denen die meisten Mitarbeiter von Zuhause aus arbeiten hat dies noch einmal zusätzlich an Bedeutung gewonnen.

Obwohl die Microsoft Zertifizierungsstelle in der Lage ist, automatische Zertifikatausstellungsprozesse umzusetzen, sind ihre Möglichkeiten, hierbei Einfluss auf den Zertifikatinhalt zu nehmen stark limitiert.

Das TameMyCerts Policy Modul für Microsoft Active Directory Certificate Services (AD CS) erlaubt das Definieren erweiterter Regeln für den Subject Distinguished Name und auch den Subject Alternative Name ausgestellter Zertifikate.

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) eingehende Zertifikatanträge reparieren kann, um sie RFC-konform zu machen

Beginnend mit Version 58 hat Google beschlossen, im Chrome Browser die Unterstützung für den Subject Distinguished Name von Webserver-Zertifikaten zu entfernen und stattdessen nur noch Zertifikate mit Subject Alternative Name zu akzeptieren.

Seit diesem Moment werden Webserver-Zertifikate ohne Subject Alternative Name in Form eines dNSName von Chrome abgelehnt. Andere Browserhersteller haben diesen Ansatz schnell übernommen, sodass dieses Problem mittlerweile alle gängigen Browser (auch Microsoft Edge) betrifft.

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) Angriffe gegen den ESC1 Angriffsvektor verhindern kann

Angriffe auf Microsoft Zertifizierungsstellen können auf das Ausnutzen von Berechtigungen auf Zertifikatvorlagen abzielen. In vielen Fällen müssen Zertifikatvorlagen konfiguriert werden, dem Antragsteller das Recht einzuräumen, beliebige Identitäten beantragen zu können. Dies kann zur Übernehme der Identitäten von Active Directory Konten und in Folge zur Erhöhung von Rechten durch den Angreifer führen. Angriffe dieser Art werden in der Security Szene These als "ESC1" bezeichnet.

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) Angriffe gegen die ESC6 und ESC7 Angriffsvektoren erkennen und verhindern kann

In der vermeintlich guten Absicht, damit die Ausstellung solcher Zertifikatanforderungen mit einem SAN möglich zu machen, raten leider viel zu viele Anleitungen dazu, auf der Zertifizierungsstelle das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 zu aktivieren.

Aktiviert man dieses Flag, wird eine sehr große Angriffsfläche geboten, da nun jeder Antragsteller die Zertifizierungsstelle anweisen kann, Zertifikate mit beliebigen Inhalten auszustellen. Diese Art von Agriffen ist in der Security-Szene als ESC6 und ESC7 bekannt.

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) dabei helfen kann, Szenarien mit Microsoft Intune und anderen Mobile Device Management (MDM) Systemen abzusichern

Unternehmen verwenden Mobile Device Management (MDM) Produkte um mobile Geräte wie Smartphones, Tablet-Computer oder Desktopsysteme über das Internet (Over-the-Air, OTA) zu verwalten, zu konfigurieren und zu aktualisieren.

Gängige Mobile Device Management Produkte sind:

Microsoft Intune
VMware Workspace One (previously known as AirWatch)
Ivanti MobileIron UEM
Jamf Pro
Baramundi Enterprise Mobility Management
BlackBerry Enterprise Mobility Suite
Sophos Mobile Control
SOTI MobiControl

DNS-Namen automatisch in den Subject Alternate Name (SAN) ausgestellter Zertifikate eintragen – mit dem TameMyCerts Policy Modul für Microsoft Active Directory Certificate Services (ADCS)

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 dieses 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

Den Subject Alternative Name (SAN) eines Zertifikats vor dessen Ausstellung verändern – aber sicher!

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

Konfigurieren einer Zertifikatvorlage für Onlineresponder (OCSP) Antwortsignatur-Zertifikate

Für die Verwendung des Online Certificate Status Protocol (OCSP) ist es erforderlich, eine entsprechende Zertifikatvorlage zu konfigurieren.

Das Senden von S/MIME verschlüsselten Nachrichten mit Outlook for iOS ist nicht möglich: "There’s a problem with one of your S/MIME encryption certificates."

Folgendes Szenario angenommen:

Die Zertifikate wurden über den Intune Connector auf das Smartphone übertragen.
Das lesen verschlüsselter Nachrichten funktioniert.
Beim Aktivieren der Verschlüsselung für ausgehende Nachrichten wird jedoch folgende Fehlermeldung angezeigt:

There's a problem with one of your S/MIME encryption certificates. Contact your IT help desk for more info.

Es gibt ein Problem mit einem ihrer S/MIME-Verschlüsselungszertifikate. Wenden Sie sich für weitere Informationen an Ihren IT-Helpdesk.

Anmeldungen über den Netzwerkrichtlinienserver (engl. Network Policy Server, NPS) scheitern mit Grund "Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect."

Folgendes Szenario angenommen:

Es wird eine zertifikatbasierte Anmeldung mit Benutzer- oder Computerkonten vorgenommen, um diese an einem drahtlosen (IEEE 802.11 oder Wireless LAN) oder verkabelten Netzwerk (IEEE 802.3), oder eine Remote Access Verbindung (z.B. DirectAccess, Routing and Remote Access (RAS), Always on VPN) anzumelden.
Das Unternehmen verwendet als Server für Authentifizierung, Autorisierung und Accounting (AAA) den Netzwerkrichtlinienserver (engl. Network Policy Server NPS) von Microsoft.
Die Anmeldung am Netzwerk ist nicht mehr möglich.
Der Netzwerkrichtlinienserver protokolliert das folgende Ereignis, wenn ein Anmeldeversuch unternommen wird:

Network Policy Server denied access to a user. [...] Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

Der Netzwerkrichtlinienserver hat einem Benutzer den Zugriff verweigert. [...] Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch.

Nachträgliche Archivierung privater Schlüssel

Für die Veschlüsselung von E-Mail Nachrichten verwenden Unternehmen üblicherweise den Secure / Multipurpose Internet Message Extensions (S/MIME) Standard und stellen ihren Benutzern hierfür entsprechende Zertifikate zur Verfügung.

Ein wichtiger Aspekt hierbei ist, dass die privaten Schlüssel der Benutzer – im Gegensatz zu den ansonsten meist verwendeten Signaturzertifikaten – zentral gesichert werden sollten. Eingehende Nachrichten sind für einen bestimmten privaten Schlüssel verschlüsselt und können nur von diesem auch wieder entschlüsselt werden. Somit muss unbedingt eine Sicherung dieser Schlüssel vorliegen – auch für die Synchronisierung auf mobile Endgeräte ist dies unabdingbar. Hierfür bieten die Microsoft Active Directory Certificate Services die Funktion der Archivierung privater Schlüssel (engl. Private Key Archival).

Was aber, wenn die Archivierung der privaten Schlüssel nicht eingerichtet wurde, und Benutzer bereits entsprechende Zertifikate beantragt haben?

Beantragung von Zertifikaten für mit Microsoft Intune verwaltete Endgeräte

In einer vernetzen Welt ist es mittlerweile zum Standard geworden, von überall zu arbeiten, und auch neben klassischen Desktopcomputern mit mobilen Endgeräten wie Smartphones oder Tablets zu arbeiten. Solche Endgeräte werden üblicherweise mittels Mobile Device Management (MDM) Systemen wie Microsoft Intune verwaltet.

Um Zugriff auf Unternehmensressourcen zu erhalten, benötigen die Benutzer mobiler Endgeräte in den meisten Fällen digitale Zertifikate, um ihre Identität unter Beweis stellen zu können. Somit ist es erforderlich, diesen Geräten eine automatisierbare und dennoch sichere Schnittstelle für die Beantragung dieser Zertifikate bereitzustellen.

Übertragen von S/MIME Zertifikaten zu Microsoft Intune

In einer modernen vernetzten Welt ist die vertrauliche Übermittlung von Nachrichten im Unternehmensumfeld essentiell für geschäftlichen Erfolg. Trotz ihres Alters ist die E-Mail weiterhin aus der modernen Unternehmenskommunikation nicht wegzudenken. Ihre Nutzung hat sich im Lauf der Jahrzehnte allerdings deutlich gewandelt.

So ist es heutzutage üblich, geschäftliche E-Mails auch auf mobilen Endgeräten wie Smartphones und Tablets lesen und schreiben zu können. Solche Endgeräte werden üblicherweise mittels Mobile Device Management (MDM) Systemen wie Microsoft Intune verwaltet.

Für die Veschlüsselung von E-Mail Nachrichten verwenden Unternehmen üblicherweise den Secure / Multipurpose Internet Message Extensions (S/MIME) Standard und stellen ihren Benutzern hierfür entsprechende Zertifikate zur Verfügung. Wie kommen diese nun in skalierbarer Weise auf die Endgeräte der Benutzer?

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

Ereignisquelle:	Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID:	41 (0x80000029)
Ereignisprotokoll:	System
Ereignistyp:	Warnung oder Fehler
Ereignistext (englisch):	The Key Distribution Center (KDC) encountered a user certificate that was valid but contained a different SID than the user to which it mapped. As a result, the request involving the certificate failed. See https://go.microsoft.com/fwlink/?linkid=2189925 to learn more. User: %1 User SID: %2 Certificate Subject: %3 Certificate Issuer: %4 Certificate Serial Number: %5 Certificate Thumbprint: %6 Certificate SID: %7
Ereignistext (deutsch):	Der Schlüsselverteilungscenter (KDC) hat ein gültiges Benutzerzertifikat gefunden, das jedoch eine andere SID enthielt als der Benutzer, dem es zugeordnet ist. Dies hat zur Folge, dass bei der Anforderung, die das Zertifikat betrifft, ein Fehler aufgetreten ist. Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2189925. Benutzer: %1 Benutzer-SID: %2 Zertifikatantragsteller: %3 Zertifikataussteller: %4 Seriennummer des Zertifikats: %5 Zertifikatfingerabdruck: %6 Zertifikat-SID: %7

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

Ereignisquelle:	Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID:	40 (0x80000028)
Ereignisprotokoll:	System
Ereignistyp:	Warnung oder Fehler
Ereignistext (englisch):	The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID). The certificate also predated the user it mapped to, so it was rejected. See https://go.microsoft.com/fwlink/?linkid=2189925 to learn more. User: %1 Certificate Subject: %2 Certificate Issuer: %3 Certificate Serial Number: %4 Certificate Thumbprint: %5 Certificate Issuance Time: %6 Account Creation Time: %7
Ereignistext (deutsch):	Der Schlüsselverteilungscenter (KDC) hat ein gültiges Benutzerzertifikat gefunden, das jedoch keinem Benutzer auf sichere Weise zugeordnet werden konnte (z. B. über eine explizite Zuordnung, eine Schlüsselvertrauenszuordnung oder eine SID). Das Zertifikat hat auch dem Benutzer vorangestellt, dem es zugeordnet ist, weshalb es abgelehnt wurde. Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2189925. Benutzer: %1 Zertifikatantragsteller: %2 Zertifikataussteller: %3 Zertifikatseriennummer: %4 Zertifikatfingerabdruck: %5 Zertifikatausstellungszeit: %6 Erstellungszeit des Kontos: %7

Deutsch