Microsoft CA-Kommunikation 

Wenn Unternehmen ihre digitale Kommunikation sichern, Identitäten verifizieren oder sicheren Zugriff auf Netzwerkressourcen ermöglichen müssen, greifen sie häufig auf Public Key Infrastructure (PKI)-Technologie zurück. Kernstück der PKI ist die Zertifizierungsstelle (CA), eine vertrauenswürdige Stelle, die für die Ausstellung, Verwaltung und Validierung digitaler Zertifikate verantwortlich ist. Diese Zertifikate sind elektronische Anmeldeinformationen, die einen öffentlichen Schlüssel mit der Identität eines Benutzers, Computers oder Geräts verknüpfen und so sichere, verschlüsselte Kommunikation, Authentifizierung und digitale Signaturen ermöglichen.

Dieser Artikel soll IT-Experten dabei helfen, CA-Kommunikationsprobleme zu diagnostizieren und zu lösen und sicherzustellen, dass digitale Zertifikate zuverlässig ausgestellt, validiert und für sichere Vorgänge verwendet werden können.

Was versteht man unter Microsoft CA-Kommunikations-Troubleshooting? Es handelt sich um den Prozess der Diagnose, warum eine Active Directory Certificate Services (AD CS)-Zertifizierungsstelle keine Zertifikate ausstellen, erneuern oder validieren kann. Dabei werden in dieser Reihenfolge der Status des CA-Dienstes, Netzwerkports, Berechtigungen des Dienstkontos, Sichtbarkeit von Zertifikatvorlagen, Ereignisprotokolle sowie die Zugänglichkeit der Zertifikatskette und der CRL überprüft.

Microsoft implementiert diese Technologie unter dem Namen Active Directory Certificate Services (AD CS). AD CS ist eine Windows Server-Rolle, mit der Unternehmen ihre eigene interne Zertifizierungsstelle erstellen und verwalten können. AD CS unterstützt die Ausstellung einer Vielzahl von Zertifikatstypen, darunter:

• Benutzerzertifikate: Diese werden für die Benutzerauthentifizierung, sichere E-Mails (S/MIME) und digitale Signaturen verwendet.
• Maschinen-(Computer-)Zertifikate: Aktivieren Sie Computer- und Serverauthentifizierung, Verschlüsselung und sichere Kommunikation.
• Webserver-Zertifikate: Sichern Sie Webserver und Anwendungen mit SSL/TLS-Verschlüsselung.
• Code-Signing-Zertifikate: Diese werden zum Signieren von Software und Skripten verwendet, um deren Integrität und Authentizität sicherzustellen.
• VPN- und Remote-Access-Zertifikate: Sichern Sie Remote-Verbindungen über VPNs und andere Remote-Access-Technologien.
• Netzwerkgerätezertifikate: Authentifizieren Sie Geräte wie Router, Switches und Firewalls, die möglicherweise keine Domänenkonten haben.
• Smartcard-Zertifikate: Aktivieren Sie eine starke Authentifizierung für Benutzer durch Smartcards oder Hardware-Token.

Die von AD CS bereitgestellten Zertifikate tragen dazu bei, Folgendes sicherzustellen:

• Vertraulichkeit: Durch die Verschlüsselung können nur die vorgesehenen Empfänger die Daten lesen.
• Integrität: Signieren Sie Daten digital, um Manipulationen zu verhindern.
• Authentifizierung: Durch Bestätigung der Identität von Benutzern, Computern oder Geräten, die auf Netzwerkressourcen zugreifen.

Microsoft implementiert diese Technologie über Active Directory Certificate Services (AD CS), eine Windows Server-Rolle, die es Organisationen ermöglicht, ihre eigene interne Zertifizierungsstelle (CA) zu erstellen und zu verwalten.

Eine Microsoft-Zertifizierungsstelle kann auf verschiedene Arten eingerichtet werden, beispielsweise als Stammzertifizierungsstelle (der Vertrauensanker für Ihr Unternehmen) oder als untergeordnete Zertifizierungsstelle (die Zertifikate unter der Autorität der Stammzertifizierungsstelle ausstellt). Unternehmenszertifizierungsstellen sind in Active Directory integriert, was die automatische Ausstellung und Verwaltung von Zertifikaten ermöglicht. Standalone-Zertifizierungsstellen hingegen arbeiten unabhängig und erfordern eine manuelle Genehmigung von Zertifikatsanforderungen.

Eine zuverlässige Kommunikation mit Ihrer Microsoft-Zertifizierungsstelle (CA) ist für jedes Unternehmen wichtig, das die Active Directory-Zertifikatdienste (AD CS) für die sichere Zertifikatsausstellung, Authentifizierung oder Integration mit Drittanbieterplattformen nutzt. Sollten Sie Probleme mit Zertifikatsanforderungen, -verlängerungen oder Integrationsfehlern haben, hilft Ihnen diese Schritt-für-Schritt-Anleitung, Kommunikationsprobleme mit der Microsoft-CA systematisch zu überprüfen und zu beheben. Sehen wir uns zunächst die Unterschiede zwischen öffentlichen CAs und MSCAs an.

Executive Summary

• Kommunikationsprobleme mit Microsoft-Zertifizierungsstellen lassen sich fast immer auf einen der folgenden sechs Bereiche zurückführen: Status des Zertifizierungsstellendienstes, Netzwerkports, Reaktionsfähigkeit der Zertifizierungsstelle, Berechtigungen des Dienstkontos, Sichtbarkeit der Zertifikatvorlage oder Zugänglichkeit der Zertifikatskette und der Sperrliste.
• Beginnen mit Get-Service certsvc Um zu bestätigen, dass der CA-Dienst läuft, arbeiten Sie sich anschließend durch die Ports. certutil -pingBerechtigungen, Vorlagen, Ereignisprotokolle und CRL-Prüfungen der Reihe nach.
• Häufige Fehlersignaturen sind „RPC Server Unavailable“, CERT_E_REVOCATION_FAILURE, CERT_E_UNTRUSTEDROOT sowie die SCEP-Fehlercodes 0x80092013 und 0x80094800.
• Mithilfe der Checkliste zur schnellen Fehlerbehebung und der unten stehenden zusammengefassten Fehlercodetabelle können Sie direkt zu einer Lösung für ein bekanntes Symptom springen.
• CertSecure Manager kann die Erneuerung, Überwachung und AD-Richtlinienanpassung automatisieren, sodass diese Probleme erkannt und behoben werden können, bevor sie zu einem Ausfall führen.

Microsoft CA vs. öffentliche CA

Um den Umfang von Microsoft CA besser zu verstehen, folgt hier ein kurzer Vergleich mit öffentlichen CAs:

Funktion	Microsoft CA (AD CS)	Öffentliche CA (z. B. DigiCert, Let’s Encrypt)
Einsatz	Vor Ort, intern verwaltet	Cloudbasiert, vom Anbieter verwaltet
Vertrauensumfang	Interne Benutzer, Systeme und Dienste	Öffentliches Vertrauen über Browser und Geräte hinweg
Validierungsmodell	AD-basierte Automatisierung	Domänen- (DV), Organisations- (OV) oder erweiterte (EV) Validierung
Kostenmodell	Infrastruktur- und Wartungskosten	Gebühr pro Zertifikat oder Abonnement
Am besten geeignet,	Interne Apps, Server, Geräte, VPN, S/MIME	Websites, externe Apps, APIs
Support und SLAs	Interner IT- oder Microsoft-Support	Vom Anbieter bereitgestellte SLAs, Support

Voraussetzungen für die Fehlerbehebung bei Microsoft CA Communication

Bevor Sie diese Anleitung durcharbeiten, vergewissern Sie sich, dass Sie Folgendes erfüllt haben.

• Administrativer oder delegierter Zugriff auf den Microsoft CA-Server und auf den betroffenen Clientrechner.
• Eine PowerShell- oder Eingabeaufforderungssitzung mit erhöhten Rechten sowohl auf dem CA-Server als auch auf einem Client ist erforderlich, da mehrere Befehle (Restart-Service, dsacls, gpresult /r) benötigen Administratorrechte.
• Es muss eine direkte Sichtverbindung zwischen Client und CA-Server bestehen, damit Porttests aussagekräftig sind.
• Zugriff auf die Zertifizierungsstellenkonsole (certsrv.msc) und das Snap-In „Zertifikatvorlagen“certtmpl.msc).
• RSAT (Remote Server Administration Tools) muss installiert sein, falls Sie es benötigen. Get-CATemplate von einer anderen Maschine als der CA.
• Eine aktuelle Sicherung oder dokumentierte Ausgangslage der CA-Berechtigungen und veröffentlichten Vorlagen, damit Sie im Falle einer Verschlechterung der Situation auf den vorherigen Stand zurückgreifen können.

Schritt für Schritt Anleitung

1. Bestätigen Sie, dass der Microsoft CA-Dienst ausgeführt wird

Wir stellen zunächst sicher, dass der CA-Dienst auf dem Server aktiv ist. Bevor Sie mit der Fehlerbehebung bei zertifikatsbezogenen Problemen beginnen, vergewissern Sie sich immer, dass der CA-Dienst auf dem Server ausgeführt wird. Dies ist wichtig, denn wenn der CA-Dienst gestoppt ist, können keine Zertifikatsanforderungen verarbeitet werden. Die anschließende Fehlerbehebung ist wirkungslos und kostet wertvolle Zeit. Öffnen Sie ein PowerShell-Fenster und führen Sie Folgendes aus:

Get-Service certsvc

Die Ausgabe sollte den Dienststatus als „Wird ausgeführt“ anzeigen. Alternativ können Sie die Diensteverwaltungskonsole (services.msc) öffnen und überprüfen, ob „Active Directory-Zertifikatdienste“ ausgeführt wird.

Wenn der Dienst beendet wurde, kann das Problem häufig durch einen schnellen Neustart behoben werden. Verwenden Sie den folgenden PowerShell-Befehl, um den Dienst zu starten oder neu zu starten:

Neustart-Dienst certsvc

Nach dem Neustart des Dienstes sollten Sie stets die Windows-Ereignisanzeige auf dienstbezogene Fehler oder Warnungen überprüfen. Öffnen Sie die Ereignisanzeige, indem Sie nach eventvwr.msc suchen. Navigieren Sie zu Anwendungs- und Dienstprotokolle > Microsoft > Windows > CertificationAuthority.

Überprüfen Sie aktuelle Ereignisse auf Fehler, Warnungen oder Informationsmeldungen im Zusammenhang mit dem CA-Dienst. Achten Sie besonders auf Protokolle mit Ereignis-IDs wie 58 (Probleme mit der Zertifikatskette), 4886 (Zertifikatanforderungen) und andere relevante Einträge, da diese Aufschluss über zugrunde liegende Probleme geben oder erfolgreiche Vorgänge bestätigen können.

2. Überprüfen Sie die Netzwerkkonnektivität und die erforderlichen Ports

Stellen Sie sicher, dass die erforderlichen Ports für die CA-Kommunikation geöffnet sind.

Erforderliche Ports:

• TCP 135 – RPC-Endpunkt-Mapper
  Es wird für die anfängliche Client/Server-Aushandlung für die RPC-Kommunikation verwendet.
• TCP 445 – SMB (wird für Zertifikatvorlagen und Gruppenrichtlinien verwendet)
  Es ist für den Zugriff auf Zertifikatvorlagen (gespeichert in AD), GPO-Verteilung und DCOM erforderlich.
• Dynamische RPC-Ports – TCP 49152–65535 (für Windows Server 2012 und neuer)
  Es wird verwendet, nachdem RPC Endpoint Mapper einen hohen Port für die Kommunikation zugewiesen hat.
• TCP 88 – Kerberos (zur Domänenauthentifizierung)
  Es übernimmt die Domänenauthentifizierung, wenn ein Benutzer oder Computer Zertifikate anfordert.

Warum sind diese Ports wichtig?

• Kerberos (TCP 88): Erforderlich für die Authentifizierung von in die Domäne eingebundenen Computern bei der Zertifizierungsstelle, insbesondere während der automatischen Registrierung oder des Zugriffs auf Zertifikatvorlagen.
• SMB (TCP 445): Der Zugriff auf im Active Directory gespeicherte Zertifikatvorlagen und CA-Richtlinien basiert auf SMB.
• RPC/High-Ports (TCP 135 + 49152–65535): Kern für DCOM- und RPC-Aufrufe, die von Certreq, Certutil, MMC-Snap-Ins und beim Remote-Anfordern von Zertifikaten verwendet werden.

Testen der Konnektivität mit PowerShell:

Test-NetConnection -ComputerName -Anschluss 135

Ein erfolgreicher Test zeigt an, dass der Port geöffnet ist.

Häufige Probleme:

Firewalls blockieren erforderliche Ports. Um alle Firewall-Regeln aufzulisten, die die CA-Kommunikation beeinträchtigen könnten:

Get-NetFirewallRule

Die Netzwerksegmentierung verhindert die Kommunikation.

Verbindungstest mit Telnet (falls installiert):

Telnet 135
Telnet 445

Wenn der Bildschirm nach dem Drücken der Eingabetaste leer bleibt, ist der Port geöffnet.
Wenn die Meldung „Verbindung konnte nicht geöffnet werden“ angezeigt wird, ist der Port blockiert.

3. Testen Sie die CA-Reaktionsfähigkeit mit Certutil

Überprüfen Sie, ob die Zertifizierungsstelle erreichbar ist und reagiert. Ein Fehler weist darauf hin, dass Ihr System nicht ordnungsgemäß mit der Zertifizierungsstelle kommunizieren kann. Dieser Fehler kann auf mehrere der unten aufgeführten Probleme hinweisen:

Schritte:

Öffnen Sie die Eingabeaufforderung oder PowerShell auf einem Clientrechner und führen Sie den folgenden Befehl aus. Es wird außerdem empfohlen, den Befehl „certutil“ sowohl vom Client als auch vom CA-Server selbst auszuführen.

certutil -config – -ping

Sie werden aufgefordert, die Zertifizierungsstelle auszuwählen. Eine erfolgreiche Antwort bestätigt, dass die Zertifizierungsstelle erreichbar ist.

Sie werden aufgefordert, die Zertifizierungsstelle aus einer Liste auszuwählen. Eine erfolgreiche Antwort bestätigt, dass die Zertifizierungsstelle erreichbar ist.

Skriptbasierte/automatisierte Prüfung:

certutil -config “ \ ” -ping

Ersetzen \ mit der vollständigen Konfigurationszeichenfolge Ihrer Zertifizierungsstelle (z. B. CA-SERVER\My-Enterprise-CA). Dadurch wird die Prüfung direkt gegen die angegebene Zertifizierungsstelle ausgeführt, was sie für Skripte und Automatisierung geeignet macht.

Häufige Probleme:

• „RPC-Server nicht verfügbar“ Fehler weisen auf Kommunikationsstörungen hin. Ein Beispiel für einen solchen Fehler ist:

Wenn Sie einen solchen Fehler erhalten, ist die Zertifizierungsstelle möglicherweise für das System nicht erreichbar, falsch konfiguriert oder durch Sicherheitsrichtlinien blockiert.

• DNS-Auflösungsfehler – Der Hostname der CA kann nicht aufgelöst werden
• Firewall-Einschränkungen – Benötigte Ports (z.B. TCP 135 für RPC) sind blockiert
• CA-Dienst ist offline – Der CA-Server ist ausgefallen oder der Zertifikatsdienstedienst wurde gestoppt
• Netzwerksegmentierung – Routing oder VLAN-Isolation verhindert die Kommunikation

Solche Probleme verhindern, dass Clients die Zertifizierungsstelle finden oder sich bei ihr registrieren.

4. Überprüfen Sie die Berechtigungen des Dienstkontos

Das für die Kommunikation mit der Zertifizierungsstelle verwendete Konto muss über bestimmte Berechtigungen für die Zertifizierungsstelle und die Zertifikatvorlagen verfügen.

So überprüfen Sie Berechtigungen auf CA-Ebene

1. Öffnen Sie den Microsoft Store auf Ihrem Windows-PC Zertifizierungsstelle Konsole auf dem CA-Server (certsrv.msc)
2. Klicken Sie mit der rechten Maustaste auf die Zertifizierungsstelle und wählen Sie Eigenschaften im Vergleich
3. Navigieren Sie zu der Sicherheit Tab
4. Bestätigen Sie, dass das Dienstkonto die Berechtigung hat, Zertifikate anfordern.

Für detailliertere Prüfungen oder Skripts können Sie Tools wie dsacls verwenden:

dsacls „CN=Public Key Services,CN=Dienste,CN=Konfiguration,DC=Domäne,DC=com“

Verwenden Sie den folgenden Befehl, um delegierte Berechtigungen in Active Directory mithilfe von PowerShell zu überprüfen:

Get-ADPermission -Identity „CA_Name“ -Benutzer „ServiceAccountName“

Diese Tools helfen insbesondere in größeren oder automatisierten Umgebungen zu überprüfen, ob dem Dienstkonto über die AD-Delegation die erforderlichen Rechte erteilt wurden.

So überprüfen Sie die Berechtigungen auf Vorlagenebene:

1. Öffnen Sie den Microsoft Store auf Ihrem Windows-PC Zertifikatvorlagen Snap-In (certtmpl.msc)
2. Klicken Sie mit der rechten Maustaste auf die entsprechende Zertifikatvorlage und wählen Sie Eigenschaften im Vergleich
3. Im Sicherheit bestätigen Sie, dass das Konto Lesen Sie mehr, Einschreibenund, falls erforderlich, Automatische Registrierung Berechtigungen

Diese Berechtigungen müssen über Active Directory erteilt werden. Möglicherweise ist eine Aktualisierung der Gruppenrichtlinien erforderlich. Um zu überprüfen, ob die richtigen Gruppenrichtlinien angewendet wurden, führen Sie Folgendes auf dem Clientsystem aus:

gpresult /r

Dieser Befehl zeigt die angewendeten Gruppenrichtlinieneinstellungen an und kann dabei helfen, zu bestätigen, ob auf dem Computer automatische Registrierungs- oder zertifikatsbezogene Richtlinien aktiv sind.

Hinweis : Wenn eine Zertifikatvorlage veröffentlicht, aber von einem Dienstkonto nicht sichtbar oder nutzbar ist, liegt dies in der Regel an einem Berechtigungsproblem auf Vorlagenebene. Falls gar keine Vorlagen funktionieren, überprüfen Sie zunächst die Berechtigungen auf Zertifizierungsstellenebene.

Typische Rollen, die mit dem CA interagieren :

1. NDES-Dienstkonto
   Wird vom Network Device Enrollment Service für Gerätezertifikatsanforderungen verwendet.
   Erfordert „Zertifikate anfordern“ bei der Zertifizierungsstelle und Lesen/Registrieren von Vorlagen.
2. Automatische Registrierung von Clients
   Domänencomputer/Benutzer registrieren sich automatisch für Zertifikate.
   Fordern Sie „Zertifikate anfordern“ bei der Zertifizierungsstelle und Lesen, Registrieren (Automatisches Registrieren, falls verwendet) auf Vorlagen an.
3. Anwendungs-/Integrationskonten
   Wird von Apps/Diensten (z. B. SCEP) zur Zertifikatsautomatisierung verwendet.
   Sie müssen bei der Zertifizierungsstelle „Zertifikate anfordern“ und Vorlagen lesen/registrieren.
4. Administratoren
   Erfordert volle Kontrolle.
   Verwalten Sie CA und Vorlagen.

5. Stellen Sie sicher, dass Zertifikatvorlagen veröffentlicht und sichtbar sind

Wenn Ihre gewünschte Zertifikatvorlage nicht verfügbar ist, wird sie möglicherweise nicht veröffentlicht oder Ihr Konto ist nicht sichtbar. Öffnen Sie die Zertifizierungsstelle (certsrv.msc).

Klicken Sie mit der rechten Maustaste auf „Zertifikatvorlagen“ und wählen Sie „Neu“ > „Auszustellende Zertifikatvorlage“.

Wählen und veröffentlichen Sie die gewünschte Vorlage.

Von einem in die Domäne eingebundenen Client aus können Sie mit dem folgenden Befehl alle verfügbaren Vorlagen auflisten:

certutil -vorlage

Wird Ihre Vorlage nicht angezeigt, überprüfen Sie die Berechtigungen und den Veröffentlichungsstatus auf der Zertifizierungsstelle. Replikationsverzögerungen in Active Directory können die Sichtbarkeit neuer oder aktualisierter Vorlagen in verschiedenen Domänen oder Standorten beeinträchtigen, da Änderungen an der Zertifizierungsstelle oder an den Vorlagenberechtigungen einige Zeit benötigen, um übernommen zu werden und für alle Clients sichtbar zu sein.

So listen Sie alle derzeit von der Zertifizierungsstelle herausgegebenen (veröffentlichten) Vorlagen mithilfe von PowerShell auf:

Get-CATemplate

Dies erfordert das Modul CertificateServices, das auf der Zertifizierungsstelle oder einem Computer mit installiertem RSAT (Remote Server Administration Tools) ausgeführt werden muss.

6. Überprüfen Sie die Ereignisprotokolle auf CA-bezogene Fehler

Öffnen Sie auf dem CA-Server die Ereignisanzeige und navigieren Sie zum folgenden Speicherort:

Anwendungs- und Dienstprotokolle > Microsoft > Windows > CertificateServicesClient

Überprüfen Sie sowohl Betriebs- als auch Debug-Protokolle auf Fehler wie „Zugriff verweigert“, „RPC nicht verfügbar“, „Vorlage nicht gefunden“ oder „Registrierungsfehler“. Diese Protokolle weisen oft direkt auf Berechtigungsprobleme, Verbindungsfehler oder Fehlkonfigurationen hin.

Um einen umfassenden Überblick zu erhalten, prüfen Sie die Ereignisprotokolle sowohl auf dem CA-Server als auch auf den Clientrechnern. Clientseitige Protokolle können Probleme bei der Richtlinienanwendung, Registrierungsfehler oder Verbindungsprobleme aufdecken, die in den Protokollen der Zertifizierungsstelle möglicherweise nicht angezeigt werden. Für eine erweiterte Fehlerbehebung empfiehlt es sich, die ausführliche Protokollierung/Debug-Protokollierung für die Komponente „Zertifikatdienste“ (certsvc) zu aktivieren, indem Sie den folgenden Registrierungswert hinzufügen:

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
Wert: Diagnose
Typ: REG_DWORD
Daten: 0x0000ffff

Starten Sie nach dem Anwenden der Änderung die Zertifikatsdienste neu, um die detaillierte Protokollierung mithilfe von Powershell zu aktivieren:

Neustart-Dienst -Name CertSvc

7. Validieren Sie die Zertifikatskette und die CRL-Zugänglichkeit

Eine häufige Ursache für Kommunikationsprobleme ist eine unvollständige oder nicht vertrauenswürdige Zertifikatskette. Stellen Sie Folgendes sicher:

• Die Stamm- und Zwischenzertifikate der CA befinden sich in den entsprechenden Speichern „Vertrauenswürdige Stammzertifizierungsstellen“ und „Zwischenzertifizierungsstellen“.
• Auf die Endpunkte der Zertifikatsperrliste (Certificate Revocation List, CRL) kann von Clientgeräten und Integrationsservern aus zugegriffen werden.

Sie können Zertifikatsspeicher folgendermaßen überprüfen:

certlm.msc

Und überprüfen Sie die CRL-Zugänglichkeit mit:

certutil -verify -urlfetch

Ersetzen mit dem Pfad zu Ihrer Zertifikatsdatei. Um zusätzlich direkt zu bestätigen, dass CRL-Verteilungspunkte (CDPs) erreichbar sind, öffnen Sie die CRL-URL in einem Webbrowser oder verwenden Sie ein Tool wie curl:

curl -I http://

Eine erfolgreiche HTTP 200-Antwort zeigt an, dass auf die Zertifikatssperrliste zugegriffen werden kann. Dieser Schritt hilft, Firewall- oder DNS-Probleme auszuschließen, die die Erreichbarkeit der Zertifikatssperrliste beeinträchtigen und bei der Validierung zu Fehlern hinsichtlich der Vertrauenswürdigkeit oder Sperrung des Zertifikats führen können.

Um den Inhalt einer heruntergeladenen CRL zu analysieren, verwenden Sie den OpenSSL-Befehl:

openssl crl -in -noout -text

Dieser Befehl zeigt CRL-Metadaten, Sperreinträge und Informationen zum Aussteller an. Er hilft zu überprüfen, ob die CRL korrekt ausgestellt und aktuell ist.

Technische Auswirkungen von CRL- oder AIA-Fehlern:

Fehler beim Zugriff auf CRL- oder AIA-URLs können die Zertifikatsvalidierung stören und zu verschiedenen Betriebsproblemen führen. Diese entstehen typischerweise durch Probleme mit der DNS-Auflösung, Firewall-Blockierungen, Fehlkonfigurationen des HTTP-Proxys oder fehlende Veröffentlichungseinstellungen der Zertifizierungsstelle. Nachfolgend sind die wichtigsten technischen Manifestationen solcher Fehler aufgeführt:

1. Fehler bei der Validierung der Zertifikatskette
   Die Zertifikatsüberprüfung kann während der Kettenerstellung fehlschlagen und Fehler wie CERT_E_REVOCATION_FAILURE, CERT_E_CHAINING oder CERT_E_UNTRUSTEDROOT auslösen. Diese weisen auf Probleme beim Erreichen von Sperr- oder AIA-Endpunkten hin.
2. SCEP- und automatische Registrierungsfehler
   Registrierungsvorgänge können mit bestimmten Fehlercodes fehlschlagen, beispielsweise:
   • 0x80092013: Sperrserver offline
   • 0x80094800: Ungültige Zertifizierungsstelle
   Diese Fehler weisen darauf hin, dass der Widerrufsstatus oder die Autoritätsinformationen nicht abgerufen werden konnten.
3. TLS/SSL-Handshake-Fehler
   Clients können Serverzertifikate während TLS/SSL-Verhandlungen aufgrund unvollständiger Ketten oder nicht verfügbarer CRL/AIA-URLs ablehnen. Dies kann die sichere Kommunikation für Dienste wie HTTPS, LDAPS oder VPNs unterbrechen.
4. Ereignisprotokollindikatoren
   In den Protokollen der Windows-Ereignisanzeige können unter CertificateServicesClient oder Schannel relevante Einträge erfasst werden, die auf Timeouts bei der Sperrprüfung, Fehler beim Kettenaufbau oder Downloadfehler von CDP/AIA-URLs hinweisen.
5. OCSP- und CRL-Abruffehler
   Versuche, Sperrdaten über OCSP oder CRL abzurufen, können aus folgenden Gründen fehlschlagen:
   • Probleme mit der DNS-Auflösung
   • Falsche oder nicht erreichbare URLs
   • HTTP-Proxy-Einschränkungen
   • Fehlende oder falsch konfigurierte CA-Veröffentlichungen

Diese Probleme können Vertrauensvalidierungsprozesse unbemerkt unterbrechen, wenn sie nicht aktiv überwacht werden.

Checkliste zur schnellen Fehlerbehebung

Schritt	Befehl/Standort	erwartetes Ergebnis	Tipps zur Fehlerbehebung
CA-Dienststatus	Get-Service certsvc	Der Dienst wird ausgeführt	Falls der Dienst nicht ausgeführt wird, überprüfen Sie die Windows-Ereignisprotokolle auf Fehler. Versuchen Sie, den Dienst neu zu starten. Stellen Sie sicher, dass die Abhängigkeiten erfüllt sind.
Port-Konnektivität	Test-NetConnection -ComputerName -Anschluss 135	Die Verbindung ist erfolgreich	Wenn dies fehlschlägt, überprüfen Sie die Firewall-Einstellungen, die Netzwerkkonnektivität und ob RPC (Port 135) zwischen dem Client und der CA geöffnet ist.
CA-Ping	certutil -config – -ping	„Ping erfolgreich abgeschlossen.“	Wenn dies nicht erfolgreich ist, überprüfen Sie die Netzwerkkonnektivität, den CA-Dienststatus und die DNS-Auflösung des CA-Servers.
Vorlagensichtbarkeit	certutil -vorlage	Die Vorlage ist aufgeführt	Falls die Vorlage fehlt, stellen Sie sicher, dass sie auf der Zertifizierungsstelle veröffentlicht ist und die AD-Replikation abgeschlossen ist. Überprüfen Sie die Vorlagenberechtigungen.
Berechtigungen	certsrv.msc > Sicherheit	Erforderliche Berechtigungen werden erteilt	Wenn Berechtigungen fehlen, überprüfen Sie diese und weisen Sie Benutzern/Gruppen die erforderlichen Rechte zu. Prüfen Sie, ob Konflikte in den Gruppenrichtlinien vorliegen.
Ereignisprotokolle	Ereignisanzeige (gruppieren nach „Netzwerk“, „Dienst“, „Berechtigungen“, „Vorlagen“)	Keine RPC- oder Berechtigungsfehler	Wenn Fehler vorhanden sind, überprüfen Sie die Details auf Hinweise. Filtern Sie die Protokolle nach relevanten Fehlern. Beheben Sie Probleme gemäß den Fehlercodes.

Häufige Fehlercodes und ihre Bedeutung

Die folgende Tabelle fasst die in diesem Leitfaden erwähnten Fehlercodes und Meldungen zusammen, sodass Sie direkt zu einem bekannten Symptom springen können.

Fehler oder Meldung	Was es bedeutet	Wo Sie es sehen werden
„RPC-Server nicht verfügbar“	Der Client kann die Zertifizierungsstelle (CA) nicht über RPC erreichen. Die CA ist möglicherweise offline, nicht erreichbar oder durch eine Firewall blockiert.	certutil -config –ping
CERT_E_REVOCATION_FAILURE	Die Validierung der Kette konnte den Widerrufsstatus nicht bestätigen, da der CRL- oder OCSP-Endpunkt nicht erreichbar war.	Validierung der Zertifikatskette
CERT_E_CHAINING	Die Zertifikatskette konnte nicht aufgebaut werden, häufig aufgrund eines fehlenden Zwischenzertifikats.	Validierung der Zertifikatskette
CERT_E_UNTRUSTEDROOT	Das Stammzertifizierungsstellenzertifikat befindet sich nicht im Speicher der vertrauenswürdigen Stammzertifizierungsstellen.	Validierung der Zertifikatskette
0x80092013	Widerrufsserver offline. Der Client konnte den Widerrufsstatus während der Registrierung nicht abrufen.	SCEP und automatische Anmeldung
0x80094800	Ungültige Zertifizierungsstelle. Die CA-Referenz ist falsch konfiguriert oder nicht erreichbar.	SCEP und automatische Anmeldung
"Zugriff verweigert"	Dem Konto fehlen die Berechtigungen zum Anfordern von Zertifikaten bei der Zertifizierungsstelle bzw. zum Registrieren in der Vorlage.	Ereignisprotokoll des CertificateServicesClient
„Vorlage nicht gefunden“	Die angeforderte Vorlage ist auf der Zertifizierungsstelle nicht veröffentlicht, oder die AD-Replikation hat sie noch nicht weitergegeben.	Ereignisprotokoll des CertificateServicesClient / certutil -template
„Anmeldung fehlgeschlagen“	Ein allgemeiner Anmeldefehler, in der Regel ein Folgesymptom einer der oben genannten Ursachen.	Ereignisprotokoll des CertificateServicesClient

Validierungsprüfungen nach Behebung von Kommunikationsproblemen mit der Zertifizierungsstelle

Sobald Sie eine Lösung angewendet haben, vergewissern Sie sich, dass das Problem tatsächlich behoben wurde, bevor Sie es als abgeschlossen betrachten.

• Wiederholung Get-Service certsvc und bestätigen Sie, dass der Status „Wird ausgeführt“ lautet, und nicht nur, dass der Neustartbefehl fehlerfrei ausgeführt wurde.
• Wiederholung certutil -config --ping (oder das Drehbuch) certutil -config "<CAName>\<CACommonName>" -ping Formular) und bestätigen Sie eine erfolgreiche Ping-Antwort.
• Wiederholung Test-NetConnection -ComputerName <CA_SERVER> -Port 135 Um die RPC-Konnektivität zu bestätigen, wiederholen Sie den Vorgang für Port 445, falls SMB Teil des Problems war.
• Wiederholung certutil -template auf dem betroffenen Client überprüfen, ob die erwartete Vorlage nun angezeigt wird.
• Fordern Sie ein Testzertifikat mit der betroffenen Vorlage an und bestätigen Sie, dass es erfolgreich ausgestellt wird und nicht im Richtlinienmodul fehlschlägt.
• Prüfen Sie nach der Fehlerbehebung die Ereignisprotokolle von CertificateServicesClient und CertificationAuthority auf ein fehlerfreies Fenster ohne wiederkehrende Fehler.

Rückgängigmachungsschritte, falls eine Fehlerbehebung das Problem nicht behebt.

Falls eine Änderung die Situation verschlechtert oder Sie vor dem Fortfahren einen Rückzieher machen müssen, können Sie mit diesen Schritten die in diesem Leitfaden am häufigsten vorgenommenen Änderungen rückgängig machen.

• Wenn Sie die ausführliche Diagnoseprotokollierung auf der Zertifizierungsstelle aktiviert haben, setzen Sie den Registrierungswert wieder auf den vorherigen Wert (üblicherweise 0) zurück und führen Sie den Befehl aus. Restart-Service -Name CertSvc um wieder zu den normalen Protokollierungsstufen zurückzukehren.
• Wenn Sie Berechtigungen auf CA-Ebene oder Vorlagenebene geändert haben, stellen Sie die vorherige Zugriffskontrollliste aus Ihrer dokumentierten Basislinie wieder her, anstatt den vorherigen Zustand zu erraten.
• Wenn Sie eine Zertifikatvorlage aus der Veröffentlichung entfernt oder gelöscht haben, veröffentlichen Sie sie erneut über die Zertifikatvorlagen in der CA-Konsole unter Zertifikatvorlagen > Neu > Auszustellende Zertifikatvorlage.
• Falls eine Änderung der Firewall-Regeln Teil der Fehlerbehebung war und dadurch neue Probleme entstanden sind, sollte man auf den zuvor exportierten Regelsatz zurückgreifen, anstatt Regeln ad hoc zu löschen.
• Wenn ein Neustart des CA-Dienstes nicht geholfen hat und die CA vor einer kürzlichen Änderung funktionierte, sollten Sie erwägen, den CA-Server aus seinem letzten bekannten funktionierenden Backup wiederherzustellen, anstatt die Fehlersuche im laufenden Betrieb fortzusetzen.

Wie kann Encryption Consulting helfen?

Encryption Consulting unterstützt Unternehmen bei der Sicherung und Verwaltung von Microsoft-Zertifikatdiensten. Wir bieten klare Anleitungen zur Behebung von Kommunikationsproblemen, zur korrekten Einrichtung der PKI und zur Automatisierung von Zertifikatsprozessen mit CertSecure Manager . Gemeinsam mit unseren Kunden ermitteln wir die genaue Ursache von Problemen wie Diensteinstellungen, Zugriffsberechtigungen oder Netzwerkfehlern.

CertSecure Manager unterstützt dies, indem er vor Ablauf von Zertifikaten Warnmeldungen sendet, diese automatisch erneuert, um Ausfallzeiten zu vermeiden, und sich mit Active Directory verbindet, um die Unternehmensrichtlinien für die Zertifikatsnutzung einzuhalten. Es verwaltet alle Zertifikate an einem Ort, überwacht Änderungen und erledigt Aufgaben ohne ständige manuelle Arbeit. Dies ermöglicht eine stärker automatisierte Zertifikatsverwaltung.

Es gewährleistet die ordnungsgemäße Integration der Zertifizierungsstelle in die Unternehmenssysteme. Ob es sich um einen einmaligen Ausfall oder die Planung einer vollständigen PKI-Implementierung handelt – wir bieten die notwendige Unterstützung für den Betrieb einer zuverlässigen, konformen und skalierbaren Zertifikatsinfrastruktur.

Fazit

Mit diesen Schritten können Sie die meisten Kommunikationsprobleme mit Microsoft-Zertifizierungsstellen systematisch diagnostizieren und beheben. So stellen Sie sicher, dass Ihre PKI-Infrastruktur robust, sicher und in die Zertifikatsverwaltungsprozesse Ihres Unternehmens integriert bleibt. Die proaktive Überwachung und Prüfung des Zustands der Zertifizierungsstelle und der Zertifikatsnutzung helfen, Störungen zu vermeiden, Anomalien frühzeitig zu erkennen und die Einhaltung von Compliance-Vorgaben zu unterstützen. Sollten weiterhin Probleme auftreten, empfiehlt es sich, PKI-Experten für weiterführende Fehlerbehebung und Unterstützung zu kontaktieren.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus der Microsoft CA-Kommunikation?

Die wichtigste Erkenntnis ist, dass sich die meisten Kommunikationsprobleme mit Microsoft-Zertifizierungsstellen in sechs überprüfbare Bereiche einteilen lassen: Status des Zertifizierungsstellendienstes, Netzwerkports, Reaktionsfähigkeit der Zertifizierungsstelle, Berechtigungen des Dienstkontos, Sichtbarkeit der Zertifikatvorlage und Zugriff auf die Zertifikatskette bzw. die Sperrliste (CRL). Die Überprüfung dieser Bereiche in dieser Reihenfolge führt schneller zur Ursachenfindung als bloßes Raten.

Warum ist das für PKI-Teams in Unternehmen wichtig?

PKI-Teams in Unternehmen sind auf Active Directory-Zertifikatdienste angewiesen, um Zertifikate für Benutzer, Computer und Anwendungen auszustellen und zu erneuern. Wenn die Kommunikation mit der Zertifizierungsstelle unterbrochen wird, kommt es im gesamten Netzwerk zu einem Stillstand bei der Zertifikatsausstellung und -erneuerung. Daher ist ein systematischer Fehlerbehebungsprozess wichtiger als eine einzelne Lösung.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Die manuelle Bearbeitung von CA-Kommunikationsproblemen ohne Checkliste erhöht das Risiko, eine eigentliche Ursache zu übersehen, wie beispielsweise eine nicht veröffentlichte Vorlage oder einen blockierten RPC-Port, und eine Lösung anzuwenden, die nur ein Symptom anstatt des zugrunde liegenden Problems behandelt, wodurch der gleiche Fehler erneut auftreten kann.

Welche Teams sollten für diese Änderung verantwortlich sein?

Die Zuständigkeit erstreckt sich typischerweise über das Active Directory- oder PKI-Administrationsteam, das die Zertifizierungsstelle und die Zertifikatvorlagen verwaltet, das Netzwerkteam, das die Firewall-Regeln und den Portzugriff steuert, und das Sicherheitsteam, das die Berechtigungen auf Ebene der Zertifizierungsstelle und der Vorlagen überprüft.

Wie hängt das mit dem Zertifikatslebenszyklusmanagement zusammen?

Die Kommunikation mit der Zertifizierungsstelle (CA) ist die Grundlage für das Zertifikatslebenszyklusmanagement. Können Clients die CA nicht erreichen, keine Vorlage anfordern oder die Zertifikatskette und den Widerrufsstatus nicht überprüfen, funktioniert die Automatisierung von Ausstellung und Verlängerung nicht, selbst wenn die Lebenszyklusrichtlinie optimal gestaltet ist.

Wie sollten Organisationen ihren Erfolg messen?

Ein Erfolg zeigt sich beispielsweise durch einen fehlerfreien Durchlauf der Checkliste zur schnellen Fehlerbehebung, das Fehlen wiederholter RPC-, Berechtigungs- oder Vorlagenfehler in den Ereignisprotokollen CertificateServicesClient und CertificationAuthority sowie durch erfolgreiche Testregistrierungen für alle Zertifikatvorlagen, von denen Clients abhängen.

Was sollte regelmäßig geprüft oder überwacht werden?

Organisationen sollten regelmäßig den Status des CA-Dienstes, die Veröffentlichung und Berechtigungen der Zertifikatvorlagen, die Erreichbarkeit der CRL- und AIA-Endpunkte sowie die Ereignisprotokolle von CertificateServicesClient und CertificationAuthority auf wiederkehrende RPC-, Zugriffsverweigerungs- oder Widerrufsfehler überprüfen.

Welche Auswirkungen hat dieses Thema auf Cloud-, Hybrid- oder Multi-CA-PKI?

In hybriden Umgebungen können Kommunikationsprobleme mit Microsoft-Zertifizierungsstellen schwieriger zu isolieren sein, da Clients die Zertifizierungsstelle über VPNs, Cloud-basierte Domänencontroller oder mehrere ausstellende Zertifizierungsstellen erreichen können. Die gleiche Checkliste gilt weiterhin, jedoch muss jede Zertifizierungsstelle und jeder Netzwerkpfad einzeln getestet werden, anstatt von einem einheitlichen Verhalten auszugehen.

Welche Voraussetzungen müssen vor der Implementierung erfüllt sein?

Vor der Fehlerbehebung sollten Sie sicherstellen, dass Sie über administrative oder delegierte Zugriffsrechte auf den CA-Server und den betroffenen Client verfügen, dass auf beiden eine PowerShell-Sitzung mit erhöhten Rechten besteht, dass Sie Zugriff auf certsrv.msc und certtmpl.msc haben, dass Sie RSAT verwenden, wenn Sie Get-CATemplate remote ausführen, und dass eine dokumentierte Basislinie der aktuellen Berechtigungen und veröffentlichten Vorlagen vorhanden ist, auf die bei Bedarf zurückgegriffen werden kann.

Auf welche häufigen Fehler sollten Administratoren achten?

Administratoren sollten im Ereignisprotokoll CertificateServicesClient auf Einträge wie „RPC Server Unavailable“, „CERT_E_REVOCATION_FAILURE“, „CERT_E_CHAINING“, „CERT_E_UNTRUSTEDROOT“, „SCEP errors 0x80092013 and 0x80094800“ sowie „Access Denied“, „Template Not Found“ oder „Enrollment Failure“ achten.