AD CS- und PKI-Fehler in Windows verstehen: Was bedeuten Zertifikats-, CRL- und OCSP-Meldungen konkret?

Fehlermeldungen im Enrollment-Lifecycle: Anforderung, Ausstellung, Autoenrollment, Erneuerung und Widerruf in AD CS

Fehlermeldungen im Enrollment-Lifecycle entstehen typischerweise an klar abgrenzbaren Übergängen: beim Erstellen der Anforderung (lokale Kryptografie und Identität), bei der Übergabe an den Enrollment-Endpunkt (RPC/DCOM, HTTP, CES/CEP), bei der Richtlinienprüfung (Vorlage, Berechtigungen, CA-Policy) sowie beim Publizieren des Ergebnisses (Zertifikatspeicher, Active Directory, Replikation). In Microsoft-Umgebungen erscheinen dieselben Ursachen häufig als TLS-, Anmelde- oder Dienstfehler, weil Zertifikate als Träger von Identität (EKU, SAN, UPN) und Vertrauensbeziehungen (Kette, Widerruf) in viele Protokolle eingebettet sind.

Der Enrollment-Status wird zudem durch Nebenbedingungen geprägt: korrekte Systemzeit (Kerberos, Signaturvalidierung, CRL/OCSP-ThisUpdate/NextUpdate), erreichbare DNS-Namen der Enrollment-URLs, AD-Integrität (Vorlagenobjekte, Gruppenmitgliedschaften, Replikation) und der verwendete Sicherheitskontext (Maschinenkonto, Benutzerkonto, Dienstkonto, Delegation). Fehlertexte und HRESULT-/Win32-Codes sind deshalb nur dann eindeutig interpretierbar, wenn sie der Phase und Komponente zugeordnet werden.

Anforderungserstellung: Schlüssel, CSP/KSP und lokale Validierung

In der ersten Phase scheitert Enrollment häufig bereits vor dem Kontakt zur CA. Ursache sind defekte oder nicht kompatible Kryptoprovider, fehlende Berechtigungen auf Schlüsselcontainer oder Richtlinien, die die Schlüsselerzeugung verhindern. Bei CNG-basierter Schlüsselerzeugung (KSP) treten andere Fehlerbilder auf als bei älteren CAPI-Anbietern (CSP). Zusätzlich wirken Template-Vorgaben wie Schlüssellänge, Exportierbarkeit, KeySpec bzw. KeyUsage, Providerliste und die Frage, ob ein privater Schlüssel überhaupt erzeugt werden darf (z. B. bei Key Archival oder wenn der Template-Workflow einen vorhandenen Schlüssel erwartet).

• CRYPT_E_NOT_FOUND (0x80092004): Objekt (z. B. Provider, Zertifikat oder angeforderte Eigenschaft) nicht gefunden; häufig bei inkonsistenter Providerzuordnung oder fehlenden Vorlagenattributen in lokalen Enrollment-APIs.
• NTE_BAD_KEYSET (0x80090016): Schlüsselcontainer nicht vorhanden oder nicht zugreifbar; typisch bei beschädigten Profil-/Maschinenschlüsselspeichern oder falschen ACLs auf %ProgramData%\Microsoft\Crypto\RSA\MachineKeys.
• NTE_EXISTS (0x8009000F): Schlüsselcontainer existiert bereits; tritt bei Wiederholungen mit identischem Key-Container-Namen oder bei abgebrochenen Enrollment-Versuchen auf, wenn Cleanup ausbleibt.
• NTE_SILENT_CONTEXT (0x80090022): Provider erfordert Benutzerinteraktion, die im aktuellen Kontext (z. B. Dienst/Autoenrollment) nicht möglich ist; häufig bei Smartcard-/HSM-Providern ohne Silent-Mode.
• 0x80070005 (E_ACCESSDENIED): Zugriff verweigert beim Öffnen/Erstellen von Schlüsselmaterial oder beim Schreiben in Zertifikatspeicher; je nach Kontext relevant für LocalMachine\My oder CurrentUser\My.
• 0x80090029 (NTE_NOT_SUPPORTED): angeforderter Algorithmus/Parameter nicht unterstützt; häufige Ursache sind Templates, die z. B. ECC verlangen, während der konfigurierte KSP dies im Zielsystem nicht bereitstellt.

Übermittlung und Policy-Abgleich: Enrollment-Endpunkte, RPC/HTTP und CA-Erreichbarkeit

Nach erfolgreicher CSR-Erstellung entscheidet der Transportweg über typische Fehlerklassen. Klassisch kommuniziert die MMC/CertEnroll-API per RPC/DCOM mit der CA. Web-Enrollment, Certificate Enrollment Web Services (CES) und Certificate Enrollment Policy Web Service (CEP) nutzen HTTP(S) und bringen zusätzliche TLS- und Authentifizierungsabhängigkeiten mit. Die CA selbst prüft die Vorlage (Certificate Template), die Request-Attribute und die ausstellungsrelevanten Policies; dabei entstehen sowohl lokale CA-Fehlercodes (CERTSRV_*) als auch transportbedingte HRESULTs.

Bei CES/CEP verschieben sich Ursachen: Ein scheinbarer Enrollment-Fehler kann in Wahrheit ein TLS-Handshake-Problem zum Webdienst sein (Serverzertifikat nicht vertrauenswürdig, EKU fehlt, Name mismatch) oder eine Authentifizierungsfrage (Kerberos/NTLM, SPN, Delegation). Bei RPC/DCOM dominieren Netzwerksegmentierung, DCOM-Härtung, dynamische RPC-Ports und Dienstzustände. In beiden Fällen gilt: Der Code beschreibt den Zeitpunkt des Abbruchs, nicht zwingend die Wurzelursache.

Autoenrollment: Gruppenrichtlinie, AD-Replikation und Zugriffskontext

Autoenrollment koppelt Zertifikatsausstellung eng an Active Directory. Die Clientseite liest Vorlagen und Policies aus AD, entscheidet anhand von EKU/Anwendungsrichtlinien, Erneuerungsfenstern und vorhandenen Zertifikaten, und führt die Anforderung im Benutzer- oder Computerkontext aus. Fehlermuster entstehen durch widersprüchliche GPOs, unvollständige AD-Replikation (Vorlage existiert nicht auf dem kontaktierten DC), fehlende Mitgliedschaften (z. B. Sicherheitsgruppen, die Enrollment erlauben) oder durch den Wechsel des Kontexts (SYSTEM vs. Benutzer).

• 0x80070002 (ERROR_FILE_NOT_FOUND): im Autoenrollment-Kontext häufig als Folge fehlender Vorlagen-/Policyobjekte aus AD (Client findet referenzierte Template- oder Policy-Daten nicht), z. B. bei Replikationsverzug oder falscher LDAP-Sicht.
• 0x80070520 (ERROR_NO_SUCH_LOGON_SESSION): Benutzerkontext für Enrollment nicht verfügbar; typisch bei geplanten Tasks/Diensten ohne interaktive Anmeldesitzung, wenn Enrollment explizit im Benutzerstore erfolgen soll.
• CERTSRV_E_BAD_REQUESTSTATUS (0x80094003): CA meldet ungültigen oder nicht passenden Request-Status; kann bei Autoenrollment als Folge inkonsistenter Wiederholungen, ausstehender Requests oder Policy-Module-Entscheidungen sichtbar werden.
• CERTSRV_E_ENROLL_DENIED (0x80094011): Enrollment durch Policy/Permissions verweigert; häufig bei fehlendem Enroll/Autoenroll-Recht auf der Vorlage oder wenn die CA den Antragsteller aufgrund von Einschränkungen (z. B. Manager Approval, RA-Policy) ablehnt.

Autoenrollment wirkt zusätzlich in die Zertifikatsinstallation hinein. Selbst wenn die CA ausstellt, kann die Persistierung scheitern: Schreibrechte im Store, Roamingprofile, beschädigte Benutzerprofile oder Schlüsselcontainerrechte führen dazu, dass das Zertifikat zwar existiert, aber nicht nutzbar ist (privater Schlüssel fehlt oder ist nicht lesbar). Daraus entstehen später Sekundärfehler wie „Kein Zertifikat gefunden“ in TLS- oder SChannel-Szenarien, obwohl die CA-Ausstellung korrekt war.

Erneuerung und Rollovers: Validität, Key-Reuse und Kettenwechsel

Erneuerung (Renewal) ist kein reiner Neu-Antrag: Der Client bewertet NotAfter, Renewal-Period und Template-Regeln (neuer Schlüssel vs. Wiederverwendung, Subject/SAN-Neuberechnung, EKU-Änderungen). Besonders fehleranfällig sind Rollovers, bei denen sich die ausstellende CA, der Signaturalgorithmus oder die Kette ändert. Ein erneuertes Zertifikat kann formal gültig sein, aber wegen fehlender neuen Intermediate-/Root-Vertrauensanker oder wegen nicht erreichbarer AIA/CDP-URLs operativ ausfallen.

• CERT_E_EXPIRED (0x800B0101): ein Zertifikat in der Kette ist abgelaufen; bei Renewal häufig Hinweis auf abgelaufenes Intermediate/Root oder auf eine Zeitabweichung, die die Gültigkeitsprüfung vorzeitig fehlschlagen lässt.
• CERT_E_VALIDITYPERIODNESTING (0x800B0102): Gültigkeitszeitraum eines untergeordneten Zertifikats überschreitet den der ausstellenden CA; relevant bei Template-Lifetime-Änderungen oder CA-Lifetime-Reduktion vor Renewal.
• CRYPT_E_REVOCATION_OFFLINE (0x80092013): Widerrufsprüfung konnte nicht durchgeführt werden; bei Rollovers häufig durch neue CDP/OCSP-Endpunkte oder durch Proxy/Firewall-Regeln ausgelöst.

In Windows ist die Erneuerung zudem an den Zugriff auf den alten privaten Schlüssel gebunden, wenn Schlüsselwiederverwendung oder bestimmte Migrationspfade (z. B. für S/MIME) greifen. Fehlt der alte Schlüssel (Profilwechsel, Keyset beschädigt), erscheint die Erneuerung je nach Implementierung als neue Registrierung oder bricht mit Keyset-/Providerfehlern ab. Bei serverseitigen Diensten fällt das oft erst in abhängigen Systemen auf, wenn die Anwendung weiterhin das alte Zertifikat referenziert, während der Store bereits aktualisiert wurde.

Widerruf und Status: Request-Entscheidungen, CRL-Integration und operative Nebenwirkungen

Widerruf gehört formal nicht mehr zur Ausstellung, beeinflusst aber den Enrollment-Lifecycle operativ: Ein „erfolgreich“ ausgestelltes Zertifikat kann unmittelbar nach Aktivierung von Widerrufspflichten praktisch unbrauchbar werden, wenn CRLs nicht publiziert oder OCSP-Signaturen nicht valide sind. AD CS signalisiert Widerrufsprobleme selten im Enrollment selbst; stattdessen erscheinen sie in der Nutzung als Ketten- und Statusfehler, etwa bei SChannel, IPsec, RDP, LDAPS oder beim Aufbau von Vertrauensstellungen zwischen Diensten.

• CERT_E_REVOKED (0x800B010C): Zertifikat wurde widerrufen; Zuordnung zur Statusprüfung (Chain Engine), nicht zur Ausstellung. Typisch nach CA-Disziplinarmaßnahmen, kompromittierten Schlüsseln oder falschem Widerruf der falschen Seriennummer.
• CRYPT_E_NO_REVOCATION_CHECK (0x80092012): Widerrufsprüfung war nicht möglich oder wurde von der Policy nicht erzwungen; tritt auf, wenn weder CRL noch OCSP für ein Zertifikat verwertbar sind (fehlender CDP/AIA, Policy-Constraints, Offline-Chain-Build).
• CRYPT_E_REVOCATION_OFFLINE (0x80092013): Widerrufsserver offline bzw. nicht erreichbar; häufig verursacht durch nicht erreichbare http://-CDP-URLs, DNS-Probleme oder blockierte egress-Regeln auf Servern.
• CERTSRV_E_REVOKED_CERTIFICATE (0x8009400D): CA-interner Statuscode im Zusammenhang mit einem widerrufenen Zertifikat/Request; relevant in CA-Logs und Verwaltungsaktionen, weniger als Client-Fehlertext.

Bei Widerruf ist die Trennung zwischen CA-Entscheidung und Client-Validierung zentral: Die CA setzt den Status und publiziert CRLs, doch die Wirksamkeit entsteht erst in den Validierungs-Engines der Konsumenten. In der Praxis führt eine fehlerhafte CRL-Publikation dazu, dass Anwendungen den gesamten TLS-Handshake abbrechen, obwohl Zertifikat und Schlüssel korrekt sind. Enrollment wirkt dann unauffällig; die Störung liegt im nachgelagerten Statusmodell, das jedoch unmittelbar die Nutzbarkeit frisch ausgestellter oder erneuerter Zertifikate bestimmt.

Vertrauen und Validierung: Kettenaufbau, Zertifikatsstatus (CRL/OCSP) und typische Trust-Fehler in Windows-Krypto-APIs

Wie Windows Vertrauen bewertet: Chain Engine, Policy und EKU

Windows validiert X.509-Zertifikate über die CryptoAPI bzw. CNG-Policykomponenten, die den Kettenaufbau (Chain Building) und die Vertrauensentscheidung (Trust Decision) trennen. Beim Kettenaufbau werden potenzielle Issuer in den Zertifikatsspeichern (Machine/User), über AIA (Authority Information Access) sowie über anwendungsseitig bereitgestellte Zertifikate gesucht. Erst danach bewertet die Policy Engine, ob die resultierende Kette für den konkreten Zweck zulässig ist: Gültigkeitszeitraum, Schlüsselverwendung (Key Usage), Enhanced Key Usage (EKU), Basic Constraints (CA=TRUE/Path Length), Signaturalgorithmen, Name Constraints und – je nach Anwendung – zusätzliche Regeln wie „Server Authentication“ für TLS oder „Client Authentication“ für mTLS.

In AD-CS-Umgebungen beeinflussen auch „Enterprise Trust“ und Gruppenrichtlinien die Bewertung. Root- und Intermediate-Zertifikate werden typischerweise über Active Directory verteilt und in Trusted Root Certification Authorities bzw. Intermediate Certification Authorities verankert. Unterschiede zwischen Benutzer- und Computerkontext (z. B. Dienstkonto, LocalSystem, gMSA) sind häufig die Ursache dafür, dass ein Zertifikat im Browser „funktioniert“, ein Windows-Dienst aber scheitert: Die Kettenengine liest dann andere Stores und besitzt andere Netzwerk- und Proxybedingungen für AIA/CRL/OCSP-Abrufe.

Typische Kettenfehler (Chain Building) und ihre Zuordnung

Kettenfehler entstehen, wenn kein vertrauenswürdiger Pfad zu einem Trust Anchor (Root) aufgebaut werden kann oder wenn ein Glied der Kette kryptografisch oder semantisch ungültig ist. In Windows erscheinen diese Zustände als HRESULT-/Win32-Codes (z. B. 0x800B0109) oder als CERT_E-/CRYPT_E-Fehler. Anwendungen kapseln sie oft als TLS-Handshakefehler, „Anmeldefehler“ oder „Die Zertifikatkette wurde von einer nicht vertrauenswürdigen Stelle ausgestellt“, obwohl die eigentliche Ursache in Store-Inhalt, AIA-Erreichbarkeit oder Zwischenzertifikaten liegt.

• Zertifikatkette endet nicht in einem vertrauenswürdigen Stamm: CERT_E_UNTRUSTEDROOT (0x800B0109) – Root-CA nicht im passenden Store (LocalMachine\Root vs. CurrentUser\Root) oder Trust per GPO fehlt.
• Ein Zertifikat war nicht signiert bzw. Signaturprüfung fehlgeschlagen: TRUST_E_CERT_SIGNATURE (0x80096004) – beschädigte Zertifikatsdaten, falscher Issuer/Subject-Match oder nicht passende Public-Key-Parameter im Chain-Element.
• Ein Zertifikat kann nicht gefunden werden (Issuer fehlt): CERT_E_CHAINING (0x800B010A) – Intermediate-CA-Zertifikat nicht vorhanden und AIA (Authority Information Access) nicht erreichbar oder vom Prozess nicht abrufbar.
• Das Zertifikat ist abgelaufen oder noch nicht gültig: CERT_E_EXPIRED (0x800B0101) bzw. CERT_E_VALIDITYPERIODNESTING (0x800B0102) – Systemzeit/Zeitzone oder CA-Zeitfehler, außerdem fehlerhafte Gültigkeitsverschachtelung innerhalb der Kette.
• Der Zertifikatzweck ist nicht zulässig: CERT_E_WRONG_USAGE (0x800B0110) – EKU/Key Usage passt nicht zur Anwendung, z. B. TLS-Serverzertifikat ohne Server Authentication (1.3.6.1.5.5.7.3.1).
• Grundlegende Constraints verletzt (CA/Path Length): CERT_E_INVALID_BASIC_CONSTRAINTS (0x800B0103) – Intermediate ohne CA-Berechtigung oder Path-Length überschritten; häufig nach fehlerhaften Cross-Signings oder falschen Vorlagen.

Statusprüfung: CRL, Delta-CRL und OCSP als eigene Fehlerdomäne

Die Widerrufs- und Statusprüfung ist in Windows konzeptionell vom Kettenaufbau getrennt, hängt aber am Ergebnis der Chain Engine. CRL (Certificate Revocation List) wird über CDP (CRL Distribution Points) bezogen; OCSP über AIA/OCSP-URLs. In AD-CS sind CDP/AIA häufig HTTP- und LDAP-Pfade, wobei HTTP aus Sicht vieler Clients die robustere Variante ist. Zeitkritische Aspekte betreffen nicht nur die Zertifikatslaufzeit, sondern auch thisUpdate/nextUpdate der CRL sowie OCSP-Response-Gültigkeiten. Fehler in diesem Bereich treten oft dann auf, wenn PKI-Inhalte zwar korrekt ausgestellt, aber nicht konsistent veröffentlicht wurden oder wenn Netzwerk-/Proxyregeln den Abruf durch Dienstkonten verhindern.

Die Unterscheidung zwischen „offline“ und „keine Revocation-Information“ ist diagnostisch zentral: CRYPT_E_REVOCATION_OFFLINE beschreibt typischerweise ein Transport-/Namensauflösungsproblem zu einer prinzipiell vorgesehenen Quelle, während CRYPT_E_NO_REVOCATION_CHECK auf fehlende oder nicht verwendbare Verweise im Zertifikat oder auf policyseitige Deaktivierungen hinausläuft. In beiden Fällen können Anwendungen den Fehler als generische TLS-Warnung oder als „Die Sperrprüfung konnte nicht durchgeführt werden“ darstellen.

Diagnostische Anker: welche Windows-APIs und Tools die Codes liefern

Die Mehrdeutigkeit vieler Anwendungsfehler reduziert sich, wenn die zugrundeliegenden Chain-/Statuscodes sichtbar werden. certutil nutzt die Windows-Chain-Engine und kann daher sehr nah am Verhalten von Schannel, WinHTTP oder .NET liegen. Für TLS ist außerdem entscheidend, ob die Validierung im Maschinenkontext (Dienste, IIS, RDP) oder im Benutzerkontext (Browser, Benutzerprozesse) stattfindet. Unterschiedliche Stores und unterschiedliche Netzwerkpfade (z. B. Systemproxy vs. Benutzerproxy) erzeugen ansonsten widersprüchliche Ergebnisse.

• Kette und Trust-Status prüfen: certutil -verify -urlfetch C:\Pfad\zertifikat.cer
• CRL/OCSP-Abruf interaktiv testen: certutil -url C:\Pfad\zertifikat.cer
• Zertifikatspeicher im Maschinenkontext prüfen: certutil -store -enterprise Root
certutil -store CA
• SChannel-/TLS-Symptome mit Kettenursache abgleichen: eventvwr.msc und relevante Protokolle wie Microsoft-Windows-Schannel/Operational (falls aktiviert) sowie System mit Schannel-Events.

Bei der Bewertung der Ergebnisse zählt der erste „harte“ Fehler im Chain-Kontext. Ein CERT_E_UNTRUSTEDROOT bleibt auch dann bestimmend, wenn nachgelagert zusätzlich CRYPT_E_REVOCATION_OFFLINE erscheint, weil Widerrufsinformationen ohne stabilen Trustpfad nicht sicher bewertet werden können. Umgekehrt kann eine perfekt vertrauenswürdige Kette durch CERT_E_REVOKED oder durch eine abgelaufene CRL faktisch unbrauchbar werden, obwohl Issuer und Root korrekt verteilt sind.

Kryptografie-, Provider- und Infrastrukturabhängigkeiten: Schlüssel, CSP/KSP, Berechtigungen, Templates sowie Wechselwirkungen mit AD, DNS und Zeit

Viele AD-CS- und PKI-Fehler wirken zunächst wie „Zertifikatsprobleme“, entstehen aber tatsächlich an Schnittstellen: kryptografische Provider (CSP/KSP), Schlüsselmaterial im lokalen Key Storage, Berechtigungen auf Vorlage und CA, sowie Basisdienste wie Active Directory, DNS und Zeit. Diese Abhängigkeiten erklären, warum identische Zertifikatsanforderungen je nach Computer-, Dienst- oder Benutzerkontext unterschiedlich scheitern und warum Störungen später als TLS-, RDP-, LDAP- oder Anmeldefehler sichtbar werden.

Schlüsselmaterial und Provider: CSP/KSP, Algorithmen, Schlüsselcontainer

Unter Windows entscheidet der Kryptografie-Stack aus CAPI/CNG, welcher Provider (Legacy-CSP oder moderner KSP) Schlüssel erzeugt und speichert. AD-CS-Zertifikatvorlagen binden diese Entscheidung über Kryptografieeinstellungen (Providerliste, Mindestschlüssellänge, Hashalgorithmus). Ein häufiges Muster: Die CA oder die Vorlage akzeptiert den angeforderten Algorithmus nicht, oder der Client kann den geforderten Provider nicht laden. Dadurch entsteht bereits beim Erzeugen des Schlüssels oder beim Signieren der Anforderung ein Fehler, lange bevor die CA die Anfrage bewertet.

Typische Ursachen sind fehlende Provider-Registrierungen, deaktivierte oder nicht FIPS-konforme Algorithmen, gesperrte Schlüsselcontainer (z. B. durch ACLs oder Profilprobleme) oder konkurrierende Einstellungen zwischen Vorlage, Gruppenrichtlinie und Anwendung (SChannel, KDC, IIS, NPS). Bei Smartcard-, TPM- oder HSM-Szenarien verschärfen sich diese Effekte: Der Schlüssel ist hardwaregebunden, PIN/Policy-gesteuert und kann nicht exportierbar sein. Daraus folgen Statusmeldungen, die auf „Keyset“ oder „Provider“ verweisen, obwohl im Ergebnis „nur“ ein Zertifikat fehlt.

• Provider kann nicht geladen werden: CRYPT_E_UNKNOWN_PROVIDER (0x80090016) – betroffene Komponente: Kryptografie-Provider-Registrierung (CAPI/CNG), häufig bei Vorlagen mit festem CSP/KSP oder nach Provider-Deinstallation.
• Schlüsselcontainer/Keyset nicht vorhanden: NTE_BAD_KEYSET (0x80090016) – Komponente: lokaler Schlüsselcontainer (Benutzer/Computer/Service-Context), oft bei Dienstkonten ohne Profil oder nach Key-Storage-Bereinigung.
• Schlüssel existiert bereits: NTE_EXISTS (0x8009000F) – Komponente: Key Storage; tritt bei wiederholter Enrollment-Logik mit identischem Container-Namen oder bei fehlerhaftem Cleanup auf.
• Ungültiger Provider-Typ/Parameter: NTE_BAD_TYPE (0x80090005) oder NTE_BAD_FLAGS (0x80090009) – Komponente: Provider-API-Aufruf; typisch bei nicht kompatiblen Vorlagenparametern oder veralteten Enrollment-Clients.
• Algorithmus/Schlüssellänge nicht unterstützt: NTE_NOT_SUPPORTED (0x80090029) – Komponente: Provider oder Richtlinie; praktisch bei ECC/RSA-Mismatch, deaktivierten Kurven oder KSP ohne ECC-Unterstützung.
• Privater Schlüssel nicht zugreifbar: CRYPT_E_NO_KEY_PROPERTY (0x80092004) oder NTE_PERM (0x80090010) – Komponente: Schlüsselberechtigungen; häufig bei Dienstzertifikaten, wenn das private Key ACL nicht auf das Dienstkonto delegiert wurde.

Berechtigungen, Sicherheitskontext und Delegation: warum „Zugriff verweigert“ selten trivial ist

AD-CS trennt Berechtigungen an mehreren Stellen: auf der Zertifikatvorlage (AD-Objekt), auf der CA selbst (Ausstellen/Verwalten), sowie lokal am privaten Schlüssel nach erfolgreicher Ausstellung. Fehlerbilder werden oft vermischt: Eine Zertifikatsanforderung kann an der Vorlage scheitern, obwohl der CA-Dienst erreichbar ist; oder die Ausstellung gelingt, aber der private Schlüssel bleibt für den eigentlichen Dienst unlesbar. Zusätzlich bestimmt der Kontext (Benutzer, Computer, Dienstkonto, SYSTEM) den Speicherort des Schlüssels und die Fähigkeit, sich per DCOM/RPC oder HTTP Enrollment zu authentifizieren.

Im Kerberos/LDAP-Umfeld werden PKI-Probleme gern als Anmeldefehler sichtbar. Fehlt etwa ein Clientauthentifizierungszertifikat oder ist der private Schlüssel nicht nutzbar, erscheinen Folgemeldungen in KDC-, LSA- oder SChannel-Logs. Umgekehrt kann eine scheinbare Zertifikatsfehlermeldung primär ein Berechtigungsproblem sein, etwa durch fehlende DCOM-Berechtigungen für die Enrollment-Komponente oder durch restriktive „Request Handling“-Einstellungen der Vorlage (z. B. „private key exportable“ verboten, Key archival erforderlich).

• CA-Rechte prüfen (Übersicht): certutil -config "CAHost\CA-Name" -getreg CA\DSConfigDN
certutil -config "CAHost\CA-Name" -caInfo
• Template-Berechtigungen und Autoenrollment: certutil -template – zeigt Vorlagenattribute; effektive Rechte werden über AD-ACLs und Gruppenmitgliedschaften bestimmt.
• Zugriff auf privaten Schlüssel (lokal): certutil -store my – Identifikation des Zertifikats; die Schlüssel-ACL wird anschließend über die Key-Storage-Mechanismen (CNG/CAPI) gesetzt und kann bei Dienstkonten nachgezogen werden.

Zertifikatvorlagen (Templates): Kryptografie-Constraints, EKUs, Namensbildung und Policy-Kollisionen

Zertifikatvorlagen sind die zentrale Policy-Schicht: Sie definieren EKUs, Key Usage, Subject/SubjectAltName-Regeln, Kryptografieparameter, Gültigkeitsdauer sowie Enrollment-Workflows (Manager Approval, Key Archival, private-key-Eigenschaften). Fehlermeldungen entstehen oft aus Kollisionen zwischen Template-Definition und tatsächlicher Anforderung. Typisch ist ein SAN-Problem: Anwendungen erwarten DNS Name oder UPN, die Vorlage erlaubt aber nur Build-from-AD, oder umgekehrt fordert ein Client SAN per Request, obwohl die Vorlage dies verbietet. Solche Konflikte tauchen als CA-Policy-Module-Fehler auf, während der Client häufig nur „Anforderung abgelehnt“ protokolliert.

Auch kryptografische Details der Vorlage wirken in andere Systeme hinein. Beispiel: Für TLS ist nicht nur ein Zertifikat nötig, sondern ein privater Schlüssel mit passendem KeySpec/Provider, EKU Server Authentication und eine vollständige Kette. Wird ein Zertifikat zwar ausgestellt, aber im falschen Store abgelegt (User statt Computer) oder der Dienst hat keinen Zugriff auf den Schlüssel, resultieren SChannel-Fehler, die wie Trust- oder Protokollprobleme aussehen. In Domain-Szenarien sind außerdem KDC- und LDAPS-Anforderungen strikt: EKUs, SubjectAltName und Key Usage müssen exakt zu Kerberos/LDAP passen, sonst schlagen Bind/Logon-Operationen fehl, obwohl die CA formal „gültige“ Zertifikate liefert.

• Template-Konflikt (allgemein): CERTSRV_E_UNSUPPORTED_CERT_TYPE (0x80094800) – Komponente: CA/Template-Zuordnung; tritt auf, wenn die angeforderte Vorlage nicht auf der CA publiziert ist oder deren Version/Typ nicht unterstützt wird.
• Ungültige oder nicht erlaubte Erweiterung: CERTSRV_E_BAD_REQUESTSUBJECT (0x80094001) – Komponente: Policy-Auswertung der Subject-/SAN-Regeln; häufig bei nicht erlaubten Subject-Namen oder SAN-Einschränkungen durch die Vorlage.
• Erfordert Schlüsselarchivierung, aber CA/Agent fehlt: CERTSRV_E_KEY_ARCHIVAL_NOT_CONFIGURED (0x8009400F) – Komponente: CA-Konfiguration/Key Recovery; entsteht, wenn die Vorlage Key Archival verlangt, die CA jedoch keinen KRA-Agenten konfiguriert hat.
• Ausstehend/Manager Approval: CERTSRV_E_REQUEST_PENDING (0x80094005) – Komponente: CA-Policy-Workflow; kein Kryptografiefehler, sondern Status „Pending“ bis zur Freigabe.

AD, DNS und Zeit: unsichtbare Voraussetzungen für Ketten, Identitäten und Protokolle

Active Directory liefert nicht nur Benutzer- und Computeridentitäten, sondern auch PKI-Metadaten: veröffentlichte CA-Zertifikate, AIA/CDP-Objekte, Template-Objekte und Vertrauensanker in domänenbasierten Stores. Wenn AD-Replikation stockt oder Sites/Subnets falsch abgebildet sind, sehen Clients unterschiedliche Template-Versionen oder veraltete CA-Informationen. DNS bestimmt, ob Enrollment-Endpunkte, CA-Namen, CDP/AIA-URLs und OCSP-Responder erreichbar sind. Fehler in Namensauflösung oder falsche SPNs können RPC/HTTP Enrollment oder TLS-SNI-Validierung brechen, ohne dass sich am Zertifikat selbst etwas ändert.

Zeit ist eine harte Abhängigkeit, weil Zertifikatsvalidierung und Kerberos zeitgebunden sind. Schon moderate Abweichungen können zu „noch nicht gültig“ oder „abgelaufen“ führen; bei Kerberos kommt eine enge Toleranz hinzu. In der Praxis tauchen diese Fehler als TLS-Handshake-Abbruch, LDAPS-Bind-Fehler oder Anmeldeverweigerung auf, obwohl die Zertifikatskette korrekt ist. Besonders tückisch sind Szenarien, in denen der Client die Zeit korrekt hat, aber der OCSP-Responder, die CA oder ein Reverse Proxy nicht.

• DNS und CA-Erreichbarkeit testen: nslookup ca01.contoso.tld
Test-NetConnection ca01.contoso.tld -Port 135
certutil -ping -config "ca01.contoso.tld\CA-Name"
• Zeitquelle und Drift prüfen: w32tm /query /status
w32tm /stripchart /computer:dc01.contoso.tld /samples:5 /dataonly
• Ketten- und Sperrprüfung mit URL-Nachverfolgung: certutil -verify -urlfetch zielzertifikat.cer – zeigt, welche AIA/CDP/OCSP-URLs fehlschlagen und ordnet den Fehler dem Retrieval zu.