Uwe Gradenegger – Passionate about PKI

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.

Verlängern oder verkürzen des Gültigkeitszeitraums von Stammzertifizierungsstellen-Zertifikaten

Bei bestehenden Public Key Infrastrukturen mag man vielleicht feststellen, dass die Gültigkeit des Stammzertifizierungsstellen-Zertifikats sich nicht bewährt hat. Beispielsweise könnte es sein, dass es zu kurz gewählt wurde (die Standardeinstellung der Microsoft ADCS ist nur fünf Jahre), oder gar zu lang, was vielleicht aus Sicherheitsaspekten nicht optimal ist.

Erneuert man das Zertifizierungsstellen-Zertifikat, möchte man somit vielleicht eine andere Gültigkeitsdauer erreichen.

Auslesen der Konfiguration der Zertifizierungsstelle durch unprivilegierte Konten unterbinden

Während Penetration Tests und auch für Angreifer, die das Netzwerk nach potentiellen Angriffszielen durchsuchen, sind Einblicke in die Konfiguration der Zertifizierungsstelle hochinteressant.

Nebst eventuellen Fehlkonfigurationen können Angreifer Informationen über das auf der Zertifizierungsstelle verwendete Policy-Modul erlangen.

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 viele Alternative Antragstellernamen (engl. Subject Alternative Name, SAN) unterstützen die Active Directory Certificate Services?

Wie jede Software unterliegen auch die Microsoft Active Directory Certificate Services bestimmten Grenzen, die durch ihr Design auferlegt sind.

Nicht so offensichtlich kann die Frage beantwortet werden, wie viele Alternative Antragstellernamen (engl. Subject Alternative Name, SAN) mit der Microsoft-Zertifizierungsstelle ausgestellt werden können.

Das IETF RFC 5280 beschreibt die Struktur für Subject Alternative Names wie folgt:

SubjectAltName ::= GeneralNames

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.