Zertifikat-Benutzung – Uwe Gradenegger

Beantragen von Zertifikaten mit auf ML-DSA basierenden Schlüsseln über den Registrierungsdienst für Netzwerkgeräte (NDES)

Mit dem Mai 2026 Sicherheits-Update hat Microsoft die Unterstützung für den ML-DSA Algorithmus in den Active Directory Certificate Services bereitgestellt.

In ihrer Dokumentation schreiben sie zwar, dass NDES nicht mit ML-DSA kompatibel ist:

You can enroll ML-DSA certificates through the Certificates Microsoft Management Console (MMC) snap-in and certreq.exe. Enrollment through the Network Device Enrollment Service (NDES) isn’t currently available.

So ganz stimmt das aber nicht…

Das Konfigurieren einer SSL-Zertifikatbindung für Microsoft Internet Information Server (IIS) schlägt fehl mit Fehlermeldung, wenn auf ML-DSA basierenden Schlüssel verwendet werden

Folgendes Szenario angenommen:

Man hat ein Webserver-Zertifikat mit auf ML-DSA basiertem Schlüsselpaar erzeugt.
Man möchte dieses an die Internetinformationsdienste IIS binden.
Die Konfiguration schlägt mit folgender Fehlermeldung fehl:

There was an error while performing this operation.

Details: 

A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)

Die Beantragung von Zertifikaten mit auf ML-DSA basierenden Schlüsseln schlägt fehl mit Fehlermeldung "The parameter is incorrect. 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER)"

Folgendes Szenario angenommen:

Man versucht, Zertifikate mit dem ML-DSA Algorithmus zu beantragen.
Die Beantragung schlägt mit folgender Fehlermeldung fehl:

The parameter is incorrect. 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER)

Kryptographische Härtung der SCEP-Transaktionen für den Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES)

Das Simple Certificate Enrollment Protocol (SCEP) ist ein uraltes Protokoll aus den frühen 2000ern. Es kommt ohne Transport Layer Security (TLS) aus. Daher werden die Protokollnachrichten auf Transportebene verschlüsselt.

Beim Senden der Zertifikatanforderung an den NDES-Server wird der Client den Zertifikatantrag mit dem CEP-Encryption Zertifikat des NDES-Servers (wurde ihm über die GetCACert Nachricht zuvor kommuniziert) vornehmen.

Beim Empfangen des ausgestellten Zertifikats wird der NDES-Server die Antwort mit einem temporär vom SCEP-Client erstellten selbstsignierten Zertifikat verschlüsseln.

In beiden Fällen kommt ein symmetrischer Verschlüsselungsalgorithmus zum Einsatz.

Automatische Veröffentlichung von Zertifikatsperrlisten nach einem Zertifikat-Widerruf

Oft bekomme ich mit, dass PKI-Betreiber gerne wünschen, dass für widerrufene Zertifikate umgehend eine neue Zertifikatsperrliste ausgestellt werden soll.

Nachfolgend möchte ich einige Überlegungen dazu loswerden, warum dieses Vorgehen nicht optimal ist und einen eleganteren Lösungsvorschlag machen.

Was ist der Unterschied zwischen "Beantragen" und "Erneuern" eines Zertifikates im Windows-Ökosystem

Möchte man auf einem Windows-Client über die Microsoft Management-Konsole (MMC) Zertifikate beantragen oder erneuern, hat man mehrere Optionen, welche zwar alle ans Ziel führen, hierbei aber ein unterschiedliches Verhalten zeigen. Nachfolgend wollen wir auf die Unterschiede eingehen.

Angriff auf das Active Directory über Microsoft Intune – und wie er mit TameMyCerts eingedämmt werden kann

Dirk-jan Mollema hat jüngst einen Angriff vorgestellt, bei welchem man sich über Intune ein Zertifikat für hochprivilegierte Konten erschleichen kann. Dieses kann dann verwendet werden, um die gesamte Active Directory Umgebung zu kompromittieren.

Der Angriff ist in seinen Grundzügen vergleichbar mit dem, was ich schon im Artikel "Von Null auf Enterprise Administrator durch den Registrierungsdienst für Netzwerkgeräte (NDES) – und was dagegen getan werden kann" und im Artikel "Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus" beschrieben habe (im Allgemeinen auch auch bekannt als ESC1).

Neu ist jedoch, das Mobile Device Management (MDM) System – in diesem Fall Microsoft Intune – entsprechend auszunutzen.

Nicht neu ist hingegen was mit dem TameMyCerts Policy Modul für die Active Directory Certificate Services dagegen getan werden kann, um die Angriffsoberfläche drastisch zu reduzieren…

Die Security Identifier (SID) Zertifikaterweiterung in per Mobile Device Management (MDM) beantragte Zertifikate automatisch eintragen – mit dem TameMyCerts Policy Modul für die Microsoft Active Directory Certificate Services (ADCS)

Nach mehrfachen Verschiebungen hat Microsoft letztendlich entschieden, dass die Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754) nun endgültig in Kraft treten sollen.

Domänencontroller werden zum 25. Februar 2025 daher automatisch in den Full Enforcement Mode gehen, wenn nichts anderes konfiguriert ist. Zum September 2025 ist angekündigt, dass abweichende Einstellungen wegfallen werden und somit keine Alternative mehr zum Full Enforcement bestehen wird.

Dies hat zur Konsequenz, dass für Anmeldungen via PKInit nur noch dann für eine Anmeldung verwendet werden können, wenn sie über die mit dem Patch neu eingeführte Security Identifier (SID) Zertifikaterweiterung verfügen.

Was zunächst klingt, als wäre dies kein großes Problem, kann durchaus zu einem werden, wenn man bedenkt, dass in der heutigen Zeit immer weniger Zertifikat-basierte Anwendungsfälle klassisches Autoenrollment verwenden.

Wie das TameMyCerts Policy Modul für die Active Directory Certificate Services bei diesem Problem helfen kann, wird im nachfolgenden Artikel näher beleuchtet.

YubiKey Personal Identity Verification (PIV) Attestation – mit dem TameMyCerts Policy Modul für Microsoft Active Directory Certificate Services (ADCS)

Seit der jüngst veröffentlichten Version 1.7 unterstützt das TameMyCerts Policy Modul für die Microsoft Active Directory Certificate Services die Personal Identity Verification (PIV) Attestierung für YubiKeys.

Ein YubiKey ist ein kompaktes Sicherheitstoken, welches unter Anderem wie eine Smartcard für die sichere Speicherung und Verwendung von Zertifikaten eingesetzt werden kann und somit auch für eine passwortlose Anmeldung an Active Directory Umgebungen verwendet werden kann.

Diese coole Funktion wurde von Oscar Virot entwickelt und in TameMyCerts integriert. Mit ihr ist es möglich, bei der Zertifikatausstellung kryptographisch nachzuweisen und somit sicherzustellen, dass ein Schlüsselpaar tatsächlich mit einem YubiKey erzeugt durch diesen gesichert ist und nicht exportiert werden kann.

Dies kann insbesondere bei der Erfüllung der NIS2-Richtlinie hilfreich werden, sofern sich Unternehmen für Zertifikate als zweiten Faktor für die Anmeldung mit sicherheitskritischen Konten im Active Directory entscheiden.

Sperrlisten werden (nur) auf Windows nicht als gültig erkannt (CRYPT_E_REVOCATION_OFFLINE)

Kürzlich ist jemand mit einem interessanten Problem auf mich zugekommen.

Es wurde eine Zertifizierungsstelle installiert. Als Grundlage dient Linux, d.h. (vermutlich) OpenSSL. Die Sperrlisten funktionieren auf Linux-Clients, werden aber von Windows-Systemen nicht akzeptiert. Hier kommt immer folgende Fehlermeldung, wenn man die Sperrlisten überprüft.

0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) -- 2148081683 (-2146885613)
Text der Fehlermeldung: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

Im englischen lautet die Fehlermeldung wie folgt:

0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) -- 2148081683 (-2146885613)
The revocation function was unable to check revocation because the revocation server was offline.

Smartcard-Anmeldung schlägt fehl mit Fehlermeldung "A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)"

Folgendes Szenario angenommen:

Das Unternehmen möchte Smartcard-Anmeldung einsetzen.
Die Domänencontroller sind mit für Smartcard-Anmeldung verwendbaren Zertifikaten ausgestattet.
Die Benutzer sind mit für Smartcard-Anmeldung verwendbaren Zertifikaten ausgestattet.
Die Anmeldung an der Domäne per Smartcard 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)

Wie das Absichern von Druckern zum Security-Desaster werden kann – und wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) dieses verhindern kann

In der heutigen Zeit ist es unumgänglich, die Authentisierung von Geräten am Unternehmens-Netzwerk sowie administrative Schnittstellen zu schützen. In der Regel kommen hierbei auf digitale Zertifikate zum Einsatz.

Auch Drucker benötigen somit in der Regel digitale Zertifikate, um sicher betrieben werden zu können. Ab einer gewissen Anzahl von Geräten kommt man um eine automatische Zertifikatverteilung nicht mehr herum.

Manche Drucker-Hersteller bieten für die Zertifikatverteilung zentrale Management-Lösungen an.

Leider zeigt sich immer wieder, dass der sichere Umgang digitalen Zertifikaten viel Wissen, Erfahrung und Sorgfalt erfordert, was leider oft nicht gegeben ist.

Neue Sicherheitslücke ESC15 in Active Directory Certificate Services entdeckt – einfach umzusetzende Gegenmaßnahmen

Für welche Zwecke ein digitales Zertifikat verwendet werden darf, wird über die Zertifikaterweiterungen "Key Usage" und "Extended Key Usage" gesteuert. In der "Extended Key Usage" Zertifikaterweiterung werden die erweiterten Schlüsselverwendungen eingetragen, für welche das Zertifikat verwendet werden darf.

Es gibt jedoch bei von einer Microsoft Zertifizierungsstelle ausgestellten Zertifikaten noch eine weitere Zertifikaterweiterung namens "Anwendungsrichtlinien" (engl. "Application Policies"), die ebenfalls eine der Extended Key Usages Erweiterung sehr ähnliche Liste enthält.

Justin Bollinger von TrustedSec hat herausgefunden, dass es bei Offline-Zertifikatanforderungen gegen Zertifikatvorlagen der Schema-Version 1 möglich ist (ähnlich wie bei der Security Identifier Erweiterung), beliebige Application Policies im Zertifikatantrag mit zu senden, welche unverändert in das ausgestellte Zertifikat übernommen werden und anschließend für einen Angriff auf die Active Directory Gesamtstruktur verwendet werden können. Der Angriff wurde auf den Namen ESC15 getauft.

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 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 Angriffen ist in der Security-Szene als ESC6 und ESC7 bekannt.