Uwe Gradenegger – Passionate about PKI

Empfohlen

Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für die Microsoft Zertifizierungsstelle

Als Betreiber einer Zertifizierungsstelle ist man (unter Anderem) für die Identifikation der Antragsteller und die Bestätigung der beantragten Identitäten verantwortlich. Dass diese Aufgabe gewissenhaft und fehlerfrei ausgeführt wird, ist der zentrale Grundpfeiler für das Vertrauen, dass der Zertifizierungsstelle eingeräumt wird. Namhafte Firmen sind bereits an dieser Aufgabe gescheitert, mussten in Folge von Falschausstellungen sogar Insolvenz anmelden und/oder wurden durch die großen Player am Markt empfindlich bestraft.

In vielen Fällen sind wir als (Microsoft-)PKI-Betreiber in Unternehmen (ungeachtet der damit einhergehenden Qualität) in der Lage, unsere Aufgabe der eindeutigen Identifikation eines Antragstellers an das Active Directory zu delegieren. In vielen Fällen müssen wir unsere Zertifizierungsstelle(n) aber auch anweisen, einfach alles auszustellen, was beantragt wird.

Empfohlen

Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)

Mit dem Patch vom 10. Mai 2022 versucht Microsoft, eine Sicherheitslücke im Active Directory zu schließen, in welcher die zertifikatbasierte Anmeldung (im Allgemeinen bekannt als PKINIT oder auch Smartcard Logon) zu schließen.

Das Update ändert sowohl das Verhalten der Zertifizierungsstelle als auch das Verhalten des Active Directory beim Verarbeiten von zertifikatbasierten Anmeldungen.

Empfohlen

Es wird Zeit: Migrieren der PKI Komponenten von Windows Server 2012 auf ein neues Betriebssystem

Zum Jahreswechsel ein Hinweis an alle Betreiber einer Microsoft Zertifizierungsstelle und angeschlossener Dienste:

Das Ende der Produktunterstüzung von Microsoft für Windows Server 2012 und 2012 R2 rückt langsam näher, es ist der 10. Oktober 2023.

Es wird somit Zeit, den Umzug auf ein neues Betriebssystem vorzubereiten.

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.

Keine Installation des Registrierungsdienstes für Netzwerkgeräte (NDES) an einem Standort mit nur schreibgeschützten Domänencontrollern möglich

Folgendes Szenario angenommen:

Es soll ein Registrierungsdienst für Netzwerkgeräte (NDES) im Netzwerk implementiert werden.
Am Active Directory-Standort des NDES-Servers befinden sich nur schreibgeschützte Domänencontroller (engl. Read Only Domain Controller, RODC).
Die Konfiguration der NDES-Rolle schlägt mit folgender Fehlermeldung fehl:

Failed to add the following certificate templates to the enterprise Active Directory Certificate Service or update security settings on those templates:
EnrollmentAgentOffline 
CEPEncryption
IPSEC(Offline request)
A referral was returned from the server. 0x8007202b (WIN32:8235 ERROR_DS_REFERRAL)

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?

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle – allein mit Bordmitteln

Im Artikel "Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle" habe ich beschrieben, wie sich ein Angreifer, der im Besitz administrativer Rechte auf der Zertifizierungsstelle ist, unter Umgehung der Zertifizierungsstellen-Software, also unter direkter Verwendung des privaten Schlüssels der Zertifizierungsstelle, ein Anmeldezertifikat für administrative Konten der Domäne erzeugen kann.

Im vorigen Artikel habe ich das PSCertificateEnrollment Powershell Modul verwendet, um das Vorgehen zu demonstrieren. Microsoft liefert mit certreq und certutil allerdings bereits ab Werk perfekt geeignete Pentesting-Werkzeuge direkt mit dem Betriebssystem mit.

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

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

Ereignisquelle:	Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID:	39 (0x80000027)
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). Such certificates should either be replaced or mapped directly to the user via explicit mapping. 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
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). Solche Zertifikate sollten entweder ersetzt oder dem Benutzer über eine explizite Zuordnung direkt zugeordnet werden. Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2189925. Benutzer: %1 Zertifikatantragsteller: %2 Zertifikataussteller: %3 Zertifikatseriennummer: %4 Zertifikatfingerabdruck: %5

Die Erneuerung eines Zertifikats über den Registrierungsdienst für Netzwerkgeräte (NDES) schlägt fehl mit Fehlercode CERT_E_UNTRUSTEDCA

Folgendes Szenario angenommen:

Es wird ein Zertifikat über den Registrierungsdienst für Netzwerkgeräte (NDES) beantragt.
Hierbei kommt der Renewal-Modus zum Einsatz, d.h. die Zertifikatanforderung wird mit einem bestehenden Zertifikat signiert.
Die Beantragung des neuen Zertifikats schlägt mit folgender Fehlermeldung fehl:

A certification chain processed correctly, but one of the CA
certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)

Die Installation eines neuen Zertifizierungsstellen-Zertifikats schlägt fehl mit Fehlercode "ERROR_INVALID_PARAMETER"

Folgendes Szenario angenommen:

Für eine untergeordnete Zertifizierungsstelle wird ein neues Zertifizierungsstellen-Zertifikat beantragt und von der übergeordneten Zertifizierungsstelle ausgestellt.
Der Subject Distinguished Name (Subject DN) ist identisch zu dem des vorigen Zertifizierungsstellen-Zertifikats.
Dennoch schlägt die Installation des Zertifizierungsstellen-Zertifikats mit folgender Fehlermeldung fehl:

An error was detected while configuring Active Directory Certificate Services.
The Active Directory Certificate Services Setup Wizard will need to be rerun to complete the configuration.
The new certificate subject name does not exactly match the active CA name.
Renew with a new key to allow minor subject name changes: The parameter is incorrect. 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER).

Zeichenkodierung im Subject Distinguished Name von Zertifikatanforderungen und ausgestellten Zertifikaten

Üblicherweise ist die Kodierung von Zeichen und Zeichenketten in Zertifikaten kein Thema, welches die Nutzer einer PKI groß interessiert. Es gibt jedoch Fälle, in welchen die Standardeinstellungen der Zertifizierungsstelle nicht die gewünschten Ergebnisse liefern.

Liste der Use Cases der Zertifikate, für welche die Kompatibilität zu auf elliptischen Kurven (ECC) basierenden Schlüsseln bekannt ist

Mit zunehmend zur Verfügung stehender Rechenleistung steigt auch der Bedarf, stärkere kryptographischer Schlüssel einzusetzen. Oftmals besteht der Bedarf (beispielsweise, weil die Schlüssel per Trusted Platform Modul geschützt werden müssen), in diesem Zug auf elliptischen Kurven (ECC) basierende Schlüssel einzusetzen. Für deren Einsatz ist es essenziell, dass die Kompatibilität zu den vorgesehenen Use Cases sichergestellt ist.

Nachfolgend eine Liste von Use Cases, für welche mir die Kompatibilität bekannt ist.