(0) exportieren Drucken
Alle erweitern

Behandlung von PKI-Problemen unter Windows Vista

Betrifft: Windows Server 2008,Windows Vista

CAPI2-Diagnose ist ein Feature unter Windows Vista® und Windows Server® 2008. Mit diesem Feature können Administratoren Probleme mit der Public Key-Infrastruktur (Public Key Infrastructure, PKI) durch Sammeln ausführlicher Informationen zur Gültigkeitsprüfung von Zertifikatketten, zu Vorgängen in Zertifikatspeichern und zur Signaturverifizierung behandeln. Mit der CAPI2-Diagnose lässt sich die Fehlerursache der meisten PKI-Probleme leichter identifizieren. Mit der CAPI2-Diagnose kann die Diagnose von Problemen in kürzerer Zeit erfolgen, wodurch sich die Problembehandlung sehr viel einfacher gestaltet. Dieses Dokument enthält eine Beschreibung der CAPI2-Diagnose und wie es zur Behandlung einiger häufig auftretender PKI-Fehler verwendet werden kann.

Dieses Dokument herunterladen.

Diese Anleitung enthält die folgenden Themen

CAPI2 (Übersicht)

Eine Public Key-Infrastruktur (PKI) ist eine Kombination aus Kryptografie, Software, Vorgängen und Diensten, die es einem Unternehmen ermöglichen, seine Kommunikation und Geschäftstransaktionen zu sichern. X.509-Zertifikate können zum Identifizieren von Benutzern, Geräten oder Unternehmen und zum Aktivieren weiterer sicherer Anwendungen (z. B. signierten E-Mails, Codesignaturen und sicheres Suchen im Internet) verwendet werden.

CryptoAPI (CAPI) stellt die Kernkryptografie und die X.509-Zertifikatunterstützung unter Windows dar. CAPI1 bezieht sich auf die Unterstützung für grundlegende Kryptografiekomponenten wie Verschlüsselung, Entschlüsselung und Hashfunktionen. CAPI2 bezieht sich auf die Unterstützung für PKI- und X.509-Zertifikate wie Gültigkeitsprüfung von Zertifikatketten, Zertifikatspeicher und Signaturverifizierungen. Kryptografie-API: Next Generation (CNG), eine unter Windows Vista festgelegte neue Anwendungsprogrammierschnittstelle (Application Programming Interface, API), soll die vorhandene Verwendung von CAPI1 ersetzen, wobei CAPI1 nach wie vor unterstützt wird. In diesem Dokument wird die Behandlung von PKI-Fehlern mit CAPI2 erläutert; CNG und CAPI1 werden hier nicht berücksichtigt.

CAPI2 wird von Anwendungen zum Ausführen zahlreicher Aufgaben wie den folgenden aufgerufen:

  • Erstellen und Überprüfen von Zertifikatketten

  • Verwalten von Einzelbenutzer- und Einzelcomputer-Zertifikatspeichern

  • Verschlüsseln/Entschlüsseln und Codieren/Decodieren sowie Signieren/Überprüfen von Meldungen

Hintergrund

PKI-Probleme sind in zahlreichen PKI-fähigen Anwendungen schwierig zu behandeln. In vielen Anwendungen werden keine ausführlichen Fehlerinformationen angezeigt. So gibt CAPI2 beispielsweise bei vielen Fehlern im Zusammenhang mit dem Netzwerk einen Fehler Sperrung offline an die Anwendung zurück, der gleichzeitig als Fehlermeldung in der Anwendung angezeigt wird. Die allgemeine Art des gemeldeten Fehlers ist zwar erkennbar, es ist jedoch unklar, wie der Benutzer das PKI-Problem lösen kann. Die API-Signatur wurde so konzipiert, dass sie sowohl einen Fehlercode als auch eine Zeichenfolge zurückgibt. Da die API öffentlich ist, konnte die Funktion nicht so erweitert werden, dass sie detaillierte Informationen zurückgibt, ohne vorhandene Anwendungen außer Kraft zu setzen. Außerdem sind einige Fehler zu leistungsintensiv, um bei normalem Betrieb erkannt zu werden. Daher sollten sie bei der Nachbearbeitung behandelt werden.

Daher sind bessere Diagnosefunktionen für die PKI-Problembehandlung in CAPI2 erforderlich. Die CAPI2-Diagnose unter Windows Vista ermöglicht das Protokollieren detaillierter Informationen zur Zertifikatgültigkeitsprüfung, zu Netzwerkabrufen, zur Sperrung und anderen API-Ergebnissen und -Fehler auf niedriger Ebene. Diese verbesserte Funktion hilft beim Erkennen der Fehlerursache des PKI-Problems.

Für häufig im Zusammenhang mit PKI auftretende Fehler gibt es im Protokoll bestimmte Informationsmuster. Dieses Dokument enthält eine Übersicht über die CAPI2-Diagnose, unterstützt Sie bei der Interpretation des Protokolls und identifiziert Muster im Protokoll, die Fehlerszenarien entsprechen. Diese Informationen sollen bei der Diagnose von PKI-Problemen helfen und Entwicklern die Möglichkeit geben, Tools zum Behandeln häufig auftretender PKI-Probleme zu schreiben.

Überprüfen des Zertifikatpfads

Für die Problembehandlung bei PKI-fähigen Anwendungen, die CAPI2 verwenden, ist es sehr wichtig, den Vorgang der Überprüfung des Zertifikatpfads zu kennen. Als Beispiel dient eine Zertifikatkette wie in Abbildung 1 dargestellt. Die Stammzertifizierungsstelle stellt das Zertifikat der untergeordneten Zertifizierungsstelle aus, die wiederum das Endentitätszertifikat ausstellt. Die Stammzertifizierungsstelle und die untergeordnete Zertifizierungsstelle stellen separat Zertifikatsperrlisten aus. Die Zertifikatsperrlisten enthalten die Seriennummern der Zertifikate, die von der signierenden Zertifizierungsstelle gesperrt wurden.

Certificate Chain

Der erste Schritt beim Überprüfen des Zertifikatpfads besteht in dessen Ermittlung. Hiermit ist die Suche der Zertifikate der ausstellenden Zertifizierungsstelle für Endentitätszertifikate und die Erstellung eines Zertifikatpfads zu einem vertrauenswürdigen Stammzertifikat gemeint. Zertifikate von Zwischenzertifizierungsstellen sind als Teil des Anwendungsprotokolls enthalten oder werden von der Gruppenrichtlinie oder über URLs aufgenommen, die in der Erweiterung des Stelleninformationszugriffs (Authority Information Access, AIA) angegeben sind. Nach dem Erstellen des Pfads wird jedes Zertifikat im Pfad im Hinblick auf verschiedene Parameter wie Name, Uhrzeit, Signatur, Sperrstatus und andere Einschränkungen auf seine Gültigkeit überprüft.

Ausführliche Informationen zum Überprüfen des Zertifikatpfads finden Sie unter http://go.microsoft.com/fwlink/?LinkId=27081 (möglicherweise in englischer Sprache).

CAPI2-Diagnose unter Windows Vista

Die CAPI2-Diagnose ist ein Feature unter Windows Vista, das mithilfe der Ereignisprotokollierung und der Ereignisanzeige bessere Protokollierungs- und Problembehandlungsfunktionen für PKI-Anwendungen basierend auf dem CAPI2 API-Satz bereitstellt. Das Ereignisprotokollierungs- und -nachverfolgungssystem unter Windows Vista ermöglicht es Anwendungen, Komponenten und Treibern, schematisierte Ereignisse zu veröffentlichen, Protokolldateien abzufragen und Ereignisse zu abonnieren. Mit diesem System werden das Ereignisprotokollierungssystem und das Ereignisverfolgungsframework vereinigt. Die Ereignisprotokollierung stellt die erforderliche Funktion bereit, mit der Ereignisse durch Anwendungen strukturiert und klassifiziert werden können, sodass die Ereignisse vom Administrator einfacher organisiert und angezeigt werden können. Die Ereignisse werden im XML-Format protokolliert und können in der Ereignisanzeige angezeigt werden. Durch Protokollieren von Diagnoseinformationen in XML können automatisierte Problembehandlungstools einfacher geschrieben werden. Die Ereignisanzeige stellt die erforderliche Benutzeroberfläche bereit, um die Ereignisse anzuzeigen und basierend auf Parametern wie Quelle, Ebene und Schlüsselwörtern zu filtern.

Weitere Informationen zum Ereignisprotokollierungs- und -nachverfolgungssystem unter Windows Vista finden Sie unter http://go.microsoft.com/fwlink/?LinkId=82279 (möglicherweise in englischer Sprache).

CAPI2 Diagnostics in event viewer in Windows Vista

Erste Schritte mit der CAPI2-Diagnose

CAPI2-Ereignisse werden über den Microsoft-Windows-CAPI2-Kanal im Ereignisprotokoll aufgezeichnet. Die Ereignisse basieren auf der allgemeinen Kryptografie-API, die Teil der Überprüfung des Zertifikatpfads ist.

Aktivieren und Speichern des CAPI2-Protokolls

Im folgenden Verfahren werden Informationen zum Aktivieren der Protokollierung, dem Speichern oder Löschen des Protokolls und dem Erhöhen der Protokollgröße bereitgestellt. Der Administrator muss dazu folgendermaßen vorgehen:

Aktivieren und Speichern des CAPI2-Protokolls über die Benutzeroberfläche der Ereignisanzeige
  1. Öffnen Sie die Ereignisanzeige. Klicken Sie zum Öffnen der Ereignisanzeige imStartmenü auf Systemsteuerung, doppelklicken Sie auf Verwaltung, und doppelklicken Sie dann auf Ereignisanzeige.

  2. Wenn das Dialogfeld Benutzerkontensteuerung eingeblendet wird, bestätigen Sie die angegebene Aktion und klicken dann auf Weiter.

  3. Erweitern Sie im Konsolenbereich Ereignisanzeige, erweitern Sie Anwendungs- und Dienstprotokolle sowie Microsoft und Windows, und erweitern Sie anschließend CAPI2.

  4. Sie können nun die folgenden Aktionen ausführen:

    1. Klicken Sie zum Aktivieren der CAPI2-Protokollierung mit der rechten Maustaste auf Betriebsbereit, und wählen Sie dann Protokoll aktivieren aus.

    2. Klicken Sie zum Speichern des Protokolls in einer Datei mit der rechten Maustaste auf Betriebsbereit, und wählen Sie dann Ereignisse speichern unter aus. Die Protokolldatei kann im EVTX-Format (kann mit der Ereignisanzeige geöffnet werden) oder im XML-Format gespeichert werden.

    3. Klicken Sie zum Deaktivieren der CAPI2-Protokollierung mit der rechten Maustaste auf Betriebsbereit, und wählen Sie dann Protokoll deaktivieren aus.

    4. Wenn sich im Protokoll bereits Daten befinden, bevor Sie das Problem reproduziert haben, empfiehlt es sich, das Protokoll zu löschen. Dadurch werden nur die für das Problemszenario relevanten Daten im gespeicherten Protokoll erfasst. Klicken Sie zum Löschen des Protokolls mit der rechten Maustaste auf Betriebsbereit, und wählen Sie dann die Option Protokoll löschen aus.

    5. Die Standardgröße für das Ereignisprotokoll beträgt 1 MB. Bei der CAPI2-Diagnose kann die Größe des Protokolls in kurzer Zeit stark zunehmen. Daher sollten Sie die Protokollgröße auf mindestens 4 MB erhöhen, um wichtige Ereignisse zu erfassen. Klicken Sie zum Erhöhen der Protokollgröße mit der rechten Maustaste auf Betriebsbereit, und wählen Sie dann Eigenschaften aus. Erhöhen Sie in den Protokolleigenschaften die maximale Protokollgröße.

Sie können auch das Tool wevtutil.exe verwenden, um die Protokollierung zu aktivieren und das Protokoll zu speichern. Dieses Tool steht unter Windows Vista zur Verfügung.

So aktivieren Sie das CAPI2-Protokoll und speichern es mit "wevtutil.exe"
  1. Öffnen Sie eine Eingabeaufforderung als Administrator. Klicken Sie dazu auf die Schaltfläche Start, dann auf Alle Programme und anschließend auf Zubehör.

  2. Klicken Sie mit der rechten Maustaste auf Eingabeaufforderung, und klicken Sie auf Als Administrator ausführen.

  3. Wenn das Dialogfeld Benutzerkontensteuerung eingeblendet wird, bestätigen Sie die angegebene Aktion und klicken dann auf Weiter.

  4. Führen Sie an der Eingabeaufforderung die folgenden Befehle aus:

    1. Verwenden Sie zum Aktivieren der Protokollierung den Befehl wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true.

    2. Verwenden Sie zum Speichern des Protokolls in einer Datei den Befehl wevtutil.exe epl Microsoft-Windows-CAPI2/Betriebsdateiname.evtx.

    3. Verwenden Sie zum Deaktivieren der Protokollierung den Befehl wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:false.

    4. Verwenden Sie zum Löschen des Protokolls den Befehl wevtutil.exe cl Microsoft-Windows-CAPI2/Operational.

    5. Verwenden Sie zum Erhöhen der Protokollgröße den Befehl wevtutil sl Microsoft-Windows-CAPI2/Operational /ms:<Protokollgröße-in-Byte>.

Führen Sie wevtutil -? aus, um alle in diesem Tool verfügbaren Optionen anzuzeigen.

noteHinweis
Da die Ereignisprotokollierung die Leistung beeinträchtigen kann, sollte die Protokollierung nur beim Behandeln von Problemen aktiviert werden.

Ereignisse (Übersicht)

Bei der CAPI2-Diagnose werden Ereignisse für bestimmte ausgeführte Aufgaben protokolliert. Einige Ereignisse beziehen sich auf bestimmte APIs, die zum Ausführen der Aufgabe aufgerufen werden. Autoren von automatisierten Problembehandlungsanwendungen und erfahrene Entwickler können Informationen im Ereignis mit API- und Datenstrukturdokumentation auf MSDN referieren. Die Ereignisse sind als Ereignisse der obersten Ebene und untergeordnete Ereignisse organisiert, wobei letztere unter denen der obersten Ebene verschachtelt sind. Diese untergeordneten Ereignisse entsprechen internen Schritten und enthalten weitere Informationen zu den ausgeführten Aktionen sowie die Objekte, auf die als Teil der Ereignisse der obersten Ebene verweisen wird.

So sind beispielsweise an der Überprüfung des Zertifikatpfads die in der nachfolgenden Tabelle aufgeführten Ereignisse beteiligt.

Ereignisse beim Überprüfen des Zertifikatpfads

Ereignis Beschreibung

CertGetCertificateChain

Zeigt die Ergebnisse beim Erstellen einer Zertifikatkette an.

CertVerifyRevocation

Zeigt die Ergebnisse der Sperrüberprüfung an.

CryptRetrieveObjectByUrlWire

Protokolliert Details zum Aufrufen von Objekten wie Zertifikatsperrlisten oder OCSP-Antworten über das Netzwerk.

CertRejectedRevocationInfo

Enthält ausführliche Fehlerinformationen in Fällen, in denen von Windows ungültige Sperrinformationen abgerufen wurden.

X509Objects

Enthält Details zu allen als Teil der Überprüfung des Zertifikatpfads verarbeiteten Objekten.

Die untergeordneten Ereignisse sind so organisiert, da sie Schritte darstellen, die während eines Ereignisses der obersten Ebene mehrfach wiederholt werden können. So kann CertVerifyRevocation beispielsweise mehrfach im selben CertGetCertificateChain-Ereignis aufgerufen werden, um die Sperre verschiedener Zertifikate in der Kette zu überprüfen.

Die Liste der verschiedenen protokollierten Ereignisse und deren Beschreibung befindet sich in Anhang A.

Weitere Informationen zu diesen APIs finden Sie unter http://go.microsoft.com/fwlink/?LinkId=82278 (möglicherweise in englischer Sprache).

In CAPI2 werden ausführliche Informationen zum Ereignis im Abschnitt UserData der Ereignisdaten protokolliert. Diese können auf der Registerkarte Details in der Ereignisanzeige anzeigen. Bei APIs, die bedeutungsvolle erweiterte Fehler zurückgeben, werden in CAPI2 Fehlercodes und Beschreibungen im Ereignis in einem Ergebnisfeld als Teil der Ereignisdaten protokolliert. Außerdem werden in CAPI2 Flags mit einem Wertattribut, das sich auf den DWORD-Wert bezieht, sowie eine Liste mit booleschen Attributen protokolliert, die sich auf einzelne festgelegte Flags beziehen. Ein Beispiel dazu lautet folgendermaßen:

<ErrorStatus value="1000040" CERT_TRUST_REVOCATION_STATUS_UNKNOWN="true" CERT_TRUST_IS_OFFLINE_REVOCATION="true" />

Protokollieren von PKI-Objekten

Ausführliche Informationen zu PKI-Objekten wie Zertifikaten, Zertifikatssperrlisten und Online Certificate Status-Protokoll-Antworten (OSCP) sind für die Problembehandlung besonders wichtig. Bei CAPI2 werden die relevantesten Informationen in Zertifikaten und anderen PKI-Objekten in XML im X509Objects-Ereignis protokolliert.

Im Folgenden finden Sie ein Beispiel für einen Eintrag zu einem Zertifikat im X509Objects-Ereignis:


<Certificate fileRef="B18D64DA254B2E51F533193E36FF10E91A9198FC.cer" subjectName="ContosoRoot"> 
<Subject> 
<CN>ContosoRoot</CN> 
</Subject> <SubjectKeyID computed="true" hash="24CD7CB5D99A6734139189D3828DD11069397CF6" /> 
<Issuer> 
<CN>ContosoRoot</CN> </Issuer> <SerialNumber>49BAC183C61F688F4F237F306950C6A3</SerialNumber>
<NotBefore>2005-01-01T00:00:00Z</NotBefore> 
<NotAfter>2008-12-31T00:00:00Z</NotAfter> 
</Certificate>

Das Attribut fileRef enthält den Dateinamen, der den SHA1-Hash des Objekts gefolgt von der entsprechenden Dateinamenerweiterung (*.cer, *.crl oder *.bin) darstellt.

Auf X.509-Objekte wird häufig mehrfach verwiesen, selbst in einem einzigen Ereignis der obersten Ebene. So wird auf das Endentitätszertifikat beispielsweise in den Ereignissen CertGetCertificateChain, CertVerifyRevocation und CryptAIAUrlRetrievalWire verwiesen. In CAPI2 wird jeder Verweis auf die Objekte mit dem Attribut fileRef gefolgt vom Namen (z. B. subjectName bei Zertifikaten oder issuerName bei Zertifikatssperrlisten und OCSP-Antworten) protokolliert.

<Certificate fileRef="" subjectName=""> <CertificateRevocationList fileRef="" subjectName=""> <OCSPResponse fileRef="" subjectName="">

Im oben dargestellten Beispiel würde der Verweis folgendermaßen lauten:

<Certificate fileRef="B18D64DA254B2E51F533193E36FF10E91A9198FC.cer" subjectName="ContosoRoot">

Korrelierte Ereignisse

Die meisten Ereignisse verfügen über eine Start- und Stoppvariante. In CAPI2 wird ein leeres Startereignis, das lediglich Systeminformationen enthält, im Ereignisprotokoll protokolliert, um den Beginn des Ereignisses anzuzeigen. Die vollständigen Informationen, einschließlich Eingabeparameter, Ausgaben und weiteren Statusinformationen, werden im Stoppereignis protokolliert. Durch Gruppieren aller Informationen mit dem Stoppereignis müssen Sie weniger häufig nach anderen Ereignissen suchen.

Die Ereignisse weisen eine Hierarchie auf. Alle zusammengehörigen Ereignisse, die internen Funktionen entsprechen, die als Teile einer API der obersten Ebene aufgerufen werden, werden zwischen dem Start- und dem Stoppereignis entsprechend der API der obersten Ebene verschachtelt. Alle diese zusammengehörigen Ereignisse (z. B. alle Ereignisse, die Teil derselben Sequenz für die Überprüfung des Zertifikatpfads sind) werden im Protokoll durch einen allgemeinen Korrelationsaufgabenbezeichner gruppiert. Jedem Ereignis in der Sequenz ist eine Sequenznummer zugeordnet, die beim Ermitteln der Reihenfolge der Ereignisse in der Sequenz hilfreich ist.

Angenommen bei einer Überprüfung des Zertifikatpfads wird beispielsweise unter anderem der Sperrstatus aller Zertifikate in der Kette mit Ausnahme des Stammzertifikats überprüft. Zusätzliche Sperrinformationen können über das Netzwerk abgerufen werden. Bei einer der Sperrüberprüfungen tritt ein Fehler auf. Die verschachtelte Sequenz der Ereignisse im Protokoll ist folgendermaßen zusammengesetzt:

CertGetCertificateChainStart

  1. CertVerifyRevocationStart

    • CryptRetrieveObjectByUrlWireStart

    • CryptRetrieveObjectByUrlWire

  2. CertVerifyRevocation

  3. CertVerifyRevocationStart

    • CryptRetrieveObjectByUrlWireStart

    • CryptRetrieveObjectByUrlWire

    • CertRejectedRevocationInfo

  4. CertVerifyRevocation

CertGetCertificateChain

CertVerifyCertifcateChainPolicy

X509Objects

Jedes Ereignis weist denselben Korrelationsaufgabenbezeichner sowie eine Sequenznummer in ansteigender Reihenfolge auf. Das erste Ereignis in diesem Beispiel weist die folgenden Felder auf:

<CorrelationAuxInfo TaskId="{B679BF8C-B26E-401A-A35F-342C7753B6BA}" SeqNumber="9" />

Protokollierungsmodi

Bei der CAPI2-Diagnose werden Daten im Protokoll mithilfe von Features der Ereignisanzeige (z. B. Fehlerebene und Schlüsselwörter) gefiltert. Wenn Sie beispielsweise nach Fehlern im Zusammenhang mit der Pfadüberprüfung suchen möchten, können Sie nach der Ereignisebene Fehler (Ebene 2) und den Schlüsselwörtern Kette erstellen, Kettenrichtlinie überprüfen und Sperre filtern. Ereignisse werden als der Ebene 2 zugehörig markiert, wenn die API einen Fehler zurückgibt. Gibt die API keinen Fehler zurück, werden sie als der Ebene 4 zugehörig markiert.

Im Standardprotokollierungsmodus werden nur Ereignisse der Ebene 2 und 4 aufgezeichnet. Hierzu gehören Erfolgs- und Fehlerereignisse der obersten Ebene sowie untergeordnete Fehlerereignisse. Für eine detailliertere Protokollierung mit zusätzlichen Informationen zu den untergeordneten Ereignissen aktivieren Sie den ausführlichen Protokollierungsmodus. Im ausführlichen Modus sind Ereignisse mit Ausführlichkeitsebene 5 im Protokoll verfügbar. So befinden sich im ausführlichen Modus beispielsweise die Verknüpfungen zu den X.509-Binärobjekten im Protokoll. X.509-Objekte werden im Dateisystem unter %USERPROFILE%/AppData/LocalLow/Microsoft/X509Objects zwischengespeichert.

Dies wird folgendermaßen protokolliert:

<X509Objects> <Base path="F:\Users\abby\AppData\LocalLow\Microsoft\X509Objects"/>

Der ausführliche Modus ist für Vorgänge nützlich, bei denen selten Fehler auftreten (z. B. Speicher- und Zwischenspeichervorgänge), die aber manchmal hilfreiche Informationen zu anderen Ereignissen bieten. Wenn bei dem Vorgang ein Fehler auftritt, wird ein Fehlerereignis der Ebene 2 protokolliert, und das Ereignis steht im Standardprotokollierungsmodus zur Verfügung.

So aktivieren Sie den ausführlichen Modus
  1. Klicken Sie auf die Schaltfläche Start, klicken Sie auf Suche starten, geben Sie Ausführen ein, und drücken Sie dann die EINGABETASTE.

  2. Geben Sie unter Ausführen die Zeichenfolge regedit ein, und klicken Sie dann auf OK.

  3. Wenn das Dialogfeld Benutzerkontensteuerung eingeblendet wird, bestätigen Sie die angegebene Aktion und klicken dann auf Weiter.

  4. Navigieren Sie zu dem folgenden Registrierungsschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\crypt32.

  5. Fügen Sie einen 32-Bit-DWORD-Wert DiagLevel mit dem Wert 0x00000005 hinzu.

  6. Fügen Sie einen 64-Bit-QWORD-Wert DiagMatchAnyMask mit dem Wert 0x00ffffff hinzu.

Datenschutz

In diesem Abschnitt wird beschrieben, wie persönlich identifizierbare Informationen bei der CAPI2-Diagnose behandelt werden. Persönlich identifizierbare Informationen stellen Informationen dar, anhand derer Sie identifiziert oder mit denen Sie kontaktiert werden können. Administratoren sollten wissen, wie persönlich identifizierbare Informationen bei der CAPI2-Diagnose behandelt werden, damit gesetzliche oder firmeninterne Datenschutzrichtlinien eingehalten werden.

Die Informationen im CAPI2-Ereignisprotokoll enthalten neben den von der Ereignisanzeige protokollierten Ereignisdaten auch Daten zu den vom Benutzer, vom System und von Anwendungen verwendeten Zertifikaten. Die zu Diagnosezwecken protokollierten und wahrscheinlich persönlich identifizierbare Informationen darstellenden Daten schließen Folgendes ein:

  • Informationen in Zertifikaten, einschließlich des definierten X.500-Namens des Antragstellers und des Zertifikatausstellers. Je nach Anwendung können darin folgende Elemente enthalten sein:

    • E-Mail-Adressen, während der Überprüfung von signierten E-Mails

    • Dateinamen, während der Signaturverifizierung in Dateien

    • URLS von besuchten Websites als Teil der Überprüfung des Zertifikatpfads im SSL-Protokoll (Secure Sockets Layer)

  • URLs, auf die als Teil der Überprüfung des Zertifikatpfads zugegriffen wird, einschließlich Standorten zu Zertifikatsperrlisten und Zwischenzertifikaten

  • IP-Adressen wie die der Proxyserver, die bei Netzwerkdownloads kontaktiert werden

Die Protokollierung im Microsoft Windows-CAPI2-Kanal ist standardmäßig nicht aktiviert. Die Protokollierung kann nur von einem lokalen Administrator aktiviert bzw. deaktiviert und das Protokoll kann nur von einem Administrator gelesen werden. Ein Administrator kann das Protokoll in einer Datei speichern oder es zum Analysieren an Experten wie den Microsoft Premier Support senden.

Weitere Informationen zum Erfassen persönlich identifizierbarer Informationen durch die CAPI2-Diagnose und die Ereignisanzeige finden Sie unter http://go.microsoft.com/fwlink/?LinkID=34493 (möglicherweise in englischer Sprache).

Behandlung häufig auftretender Probleme

Nachdem die Protokollierung aktiviert, das Szenario reproduziert und das Protokoll erfasst wurde, müssen als nächstes die Daten aus dem Ereignisprotokoll interpretiert werden, um die Fehlerursache des Problems zu ermitteln. In diesem Abschnitt wird beschrieben, wie die CAPI2-Diagnose-Ereignisse beim Behandeln einiger häufig auftretender PKI-Probleme hilfreich verwendet werden können. Bei jedem Problemszenario erfahren Sie mehr über die Bedingungen des Szenarios und welche Ereignisse im Pfad Microsoft-Windows-CAPI2\Operational in der Ereignisanzeige protokolliert werden. Sie erfahren, wie Sie das Problem behandeln, indem Sie die folgenden Aufgaben ausführen:

  • Identifizieren und Korrelieren der relevanten Ereignisse

  • Einstufen des Fehlers basierend auf den Fehlerereignissen der oberster Ebene

  • Eingrenzen der Fehlerursache mithilfe der verschachtelten Ereignisse

  • Feststellen der Fehlerursache für den Fehler anhand der detaillierten Ereignisdaten

In CAPI2 werden Informationen in einem strukturierten XML-Format protokolliert, das für die automatisierte Problembehandlung entwickelt wurde. XPATH, eine Sprache zum Verweisen auf Teile eines XML-Dokuments, ist sehr nützlich zum Abfragen von Informationen in der CAPI2-Diagnose-Ereignisanzeige. XPATH kann für zum Abgleichen von Knoten (d. h. zum Überprüfen, ob ein Knoten einem bestimmten Muster entspricht) verwendet werden. Die Daten im Protokoll weisen ein spezielles Muster auf, das bestimmten Szenarien entspricht. So wird beispielsweise die Proxyliste protokolliert, wenn der Netzwerkabruf über einen Proxy erfolgt. Mit XPATH kann überprüft werden, ob ein Knoten mit einem Muster übereinstimmt, das auf das Vorhandensein einer Proxyliste hinweist. Diese Muster können mithilfe von XPATH-Ausdrücken beschrieben werden, die beim Auswerten zu einer Reihe von Knoten, die mit dem Ausdruck übereinstimmen, oder zu einem Wert wie einer Zeichenfolge, einer Zahl oder einem booleschen Wert führen.

Weitere Informationen zu XPATH finden Sie unter http://go.microsoft.com/fwlink/?LinkId=82280 (möglicherweise in englischer Sprache).

Folgende Probleme werden in diesem Abschnitt behandelt:

Authentifizierungsfehler beim Herstellen einer HTTP-Sitzung über SSL

Szenario

Sie stellen über HTTPS eine Verbindung mit einer Website an, indem Sie deren Adresse in Internet Explorer eingeben, z. B. https://www.contoso.com. Die Navigation wird dann von Internet Explorer mit dem Zertifikatfehler Das Sicherheitszertifikat dieser Website wurde nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt blockiert.

Navigation blocked due to certificate error

Wenn Sie dennoch zu der Website wechseln, wird der Zertifikatfehler rechts neben der Adressleiste angezeigt.

Certificate error indicated next to address bar

Als Teil der Ermittlung des Zertifikatpfads müssen die Zertifikate der ausstellenden Zertifizierungsstelle gefunden werden, damit der Zertifikatpfad erstellt werden kann. Diese Zertifikate können aus dem Cache oder dem Zertifikatspeicher auf dem Client abgerufen werden. Server können dem Client zusätzliche Informationen bereitstellen. Ein Beispiel für diese Technik ist SSL. Bei der SSL-Aushandlung stellt der Server dem Client sein eigenes Zertifikat und die Zwischenzertifikate bereit, die der Client zum Erstellen des Zertifikatpfads verwenden kann.

Für dieses Szenario gelten die folgenden Bedingungen:

  1. Das Zwischenzertifikat, das zum Erstellen des Zertifikatpfads für das Serverzertifikat erforderlich ist, befindet sich nicht im Cache oder im Zertifikatsspeicher des Clients.

  2. Als Teil der SSL-Aushandlung wird dem Client nur das Endentitäts-Serverzertifikat bereitgestellt. Im lokalen Zertifikatspeicher des Servers befindet sich kein gültiges Zwischenzertifikat, daher wird kein Zertifikat als Teil der SSL-Aushandlung bereitgestellt.

  3. Da lokal kein Zwischenzertifikat verfügbar ist und von der Anwendung auch kein Zwischenzertifikat bereitgestellt wird, wird das Zwischenzertifikat von CAPI2 mithilfe der Erweiterung des Stelleninformationszugriffs im Endentitätszertifikat aus dem Netzwerk abgerufen.

  4. Das Zertifikat befindet sich nicht an dem Netzwerkspeicherort, der in der Erweiterung des Stelleninformationszugriffs angegeben ist. Daher tritt beim Abrufen aus dem Netzwerk ein Fehler auf.

  5. Das Zwischenzertifikat kann nicht abgerufen werden. Daher kein Zertifikatpfad von einer vertrauenswürdigen Stammzertifizierungsstelle erstellt werden.

Diagnose

In der nachfolgenden Abbildung sind die in diesem Szenario protokollierten Ereignisse dargestellt.

Events logged for partial chain error
  1. Beginnen Sie mit der Problembehandlung, indem Sie sich das CertGetCertificateChain-Fehlerereignis (d. h. das Ereignis mit der Aufgabenkategorie Kette erstellen) ansehen. Der von der CertGetCertificateChain-API gemeldete Fehler wird in der Regel der Anwendung zurückgemeldet. Anhand des Prozessnamens in den Ereignisdaten kann das jeweilige Fehlerereignis leichter eingegrenzt werden. In diesem Fall ist Ihnen bekannt, dass Internet Explorer die Anwendung ist. Daher können Sie beim Abfragen der Ereignisse den entsprechenden Prozessnamen iexplore.exe verwenden. Ermitteln Sie alle zusammengehörigen Ereignisse, deren CorrelationAuxInfo-Werte dieselbe TaskId aufweisen. Auf diese Weise können Sie die Ereignisse eingrenzen, nach denen Sie suchen müssen, um die Ursache zu ermitteln.

CertGetCertificateChain event - partialchain error
  1. Klassifizieren Sie den Fehler, indem Sie sich die im CertGetCertificateChain-Ereignis protokollierten Statusflags ansehen. Anhand des Fehlerstatus können Sie die Ursache für den bei der Pfadüberprüfung ermitteln. Rufen Sie zum Ermitteln eines partiellen Kettenfehlers das CERT_TRUST_IS_PARTIAL_CHAIN-Flag ab. Beim Zertifikatpfad-Ermittlungsprozess werden Ausstellerzertifikate in den Zertifikatspeichern gesucht, und die Zertifikate werden von der Anwendung bereitgestellt. Das Feld AdditionalStore in den Ereignisdaten (Abbildung 6) enthält von der Anwendung bereitgestellte zusätzliche Zertifikate.

  2. In diesem Beispiel wird CAPI2 von der Anwendung nur das Endentitätszertifikat bereitgestellt. In CAPI2 wird versucht, das Ausstellerzertifikat mithilfe der Erweiterung des Stelleninformationszugriffs herunterzuladen. Dies wird durch das CertAIAUrlRetrievalWire-Ereignis dargestellt (Abbildung 7), das unter CertGetCertificateChain verschachtelt ist. Wenn Sie ein Problem beim Abrufen von Ausstellerzertifikaten aus dem Netzwerk ermitteln möchten, fragen Sie das CertAIAUrlRetrievalWire-Ereignis mit dem Ergebnis "nicht erfolgreich" (einem anderen Wert als 0) ab.

  3. Bei Abrufen aus dem Netzwerk ist das CryptRetrieveObjectByUrlWire-Ereignis (Abbildung 8) unter CertAIAUrlRetrievalWire verschachtelt. Wenn bei HTTPResponseHeadersInfo unter AdditionalInfo der Fehler 404 Nicht gefunden angezeigt wird, bedeutet dies, dass das Objekt am Speicherort nicht gefunden wurde. In diesem Fall befindet sich das Objekt nicht an dem Speicherort, der in der Erweiterung des Stelleninformationszugriffs im Endzertifikat angegeben ist. Diese Informationen können vom Attribut httpStatusCode im Element AuxInfo in diesem Ereignis abgefragt werden.

CertAIAUrlRetrievalWire event - partialchain error CryptRetrieveObjectByUrlWire event - partial chain

Auf ähnliche Art und Weise können anhand der HTTP-Statuscodeinformationen weitere HTTP-Fehler diagnostiziert werden. Diese Szenarien werden im Abschnitt HTTP-Fehler dieses Dokuments erläutert.

Fehler beim Anmelden mit einer Smartcard

Szenario

Sie versuchen, sich mit einer Smartcard bei einem Computer anzumelden. Bei der Anmeldung mit der Smartcard tritt jedoch ein Fehler auf. Anschließend stellen Sie den folgenden Fehler fest:

Smartcard logon failure

Bei einer Smartcard-Anmeldung findet eine gegenseitige Authentifizierung statt. Der Domänencontroller authentifiziert den Client, indem er das Zertifikat auf der Smartcard überprüft. Der Client authentifiziert den Domänencontroller, indem er eine Kette für dessen Zertifikat erstellt und es überprüft.

Für dieses Szenario gelten die folgenden Bedingungen:

  1. Die zum Überprüfen der Sperre des Domänencontrollerzertifikats erforderliche Zertifikatssperrliste befindet sich nicht im Cache oder im Speicher auf dem Client.

  2. Die Zertifikatssperrliste befindet sich nicht am Speicherort, der im Zertifikatsperrlisten-Verteilungspunkt im Endentitätszertifikat des Domänencontrollers angegeben ist.

  3. Bei der Sperrüberprüfung für das Endentitätszertifikat tritt ein Fehler auf. Folglich tritt bei der Überprüfung des Zertifikatpfads für das Domänencontrollerzertifikat ein Fehler auf. Da die Smartcard-Anmeldung nicht ausgeführt werden kann, müssen Sie sich mit Ihrem Benutzernamen und Kennwort beim Computer anmelden.

In der Fehlermeldung wird angegeben, dass der Fehler auf das Zertifikat des Domänencontrollers zurückzuführen ist. Die Überprüfung dieses Zertifikatpfads erfolgt auf dem Client. Daher müssen Sie die Protokollierung in der CAPI2-Diagnose auf dem Client aktivieren und den Fehler reproduzieren, um das Problem zu diagnostizieren.

Diagnose

In diesem Szenario werden die folgenden Ereignisse im Protokoll aufgeführt:

Events logged for smartcard logon failure
  1. Suchen Sie das CertGetCertificateChain-Fehlerereignis mit dem Prozessnamen lsass.exe, und ermitteln Sie alle korrelierten Ereignisse.

  2. Fragen Sie die Fehlerstatusflags des CertGetCertificateChain-Fehlerereignisses ab. Wenn keine gültigen Sperrinformationen abgerufen werden können, werden die Fehlerstatusflags CERT_TRUST_IS_OFFLINE_REVOCATION und CERT_TRUST_REVOCATION_STATUS_UNKNOWN festgelegt. Überprüfen Sie die Kettenelemente. Wenn ein Element dieses Flag aufweist, ist bei der Sperrüberprüfung für das entsprechende Kettenelement ein Fehler aufgetreten. Außerdem werden zu dem Kettenelement, bei dem der Fehler auftritt, weitere Informationen angezeigt (z. B. Antragstellername und Hash des Zertifikats, bei dessen Sperrüberprüfung ein Fehler aufgetreten ist).

  3. Entsprechend der Sperrüberprüfung ist das CertVerifyRevocation-Ereignis unter CertGetCertificateChain verschachtelt. Wenn bei der Sperrüberprüfung ein Fehler auftritt, wird vom CertVerifyRevocation-Ereignis ein Fehler gemeldet. Die Ursache dieses Fehlers kann anhand der unter CertVerifyRevocation verschachtelten Ereignisse identifiziert werden.

  4. Während der Sperrüberprüfung wird das CryptRetrieveObjectByUrlWire-Fehlerereignis bei jedem Netzwerkabruf unter CertVerifyRevocation verschachtelt. Ähnlich wie beim vorherigen Szenario können Sie die HTTP-Statuscodeinformationen verwenden, um die Ursache des Fehlers zu ermitteln. Der HTTP-Fehlercode 404 gibt an, dass das Objekt nicht gefunden wurde.

CertGetCertificateChain error - sc logon failure CryptRetrieveObjectByUrlWire error - sc logon fail

Andere Netzwerkfehler können auf ähnliche Art und Weise behoben werden. Mit den Ereignissen der obersten Ebene kann der Offlinesperrfehler und mit dem CryptRetrieveObjectByUrlWire-Fehlerereignis kann die Grundursache ermittelt werden.

Zertifikatwarnung in Microsoft Outlook beim Überprüfen einer signierten E-Mail

Szenario

Sie öffnen eine signierte E-Mail in Microsoft Outlook 2007. Wenn Sie nach dem Öffnen der Nachricht auf das Symbol für die digitale Signatur klicken, wird die folgende Warnung angezeigt:

Warning when verifiying signed email in Outlook

Für dieses Szenario gelten die folgenden Bedingungen:

  1. Die zum Überprüfen der Sperre des Signaturzertifikats erforderliche Zertifikatssperrliste befindet sich nicht im Cache oder im Speicher auf dem Client.

  2. Für den Clientcomputer besteht keine Verbindung mit dem Netzwerk. Daher kann die Zertifikatsperrliste nicht vom im Signaturzertifikat angegebenen Zertifikatsperrlisten-Verteilungspunkt heruntergeladen werden.

  3. Wenn die Zertifikatsperrliste nicht heruntergeladen werden kann, tritt ein Fehler Sperrung offline auf, und auf der Outlook-Benutzeroberfläche wird die Meldung angezeigt, dass die Zertifikatssperrliste, die zur Überprüfung des Signaturzertifikats benötigt wird, nicht verfügbar oder nicht mehr gültig ist.

Diagnose

In diesem Szenario werden die folgenden Ereignisse protokolliert:

Events logged for certificate warning in Outlook
  1. Suchen Sie das entsprechende Fehlerereignis für "Kette erstellen", und identifizieren Sie alle korrelierten Ereignisse. Verwenden Sie zum Eingrenzen der Suche nach bestimmten Fehlerereignissen den Prozessnamen (in diesem Fall outlook.exe).

  2. Bei der Überprüfung des Zertifikatpfads ist ein Fehler aufgetreten, da bei der Sperrüberprüfung für das Zertifikat ein Fehler aufgetreten ist. Grenzen Sie ähnlich wie im vorherigen Szenario den Sperrüberprüfungsfehler ein, indem Sie die Flags im CertGetCertificateChain-Ereignis abfragen. Sehen Sie sich die unter dem entsprechenden CertVerifyRevocation-Fehlerereignis verschachtelten Ereignisse an.

CertGetCertificateChain error - outlook warning
  1. Sehen Sie sich die im CertRejectedRevocationInfo-Fehlerereignis protokollierte Aktion an. Die Call_IsNetworkAlive-Aktion wird in diesem Szenario protokolliert. Der Fehler weist darauf hin, dass für den Computer keine Verbindung mit dem Netzwerk besteht, und der Computer die für die Zertifikatüberprüfung erforderlichen Sperrinformationen nicht abrufen kann.

Das CertRejectedRevocationInfo-Ereignis kann für die Diagnose zahlreicher Fehler im Zusammenhang mit einer fehlerhaften Überprüfung der Sperrinformationen (z. B. eine Zertifikatsperrliste oder eine OCSP-Antwort) nützlich sein. Die Ursache für diese Fehler kann durch Abfragen des entsprechenden Aktionsnamens im CertRejectedRevocationInfo-Fehlerereignis ermittelt werden. Weitere Diagnoseschritte weisen Ähnlichkeiten auf. Weitere Einzelheiten zu den verschiedenen Fehlerszenarien in dieser Fehlerklasse sowie zu deren Behebung finden Sie im Abschnitt Fehlerszenarien in diesem Dokument.

CertRejectedRevocationInfo - outlook warning

Diese Beispiele verdeutlichen, dass die CAPI2-Diagnose bei der Diagnose verschiedener Anwendungsfehler helfen kann, indem es Informationen zum Ermitteln der Fehlerursache bereitstellt.

Zum Anzeigen bestimmter Ereignisse im Ereignisprotokoll können Sie das Protokoll mithilfe der Ereignisanzeige manuell filtern. Anhang D enthält einige Beispiele zum Filtern mit der Ereignisanzeige. Wenn Sie das Protokoll in einer XML-Datei speichern, können Sie XPATH-Abfragen in den Code schreiben, um die Daten im Protokoll abzufragen. Beispielabfragen finden Sie in Anhang B. Anhang C enthält ein Beispiel für einen C#-Codes, der die Ermittlung der Ursache von Fehlern mithilfe der XPATH-Abfragen demonstriert.

Fehlerszenarien

In diesem Abschnitt sind die verschiedenen Fehlerszenarien beschrieben, und es werden Schritte zum Beheben dieser Fehler basierend auf den Informationen im CAPI2-Diagnose-Ereignisprotokoll aufgezeigt.

Fehler bei der Pfadüberprüfung

In CAPI2 werden Fehler bei der Zertifikatpfadüberprüfung im CertGetCertificateChain-Fehlerereignis protokolliert. Diese Fehler können durch Abfragen des ErrorStatus-Flags im CertificateChain-Element im CertGetCertificateChain-Fehlerereignis diagnostiziert werden. In der nachstehenden Tabelle sind einige häufig auftretende Fehler bei der Überprüfung des Zertifikatpfads aufgeführt.

Fehler bei der Pfadüberprüfung

ErrorStatus-Flag Beschreibung

CERT_TRUST_IS_NOT_TIME_VALID

Das Endentitätszertifikat oder eines der Zertifikate in der Kette ist abgelaufen. Weitere Informationen zum Zertifikat und dessen Gültigkeit finden Sie im X509Objects-Ereignis.

CERT_TRUST_IS_NOT_SIGNATURE_VALID

Die Signatur für das Endentitätszertifikat oder eines der Zertifikate in der Kette kann nicht überprüft werden.

CERT_TRUST_IS_REVOKED

Das Endentitätszertifikat oder eines der Zertifikate in der Kette ist gesperrt. Der Sperrgrund kann den Ereignisdaten entnommen werden.

CERT_TRUST_IS_NOT_VALID_FOR_USAGE

Das Zertifikat wird für einen anderen Zweck als seine erweiterte Schlüsselverwendung (Extended Key Usage, EKU) verwendet. Die EKU und die Anwendungsnutzungsinformationen können dem CertGetCertificateChain-Fehlerereignis entnommen werden.

CERT_TRUST_IS_UNTRUSTED_ROOT

Die Zertifikatkette wurde bis zu einer Stammzertifizierungsstelle erstellt. Das Zertifikat der Stammzertifizierungsstelle befindet sich jedoch nicht im Speicher der vertrauenswürdigen Stammzertifizierungsstelle auf dem Computer.

CERT_TRUST_IS_CYCLIC

Die Zertifikatkette ist zyklisch, was bedeutet, dass eines der Zertifikate in der Kette von einer Zertifikatstelle ausgestellt wurde, die vom ursprünglichen Zertifikat zertifiziert wurde.

CERT_TRUST_IS_REVOCATION_UNKNOWN

Der Sperrstatus des Endentitätszertifikats oder eines der Zertifikate in der Kette ist unbekannt. Weitere Informationen zu Fehlern bei der Sperrüberprüfung finden Sie im Abschnitt Fehler aufgrund einer fehlerhaften Sperrüberprüfung in diesem Dokument.

CERT_TRUST_IS_OFFLINE_REVOCATION

Der Sperrstatus des Endentitätszertifikats oder eines der Zertifikate in der Kette ist offline oder nicht mehr aktuell. Der Grund dafür ist häufig ein Netzwerkproblem. Weitere Informationen zu Fehlern bei der Sperrüberprüfung finden Sie im Abschnitt Fehler aufgrund einer fehlerhaften Sperrüberprüfung in diesem Dokument.

CERT_TRUST_IS_PARTIAL_CHAIN

Die Zertifikatkette ist unvollständig. Ein Fehler bei dem Ermitteln des Zertifikatpfads führt zu einem unvollständigen Zertifikat. Weitere Informationen finden Sie im Abschnitt Fehler beim Ermitteln des Zertifikatpfads in diesem Dokument.

Bestimmte Pfadüberprüfungsfehler wie partielle Kettenfehler oder Sperrüberprüfungsfehler können durch unterschiedliche Probleme wie Netzwerkfehler, ungültige Objekte oder falsche Konfiguration verursacht werden. In den nachfolgenden Abschnitten sind diese Fehlerszenarien beschrieben, die häufig die Ursache für andere Probleme darstellen.

Fehler beim Netzwerkabruf

Viele PKI-Probleme sind auf einen Netzwerkfehler zurückzuführen. So können Fehler beim Netzwerkabruf beispielsweise beim Abrufen verschiedener Objekttypen wie Zertifikatsperrlisten, OCSP-Antworten und Ausstellerzertifikaten mithilfe der Erweiterung des Stelleninformationszugriffs auftreten. Daher können Fehler beim Herunterladen aus dem Netzwerk zu Fehlern bei der Sperrüberprüfung oder der Zertifikatpfadermittlung führen. Netzwerk-Fehlerszenarien können außerdem folgendermaßen klassifiziert werden:

HTTP-Fehler

In diesem Abschnitt sind mögliche HTTP-Fehler wie die folgenden aufgeführt und beschrieben:

Objekt nicht gefunden

Beim Herunterladen der Zertifikatsperrliste tritt ein Fehler auf, wenn sie sich nicht an dem in der Zertifikatsperrlisten-Verteilungspunkt-Erweiterung im Zertifikat angegebenen Ort befindet. Ebenso tritt beim Herunterladen des Ausstellerzertifikats ein Fehler auf, wenn es sich nicht am Speicherort in der Erweiterung des Stelleninformationszugriffs befindet. Wenn das Objekt nicht gefunden wird, wird der HTTP-Statuscode 404 zurückgegeben. Dies kann aus dem Feld httpStatusCode im CryptRetrieveObjectByUrlWire-Ereignis in entnommen werden. Mit httpStatusCode können ähnliche HTTP-Szenarien diagnostiziert werden. Einige davon sind in den folgenden Unterabschnitten beschrieben.

Zugriff verweigert

Wenn der Zugriff auf das Objekt auf dem Server verweigert wird, wird der HTTP-Antwortstatus 401 zurückgegeben. Fragen Sie zum Identifizieren dieses Fehlers die HTTP_STATUS_DENIED-Aktion im CryptRetrieveObjectByUrlWire-Fehlerereignis ab. Die URL des Servers wird im selben Fehlerereignis protokolliert. Dieser Fehler weist auf einen Authentifizierungsfehler auf dem Server hin.

Vom Webserver nicht zugelassene Methode

Wenn die HTTP-Methode, mit der Informationen vom Server angefordert werden, vom Server nicht zugelassen wird, wird der HTTP-Statuscode 405 zurückgegeben, der auf diesen Fehler hinweist. Dies kann durch Suchen nach dem Feld httpStatusCode mit dem Wert 405 in CryptRetrieveObjectByUrlWire abgefragt werden. Ein Beispiel für dieses Szenario ist eine Anforderung für eine OCSP-Antwort in CAPI2. In CAPI2 wird zuerst eine GET-Methode ausgeführt. Tritt bei GET ein Fehler auf, wird die POST-Methode verwendet. Wenn der Server POST nicht unterstützt, gibt er einen HTTP 405-Fehler zurück.

Proxyauthentifizierung ist erforderlich

Ein weiteres mit den HTTP-Statuscodes identifizierbares Szenario ist der Fehler bei der Proxyauthentifizierung. Dieser ähnelt dem Fehler Zugriff verweigert. Der Unterschied besteht darin, dass der Authentifizierungsfehler auf dem Proxyserver auftritt, mit dem auf die Webressource zugegriffen wird und dieser den HTTP-Statuscode 407 zurückgibt. Fragen Sie zum Identifizieren dieses Fehlers den Aktionsnamen HTTP_STATUS_PROXY_AUTH_REQ im CryptRetrieveObjectByUrlWire-Ereignis ab. Dieses Fehlerszenario tritt lediglich bei bestimmten Konfigurationen auf, beispielsweise wenn der Proxy die integrierte Windows-Authentifizierung nicht unterstützt oder wenn der Benutzer oder der Computer nicht berechtigt ist, über den Proxy auf das Internet zuzugreifen. Weitere Informationen finden Sie unter http://go.microsoft.com/fwlink/?LinkId=82288 (möglicherweise in englischer Sprache).

Andere HTTP-Fehler

Andere HTTP-Fehler können auf ähnliche Art und Weise durch Anzeigen des HTTP-Statuscode im CryptRetrieveObjectByUrlWire-Ereignis identifiziert werden. Weitere Informationen finden Sie unter http://go.microsoft.com/fwlink/?LinkId=82289 (möglicherweise in englischer Sprache).

Zeitüberschreitungsfehler

Bei jeder Anforderung an den Webserver zum Abrufen eines Objekts ist mit dem Abruf aus dem Netzwerk ein Zeitlimit verbunden. Das Standardzeitlimit beträgt 15 Sekunden. Dieser Wert kann jedoch über die Gruppenrichtlinien konfiguriert oder von der Anwendung festgelegt werden. Wird das Objekt nicht innerhalb dieses Zeitlimits abgerufen, wird die NetworkRetrievalTimeout-Aktion im CryptRetrieveObjectByUrlWire-Ereignis protokolliert.

Das Objekt ist zu groß

Ein Szenario, in dem eine Zeitüberschreitung stattfinden kann, liegt dann vor, wenn das herunterzuladende Objekt zu groß ist und daher nicht innerhalb des Zeitlimits heruntergeladen werden kann. In CAPI2 wird automatisch ein Hintergrundthread zum Abrufen von Objekten gestartet. Wenn der Abrufvorgang nicht innerhalb des Zeitlimits abgeschlossen werden kann, wird der ursprüngliche Vordergrundthread mit dem Fehler NetworkRetrievalTimeout beendet. Der Download wird jedoch im Hintergrundthread abgeschlossen. Nachdem der Download abgeschlossen ist, wird ein CryptRetrieveObjectByUrlWire-Ereignis mit der PendingNetworkRetrievalComplete-Aktion protokolliert. Mit diesem Ereignis wird auch das abgerufene Objekt aufgezeichnet.

Stellen Sie sich als Beispiel ein Szenario vor, bei dem eine Smartcard-Anmeldung erfolgt. Bei der Anmeldung tritt ein Fehler auf, da beim Herunterladen der Zertifikatsperrliste das Zeitlimit überschritten wird. Wenn Sie nach einiger Zeit erneut versuchen, sich anzumelden, ist die Anmeldung erfolgreich, da der Download der Zertifikatsperrliste im Hintergrund abgeschlossen wurde.

So diagnostizieren Sie diesen Fehler anhand des Ereignisprotokolls

  1. Suchen Sie das CryptRetrieveObjectByUrlWire-Fehlerereignis mit der protokollierten NetworkRetrievalTimeout-Aktion.

  2. Ermitteln Sie die URL, bei der das Zeitlimit des Downloads überschritten wurde, im URL-Element dieses Fehlerereignisses.

  3. Suchen Sie im Protokoll nach einem weiteren CryptRetrieveObjectByUrlWire-Ereignis mit demselben URL-Elementwert, zu dem eine PendingNetworkRetrievalComplete-Aktion protokolliert wurde. Dies entspricht dem Hintergrundthread. Dieser verfügt über eine separate CorrelationAuxInfo-TaskId aus dem Vordergrundthread, der die Pfadüberprüfung vornimmt.

  4. Der Ergebniswert 0 bedeutet, dass der Hintergrundthread erfolgreich abgeschlossen wurde.

noteHinweis
Wenn der Aufrufprozess beendet wird, bevor der Hintergrundthread den Download abschließt, wird das Fehlerereignis mit PendingNetworkRetrievalComplete nicht protokolliert.

Zeitüberschreitung der Anforderung

Das Zeitlimit für eine Anforderung an den Server zum Abrufen eines Objekts kann in verschiedenen Szenarien wie den folgenden überschritten werden:

  • Der Server ist nicht online und reagiert nicht auf die Anforderung.

  • Zeitüberschreitung des DNS-Servers.

  • Der Proxy reagiert nicht.

  • Die automatische Proxyermittlung wird langsam ausgeführt, was zu einer Zeitüberschreitung führt.

In diesen Szenarien wird die NetworkRetrievalTimeout-Aktion des CryptRetrieveObjectByUrlWire-Fehlerereignisses protokolliert, wodurch angegeben wird, dass das Zeitlimit überschritten wurde. Der Hintergrundthread kann das Objekt jedoch auch nicht abrufen. Beim Ereignis mit der PendingNetworkRetrievalComplete-Aktion wird der Fehler so protokolliert, wie er von der zugrunde liegenden Netzwerkkomponente gemeldet wurde. Wenn beispielsweise keine Verbindung mit dem HTTP-Server hergestellt werden kann, wird eine Call_WinHttpSendRequest-Aktion mit dem Fehlerwert 2EFD protokolliert. Dieser Wert stellt den Hexadezimalwert für die Fehlermeldungskonstante ERROR_WINHTTP_CANNOT_CONNECT dar.

Gehen Sie zur Diagnose dieses Fehlers ähnlich vor wie im Abschnitt Das Objekt ist zu groß beschrieben. Der Unterschied besteht hier darin, dass das Fehlerereignis mit PendingNetworkRetrievalComplete im Ergebniselement einen anderen Wert als 0 aufweist. Fragen Sie zum Identifizieren der Fehlerursache die Aktion ab, die sich auf den zugrunde liegenden API-Fehler bezieht (wie Call_WinHttpSendRequest im obigen Beispiel). Wenn außerdem eine Aktion mit dem Präfix Call_ protokolliert wird, bezieht sie sich auf den Aufruf einer zugrunde liegenden fehlerhaften API. So weist Call_WinHttpSendRequest beispielsweise darauf hin, dass beim Aufrufen von WinHttpSendRequest ein Fehler aufgetreten ist. Der von dieser API zurückgegebene Fehlercode wird ebenfalls protokolliert.

Erhöhen der Zeitüberschreitung

Wenn das Zeitlimit überschritten wurde und der Abruf anschließend erfolgreich im Hintergrund ausgeführt wird, bedeutet dies, dass es sich um ein großes Objekt handelt oder eine langsame Netzwerkverbindung die Zeitüberschreitung verursacht hat. Sie können dieses Problem beheben, indem Sie die standardmäßige Zeitüberschreitung für den Abruf aus dem Netzwerk erhöhen. Wenn Ihnen die Größe des Objekts und die Bandbreite bekannt sind, können Sie die Zeit einschätzen, die der Download in Anspruch nehmen wird. Die Größe des Objekts finden Sie im Kopfzeilenfeld Content-Length im Element HTTPResponseHeadersInfo in den Daten des CryptRetrieveObjectByUrlWire-Ereignisses.

Im nachfolgenden Verfahren sind die Schritte zum Erhöhen der Abrufzeitüberschreitung beschrieben.

So erhöhen Sie die Abrufzeitüberschreitung:
  1. Klicken Sie auf Start, klicken Sie auf Suche starten, geben Sie mmc ein, und drücken Sie dann die EINGABETASTE.

  2. Wenn das Dialogfeld Benutzerkontensteuerung eingeblendet wird, bestätigen Sie die angegebene Aktion und klicken dann auf Weiter.

  3. Klicken Sie im Menü Datei auf Snap-In hinzufügen/entfernen.

  4. Gehen Sie unter Snap-Ins hinzufügen bzw. entfernen folgendermaßen vor:

    1. Wenn Sie das Gruppenrichtlinienobjekt für den lokalen Computer bearbeiten, klicken Sie auf Editor für lokale Gruppenrichtlinien, klicken Sie auf Hinzufügen und anschließend auf Fertig stellen.

    2. Wenn Sie das Gruppenrichtlinienobjekt für die Domäne bearbeiten, klicken Sie auf die Gruppenrichtlinien-Verwaltungskonsole, klicken Sie auf Hinzufügen und anschließend auf Fertig stellen. Doppelklicken Sie in der Konsolenstruktur in der Gesamtstruktur und Domäne, die das zu bearbeitende Gruppenrichtlinienobjekt Standarddomänenrichtlinie enthält, auf Gruppenrichtlinienobjekte. Klicken Sie mit der rechten Maustaste auf das Gruppenrichtlinienobjekt Standarddomänenrichtlinie, und klicken Sie dann auf Bearbeiten.

    3. Wenn Sie der Konsole keine weiteren Snap-Ins hinzufügen möchten, klicken Sie auf OK.

  5. Erweitern Sie in der Konsolenstruktur je nach der Auswahl im vorherigen Schritt Lokale Sicherheitsrichtlinie oder Standarddomänenrichtlinie. Erweitern Sie Computerkonfiguration, erweitern Sie Windows-Einstellungen und Sicherheitseinstellungen, klicken Sie auf Richtlinien öffentlicher Schlüssel, und wählen Sie Einstellungen für die Überprüfung des Zertifikatpfades aus.

  6. Wählen Sie die Registerkarte Netzwerkabruf aus.

  7. Wählen Sie die Option Standardwert für URL-Abrufzeitüberschreitung (in Sekunden) im Abschnitt Einstellungen für den Standardwert der Abrufzeitüberschreitung aus.

  8. Geben Sie den gewünschten Wert für die Zeitüberschreitung ein.

  9. Klicken Sie auf Übernehmen, um die neuen Einstellungen zu übernehmen.

Fehler beim Herstellen der Verbindung über einen Proxyserver

Wenn die Verbindung mit dem Netzwerk über einen Proxyserver hergestellt wird, muss dieser ordnungsgemäß konfiguriert sein. Wenn der Proxyserver falsch konfiguriert ist, tritt beim Abrufen der Sperrinformationen über das Netzwerk ein Fehler auf. Dieses Szenario kann durch Anzeigen der im CryptRetrieveObjectByUrlWire-Ereignis gespeicherten Daten ermittelt werden. Wenn ein Proxy verwendet wird, enthält es eine ProxyListAndBypass-Aktion gefolgt von der Proxyliste. Wenn lokal kein Proxy konfiguriert wurde, enthält es die NoProxy-Aktion.

Wenn der Proxyserver falsch ist, wird eine BadProxy-Aktion in den Daten des CryptRetrieveObjectByUrlWire-Ereignisses protokolliert. Hierauf folgt die Systemfehlermeldung, in der der Fehler erläutert wird. Wenn DNS beispielsweise einen Fehler meldet, da der DNS-Name des Proxyservers nicht aufgelöst werden kann, wird eine Call_WinHttpSendRequest-Aktion mit dem Fehlercode 2EE7 protokolliert. Dieser stellt den Hexadezimalwert für die Fehlerkonstante ERROR_WINHTTP_NAME_NOT_RESOLVED dar. Wenn die Verbindung mit dem Proxyserver nicht hergestellt werden kann, wird eine Call_WinHttpSendRequest-Aktion mit dem Fehlercode 2EFD protokolliert. Dieser stellt den Hexadezimalwert für die Fehlerkonstante ERROR_WINHTTP_CANNOT_CONNECT dar.

Jedes Mal, wenn eine Netzwerkverbindung über einen Proxyserver hergestellt wird, enthält das Protokoll die Liste der Proxyserver und der Umgehungsorte. Dies wird im CryptRetrieveObjectByUrlWire-Ereignis im ProxyListAndBypassList-Aktionselement protokolliert. Das Parameterattribut dieser Aktionselemente listet die Proxyserver und die Umgehungsorte auf. BadProxy weist im Allgemeinen auf ein Problem mit dem ersten Proxy in der Liste hin.

LDAP-Fehler

Beim Abrufen von Objekten mithilfe von Lightweight Directory Access Protocol (LDAP) ähneln manche Fehler denen in anderen Netzwerkabruf-Szenarien. Es können jedoch zusätzliche, für LDAP spezifische Fehler auftreten.

Jedes Mal, wenn eine LDAP-URL ermittelt wird, wird die URL zuerst in CAPI2 analysiert, um die verschiedenen Komponenten zu identifizieren. Tritt bei diesem Vorgang ein Fehler auf, wird CrackLdapUrl im CryptRetrieveObjectByUrl-Fehlerereignis protokolliert.

Fehler können in verschiedenen Phasen des LDAP-Verbindungsvorgangs auftreten. In CAPI2 werden verschiedene LDAP-APIs aufgerufen, um die Verbindung herzustellen und das Objekt herunterzuladen. In Abhängigkeit davon, bei welcher API ein Fehler auftritt, wird ein Fehlerereignis mit einem Aktionsnamen protokolliert, das den API-Namen mit dem Präfix Call_ enthält. Der von der LDAP-API zurückgegebene Fehlercode wird ebenfalls protokolliert, was beim Identifizieren der Fehlerursache hilfreich sein kann. In Abhängigkeit davon, bei welcher LDAP-API ein Fehler auftritt, kann das Protokoll die Aktionen Call_ldap_connect, Call_ldap_bind oder Call_ldap_search enthalten.

Weitere Fehler beim Netzwerkabruf

In diesem Abschnitt sind weitere Fehler beim Netzwerkabruf beschrieben. Dazu gehören beispielsweise die folgenden:

Fehler beim Abrufen von Inhalt des Objekts

Beim Abrufen eines Objekts aus dem Netzwerk wird die CryptQueryObject-Funktion aufgerufen, um Informationen zum Inhalt des Objekts abzurufen. Tritt dabei ein Fehler auf, wird in CAPI2 ein CryptRetrieveObjectByUrlWire-Fehlerereignis mit der Call_CryptQueryObject-Aktion sowie ausführlichen Informationen zu diesem Fehler protokolliert. Wenn beispielsweise die Zertifikatsperrliste beschädigt ist und nicht decodiert werden kann, wird dieser Fehler protokolliert. Beachten Sie, dass die Decodierung von OCSP-Antworten separat von diesem Schritt erfolgt. Weitere Informationen finden Sie im Abschnitt Decodieren der OCSP-Antwort nicht möglich in diesem Dokument.

Fehler beim Herstellen einer Verbindung mit dem Server

Dieses Fehlerszenario bezieht sich auf einen Fehler beim Herstellen der Verbindung mit dem Server, der aufgrund folgender Probleme auftreten kann:

  • Der Server ist nicht online.

  • Die angegebene URL ist falsch.

  • Die URL verweist auf eine falsche IP-Adresse.

Die CryptRetrieveObjectByUrl-API ruft die WinHttpSendRequest-API auf, um eine Anforderung für die Zertifikatsperrliste an den HTTP-Server zu senden. Wenn in diesem Szenario die Verbindung mit dem Server nicht hergestellt werden kann, tritt bei WinHttpSendRequest der Fehler ERROR_WINHTTP_CANNOT_CONNECT auf. Der Fehler wird im CryptRetrieveObjectByUrlWire-Ereignis als Aktionselement mit der Bezeichnung Call_WinHttpSendRequest und dem Fehlerwert 2EFD protokolliert. Dieser entspricht dem Hexadezimalwert für die Fehlermeldungskonstante ERROR_WINHTTP_CANNOT_CONNECT.

Protokoll wird nicht unterstützt

Wenn das in der URL angegebene Protokoll beim Abrufen eines Objekts nicht unterstützt wird, wird der Fehler Die angegebene Datei wurde nicht gefunden im CryptRetrieveObjectByUrlWire-Ereignis protokolliert. Dies kann abgefragt werden, indem im CryptRetrieveObjectByUrlWire-Fehlerereignis nach einem Ergebniswert 2 gesucht wird. CryptoAPI unterstützt beispielsweise kein FTP (File Transfer Protocol) für den Netzwerkabruf. Wenn die Zertifikatsperrlisten-Verteilungspunkt-Erweiterung oder die Erweiterung des Stelleninformationszugriffs eine FTP-URL aufweist, tritt beim Netzwerkabruf ein Fehler auf.

Fehler beim wiederholten Netzwerkabruf

In CAPI2 wird vermieden, dass der Server zu oft für wiederholte Offlineantworten kontaktiert wird. Wenn eine Anforderung vor dem nächsten frühesten Zeitpunkt erfolgt, zu dem der Server über einen progressiven Backoff erreicht wird, wird der wiederholte Netzwerkabruf unterdrückt. In diesem Szenario wird das CertRejectedRevocationInfo-Fehlerereignis mit der CanRetrieveFromNetwork-Aktion protokolliert. Der nächste früheste Zeitpunkt, zu dem der Server erreicht wird, ist unter dem Parameter EarliestOnlineTime aufgeführt.

Kurz gesagt muss zum Behandeln von Netzwerkfehlern die zugrunde liegende Komponente (z. B. das Netzwerk, die Proxyeinstellungen, der Webserver oder LDAP), die den Fehler verursacht, korrigiert werden.

Fehler bei der Sperrüberprüfung

In diesem Abschnitt erfahren Sie, wie Sie Fehler bei der Sperrüberprüfung diagnostizieren. Bei einer Sperrüberprüfung können aus verschiedenen Gründen Fehler auftreten. Ein Grund dafür kann sein, dass keine gültigen Sperrinformationen abgerufen werden konnten oder keine Sperrinformationen bereit standen, da sich im Zertifikat keine Zertifikatsperrlisten-Verteilungspunkt- und OCSP-AIA-Erweiterungen befanden. Das CertGetCertificateChain-Ereignis enthält ein ErrorStatus-Flag mit dem Wert CERT_TRUST_REVOCATION_STATUS_UNKNOWN, der auf einen Fehler bei der Sperrüberprüfung hinweist.

Der Grund für die meisten Fehler bei der Sperrüberprüfung besteht darin, dass keine gültigen Sperrinformationen abgerufen werden konnten. In diesem Fall wird ein zusätzlicher ErrorStatus-Flag mit dem Wert CERT_TRUST_IS_OFFLINE_REVOCATION festgelegt, um anzuzeigen, dass der Sperrstatus eines der Zertifikate in der Kette offline oder nicht mehr aktuell ist. Der Grund dafür kann sein, dass keine Sperrinformationen abgerufen werden konnten oder dass zwar Informationen abgerufen werden konnten, diese jedoch ungültig waren.

Die Ergebnisse der Sperrüberprüfung werden im CertVerifyRevocation-Ereignis protokolliert. Wenn Sie die Fehlerursache ermitteln möchten, müssen Sie die unter dem CertVerifyRevocation-Ereignis verschachtelten Ereignisse CertRejectedRevocationInfo und CryptRetrieveObjectByUrlWire anzeigen.

Fehler beim Abrufen von Sperrinformationen

Beim Netzwerkabruf können aus verschiedenen Gründen Fehler auftreten. Diese Gründe sind im Abschnitt Fehler beim Netzwerkabruf in diesem Dokument aufgeführt.

Ungültige Sperrinformationen

Zertifikatsperrliste ist abgelaufen

Wenn das aktuelle Datum nach dem Datum im Feld nextUpdate in der Zertifikatsperrliste liegt, bedeutet dies, dass die Zertifikatsperrliste abgelaufen ist. Dieses Szenario wird durch die CheckTimeValidity-Aktion im CertRejectedRevocationInfo-Ereignis angegeben. Dieses Ereignis enthält Einzelheiten zu abgelehnten Sperrinformationen (z. B. die Zertifikatsperrliste oder die OCSP-Antwort) sowie das Zertifikat, bei dem der Fehler bei der Sperrüberprüfung aufgetreten ist. In diesem Ereignis wird außerdem die fehlerhafte Aktion protokolliert, die zu den abgelehnten Sperrinformationen geführt hat.

Das Datum im Feld nextUpdate der Zertifikatsperrliste kann über das Ereignisprotokoll ermittelt werden. Suchen Sie im entsprechenden X509Objects-Ereignis das Element CertificateRevocationList mit demselben Wert für fileref wie das Element, das im entsprechenden CertRejectedRevocationInfo-Ereignis protokolliert wurde. Dieses Element enthält Informationen zur Gültigkeitsdauer der Zertifikatsperrliste gemäß der Angabe in den Feldern thisUpdate und nextUpdate. Sie können diesen Fehler beheben, indem Sie eine Zertifikatsperrliste mit gültiger Dauer auf dem Server veröffentlichen.

Wie bereits im Abschnitt Fehler beim wiederholten Netzwerkabruf erwähnt wurde, wird in CAPI2 mithilfe des progressiven Backoff vermieden, dass der Server zu oft kontaktiert wird. Wenn der Server wiederholt mit einer zeitlich ungültigen Zertifikatsperrliste antwortet und die nächste Anforderung vor dem nächsten frühesten Zeitpunkt erfolgt, wird der Server über den Backoff erreicht. Anschließend wird eine CanCheckServerForUpdatedCrl-Aktion protokolliert. Der nächste früheste Zeitpunkt, zu dem der Server erreicht wird, ist unter dem Parameter EarliestOnlineTime aufgeführt.

Ungültige Zertifikatsperrlisten-Signatur

Wenn die Signatur der Zertifikatsperrliste nicht überprüft werden kann, wird ein CertRejectedRevocationInfo-Fehlerereignis mit der IsCrlSignatureValid-Aktion protokolliert. Außerdem werden der Fehlercode zum aufgetretenen Fehler und der Ort der Zertifikatsperrliste protokolliert. Zum Beheben dieses Problems muss die Zertifikatsperrliste auf diesem Server durch eine Zertifikatsperrliste mit gültiger Signatur ersetzt werden.

OCSP-Antwort kann nicht überprüft werden

Ein Teil der Überprüfung der OCSP-Antwort besteht in der Verifizierung ihrer Signatur. Wenn diese Signaturverifizierung jedoch nicht erfolgreich ausgeführt werden kann, tritt folglich bei der Überprüfung ein Fehler auf. In diesem Fall wird die IsResponseSignatureValid-Aktion im CertRejectedRevocationInfo-Fehlerereignis protokolliert. Außerdem kann eine OCSP-Antwort in CAPI2 nicht überprüft werden, wenn sie keine grundlegende signierte Antwort darstellt. Wenn die Antwort keine Objektkennung (auch OID genannt) enthält, wird ein CertRejectedRevocationInfo-Feherereignis mit einem IsMissingResponseOID-Aktionselement protokolliert. Wenn die Antwort eine andere Objektkennung enthält als die für eine grundlegende signierte OCSP-Antwort, wird eine IsUnsupportedResponseOID-Aktion protokolliert.

Nicht autorisierter OCSP-Signaturgeber

Eine OCSP-Antwort muss signiert werden. Das Zertifikat des OCSP-Signaturgebers muss die Signatur-EKU des OCSP enthalten. Wenn die EKU nicht vorhanden ist, tritt ein Fehler auf. Dieser Fehler wird durch die GetOCSPSignerCertificate-Aktion im CertRejectedRevocationInfo-Ereignis angegeben. Bei anderen Fehlern, die möglicherweise im Zusammenhang mit dem Zertifikat eines OCSP-Signaturgebers auftreten, wird dieselbe Aktion protokolliert. Dazu zählen folgende Fehler:

  • Ein zeitlich ungültiges Zertifikat

  • Ein Zertifikat mit einer Zertifikatsperrlisten-Verteilungspunkt-Erweiterung oder einer OCSP-URL ohne Revocation_No_Check-Erweiterung

Bei diesen Fehlern werden in CAPI2 außerdem die Informationen zum Zertifikat des OCSP-Signaturgebers protokolliert.

Decodieren der OCSP-Antwort nicht möglich

Eine OCSP-Antwort besteht aus Datenstrukturen, die rekursiv decodiert werden müssen, um die erforderlichen Informationen abzurufen. Wenn beim Decodieren der OCSP ein Fehler auftritt, wird in CAPI2 ein CertRejectedRevocationInfo-Fehlerereignis protokolliert. Je nachdem, in welcher Phase der Fehler bei der Decodierung auftritt, wird dieses Ereignis in CAPI2 mit der Aktion Call_CryptDecodeObject_OCSP_RESPONSE, Call_CryptDecodeObject_OCSP_BASIC_SIGNED_RESPONSE- oder Call_CryptDecodeObject_OCSP_BASIC_RESPONSE protokolliert.

Die Zertifikatsperrliste oder die OCSP-Antwort weist eine nicht unterstützte wichtige Erweiterung auf

Wenn die Zertifikatsperrliste oder die OCSP-Antwort eine nicht unterstützte wichtige Erweiterung aufweist, kann die Sperrung in CAPI2 nicht überprüft werden. In diesem Fall wird in CAPI2 Folgendes protokolliert:

  • Ein CertRejectedRevocationInfo-Fehlerereignis" mit der IsCrlCriticalExtensionSupported-Aktion, wenn der Fehler bei einer Zertifikatsperrliste auftritt.

  • Eine IsResponseCriticalExtensionSupported-Aktion, wenn die OCSP-Antwort eine nicht unterstützte wichtige Erweiterung enthält.

Der OCSP-Antwortstatus lautet nicht "Erfolgreich"

Eine OCSP-Antwort besteht aus einem Feld responseStatus, in dem der Verarbeitungsstatus der vorherigen Anforderung angezeigt wird. Verläuft die Verarbeitung erfolgreich, lautet der Antwortstatus succesful.

Wenn ein Fehler auftritt, kann der OCSP-Antwortstatus (responseStatus) einen der folgenden Werte aufweisen:

  • MalformedRequest

  • InternalError

  • TryLater

  • SigRequired

  • Unauthorized

Wenn der Wert für responseStatus nicht succesful lautet, wird ein CertRejectedRevocationInfo-Ereignis mit der CheckResponseStatus-Aktion protokolliert. Zeigen Sie zum Abfragen des Status der OCSP-Antwort das entsprechende X509Objects-Ereignis an. Das Statuselement von OCSPResponse enthält den Antwortstatus.

Weitere Einzelheiten zu den Statuswerten und den Szenarien, in denen sie festgelegt werden, finden Sie unter RFC 2560 auf der IETF-Website (möglicherweise in englischer Sprache).

Andere Fehler

Das Zertifikat enthält keine Sperrinformationen

Ein Zertifikatsperrlisten-Verteilungspunkt ist für alle Zertifikate – außer für ein Stamm-Zertifizierungsstellenzertifikat – erforderlich, da der Zertifikatsperrlisten-Verteilungspunkt einen Zeiger zum Finden der Sperrinformationen bereitstellt. Wenn der Zertifikatsperrlisten-Verteilungspunkt nicht vorhanden ist, sollte der OCSP-Downloadort in der Erweiterung des Stelleninformationszugriffs enthalten sein. Wenn keiner der beiden Zeiger vorhanden ist, hat CAPI2 keinen endgültigen Beweis dafür, dass die Zertifizierungsstelle tatsächlich Sperrinformationen veröffentlicht hat. Dies führt zu einem Fehler bei der Sperrüberprüfung und einem Fehlerstatus Sperrung unbekannt. In diesem Fall wird in CAPI2 ein CertRejectedRevocationInfo-Feherereignis mit der GetCrlOrOcspUrls-Aktion und dem erweiterten Fehler Das Objekt oder die Eigenschaft wurde nicht gefunden protokolliert.

Beheben Sie dieses Problem, indem Sie das Zertifikat, das den Fehler verursacht, im Ereignisprotokoll überprüfen. Sofern es sich nicht um ein Stamm-Zertifizierungsstellenzertifikat handelt, müssen die jeweiligen ausstellenden Zertifizierungsstellen neu konfiguriert und die betreffenden Zertifikate mit dem richtigen Zertifikatsperrlisten-Verteilungspunkt neu ausgestellt werden. Wenn es sich um ein Stamm-Zertifizierungsstellenzertifikat handelt, ist eine Sperrprüfung dieses Zertifikats nicht angebracht.

In CAPI2 werden keine Zertifikatssperrlisten unterstützt, die aus bestimmten Gründen partitioniert wurden. Wenn der Zertifikatsperrlisten-Verteilungspunkt im Zertifikat auf eine Zertifikatssperrliste verweist, die aus bestimmten Gründen partitioniert wurde, wird der jeweilige Ort des Zertifikatsperrlisten-Verteilungspunkts in CAPI2 bei der Verarbeitung ignoriert. Wenn kein anderer Zertifikatsperrlisten-Verteilungspunkt verfügbar ist, führt dies zum selben Fehlerszenario wie bei einem Zertifikat ohne Zertifikatsperrlisten-Verteilungspunkt-Informationen.

Informationen zu bewährten Methoden finden Sie unter http://go.microsoft.com/fwlink/?LinkId=25612 (möglicherweise in englischer Sprache).

Ausstellender Verteilungspunkt in der Zertifikatsperrliste für das Antragstellerzertifikat ungültig

Wenn die Zertifikatsperrliste eine Erweiterung für einen ausstellenden Verteilungspunkt (Issuing Distribution Point, Ausstellungs-Verteilungspunkt) enthält, wird in CAPI2 überprüft, ob der ausstellende Verteilungspunkt für das Antragstellerzertifikat, das im Hinblick auf eine Sperrung überprüft wird, gültig ist. Wenn bei dieser Überprüfung ein Fehler auftritt und der Ausstellungs-Verteilungspunkt für das Antragstellerzertifikat nicht gültig ist, wird von CAPI2 ein CertRejectedRevocationInfo-Fehlerereignis mit der Call_CertIsValidCRLForCertificate-Aktion protokolliert. Wenn beispielsweise der Ausstellungs-Verteilungspunkt in der Zertifikatsperrliste nicht mit dem Zertifikatsperrlisten-Verteilungspunkt übereinstimmt, wird dieser Fehler protokolliert.

Fehler beim Ermitteln des Zertifikatpfads

Abruf des Ausstellerzertifikats verursachender Fehler bei der Serverkonfiguration

Als Teil der Zertifikatpfadermittlung werden die Zwischenzertifikate aus dem Zertifikatspeicher oder aus dem Cache auf dem Client oder dem Anwendungsprotokoll entnommen. Im Fall von SSL werden beispielsweise Zwischenzertifikate zusammen mit dem Serverauthentifizierungszertifikat als Teil des Handshake an den Client gesendet. Wen das Ausstellerzertifikat nicht lokal verfügbar ist und auch nicht als Teil des Anwendungsprotokolls bereitgestellt wird, wird das Ausstellerzertifikat mithilfe der Erweiterung des Stelleninformationszugriffs im Endentitätszertifikat aus dem Netzwerk abgerufen. In CAPI2 wird der Download des Ausstellerzertifikats im CertAIAUrlRetrievalWire-Ereignis protokolliert. Da das Abrufen aus dem Netzwerk die Leistung beeinträchtigt, sollte dieser Abruf des Stelleninformationszugriffs vermieden werden.

Wenn sich im Fall von SSL ein CertAIAUrlRetrievalWire-Ereignis im Ereignisprotokoll befindet, bedeutet dies, dass der Server nicht ordnungsgemäß konfiguriert ist. Sie können die Informationen im Protokoll im Hinblick auf möglicherweise fehlende oder abgelaufene Zertifikate näher untersuchen. Ein Administrator kann die Zertifizierungsstellen-Zwischenzertifikate mithilfe der Gruppenrichtlinien auf Clients bereitstellen. Diese Zertifikate werden jedoch in der Regel nicht lokal auf Clients installiert. Zur Vermeidung des Netzwerkabrufs sollten alle Server ordnungsgemäß konfiguriert sein und über entsprechende Zertifizierungsstellen-Zwischenzertifikate verfügen. Gültige Zwischenzertifikate, die Teil der Zertifikatkette für das Serverzertifikat sind, sollten dem lokalen Speicher für Zertifizierungsstellen-Zwischenzertifikate auf dem Server hinzugefügt werden. Stellen Sie nach dem Hinzufügen des gültigen Zwischenzertifikats die Serverzertifikatbindung wieder her. Auf diese Weise ist sichergestellt, dass Zwischenzertifikate als Teil des Handshakes weitergegeben werden.

Weitere Informationen finden Sie im Artikel 834438 unter http://go.microsoft.com/fwlink/?LinkId=82290 (möglicherweise in englischer Sprache).

Ausstellerzertifikate konnten nicht abgerufen werden

Wenn die Ausstellerzertifikate nicht abgerufen werden können, kann keine Kette vom Endentitätszertifikat bis zu einem vertrauenswürdigen Stammzertifikat erstellt werden. Dies führt zu einem partiellen Kettenfehler, d. h., die Zertifikatkette kann nicht bis zu einer vertrauenswürdigen Stammzertifizierungsstelle erstellt werden. Im Falle eines partiellen Kettenfehlers wird das CERT_TRUST_IS_PARTIAL_CHAIN-Fehlerstatusflag festgelegt.

Beim Abrufen von Ausstellerzertifikaten können aus verschiedenen Gründen Fehler auftreten. Beim Netzwerkabruf von Ausstellerzertifikaten können aus verschiedenen Gründen Fehler auftreten. Diese Gründe sind im Abschnitt Fehler beim Netzwerkabruf in diesem Dokument aufgeführt.

Außerdem ist die Anzahl der URLs beschränkt, die als Teil des Abrufs von Ausstellerzertifikaten getestet werden können. Die Anzahl der über den Stelleninformationszugriff abgerufenen Zertifikate kann ebenfalls beschränkt werden. Durch diese Beschränkungen soll die für den Abruf von Ausstellerzertifikaten in Anspruch genommene Zeit reduziert werden. Werden die Beschränkungen überschritten, kann ein partieller Kettenfehler auftreten. Wenn das Ausstellerzertifikat zwar abgerufen, jedoch nicht erfolgreich decodiert werden kann, kann ebenfalls ein partieller Kettenfehler auftreten.

Allgemeine Überlegungen zur automatisierten Problembehandlung

Nachstehend sind die Schritte zur näheren Untersuchung der Daten im Protokoll und zur Ermittlung der Ursache des Fehlers erläutert.

Schritt 1: Identifizieren und Zusammenfassen von korrelierten Ereignissen

  1. Suchen Sie jede einzelne CorrelationAuxInfo-TaskId im Protokoll, und notieren Sie sie.

  2. Identifizieren Sie zu jeder Task-ID die Ereignisse, die dieselbe TaskId aufweisen, und gruppieren Sie sie in einem Satz.

Führen Sie für jeden Satz korrelierter Ereignisse die folgenden Schritte aus.

Schritt 2: Einstufen des Fehlers

Stufen Sie in diesem Schritt den Fehler basierend auf dem Fehlerereignis der obersten Ebene ein.

  1. Suchen Sie das CertGetCertificateChain-Ereignis mit einem Fehler. Wenn ein CertGetCertificateChain-Fehlerereignis vorhanden ist, identifizieren Sie das Fehlerszenario mithilfe der ErrorStatus-Flags.

    • Wenn das CERT_TRUST_REVOCATION_STATUS_UNKNOWN-Flag festgelegt ist, wurde die Pfadüberprüfung aufgrund eines Fehlers bei der Sperrüberprüfungsfehler nicht erfolgreich ausgeführt. Fehler bei der Sperrüberprüfung werden im Allgemeinen aufgrund von Abruffehlern verursacht. Es wird ein zusätzliches Flag festgelegt, mit dem dies angegeben wird. Wenn das Flag von sich selbst festgelegt wird, kann dies ein Hinweis auf Sperrüberprüfungsfehler aus anderen Gründen sein, z. B. ein Zertifikatsperrlisten-Verteilungspunkt, der ein nicht unterstütztes Feld für Gründe aufweist.

    • Wenn das CERT_TRUST_IS_REVOCATION_OFFLINE-Flag auch festgelegt ist, konnte die Pfadüberprüfung aufgrund eines Abruffehlers während einer Sperrüberprüfung nicht erfolgreich ausgeführt werden. Die Sperrinformationen konnten nicht abgerufen werden oder sind ungültig.

    • Wenn das CERT_TRUST_IS_UNTRUSTED_ROOT-Flag festgelegt ist, wurde die Zertifikatkette bis zu einer Stammzertifizierungsstelle erstellt. Das Zertifikat der Stammzertifizierungsstelle befand sich jedoch nicht im Speicher der vertrauenswürdigen Stammzertifizierungsstelle.

    • Wenn das CERT_TRUST_IS_PARTIAL_CHAIN-Flag festgelegt ist, konnte keine vollständige Zertifikatkette bis zu einer vertrauenswürdigen Stammzertifizierungsstelle erstellt werden. Dies kann dann der Fall sein, wenn die Ausstellerzertifikate nicht gefunden wurden und bei deren Abruf mithilfe des Stelleninformationszugriffs ein Fehler aufgetreten ist.

    • Wenn andere Flags vorhanden sind, weist dies je nach Flag darauf hin, dass ein bestimmter Pfadüberprüfungsfehler aufgetreten ist. Im Abschnitt Fehler bei der Pfadüberprüfung in diesem Dokument sind häufig auftretende Pfadüberprüfungs-Fehlerszenarien und deren entsprechende ErrorStatus-Flags beschrieben.

  2. Suchen Sie das CryptAcquireCertificatePrivateKey-Ereignis mit einem Fehler. Dieses Ereignis weist auf Fehler im Zusammenhang mit dem Erhalt eines privaten Schlüssels für ein Zertifikat hin.

  3. Suchen Sie das CertOpenStore-Ereignis mit einem Fehler. Dieses Ereignis weist auf Fehler im Hinblick auf Vorgänge im Zertifikatspeicher hin.

  4. Suchen Sie nach weiteren Fehlern.

Die Fehlerstatusflags im CertGetCertificateChain-Ereignis helfen beim Ermitteln des Symptoms und beim Eingrenzen der Suche nach der Fehlerursache. Zeigen Sie zum Ermitteln der Fehlerursache die weiteren APIs an, die als Teil der Pfadüberprüfung aufgerufen werden. In bestimmten Fällen können diese APIs jedoch direkt aufgerufen werden, und der korrelierte Satz aus Ereignissen weist möglicherweise kein CertGetCertificateChain-Ereignis auf. Suchen Sie in diesem Fall direkt nach der Fehlerursache. Verwenden Sie hierzu die auf diesen APIs basierenden Ereignisse. Diese Fehlerereignisse könnten zu den anderen Ereignissen gehören, die im Abschnitt Fehlerszenarien in diesem Dokument beschrieben werden.

Schritt 3: Ermitteln der Fehlerursache

In Schritt 2 haben Sie die Symptome ermittelt, mit denen die Ursachen für Fehler, die in einem jeden Szenario zu suchen sind, eingegrenzt werden können. In Schritt 3 werden Sie die Fehlerursache ermitteln. Dazu können Sie bestimmte Aktionen oder Statuscodes im Ereignisprotokoll untersuchen. Die Aktionen und Statuscodes zu verschiedenen Szenarien sind im Abschnitt Fehlerszenarien beschrieben. Suchen Sie basierend auf der Fehlerklasse nach den Bezeichnungen dieser Aktionen und den Statuscodes in bestimmten Ereignissen. Untersuchen Sie beispielsweise bei Sperrfehlern die CertRejectedRevocationInfo-Fehlerereignisse und bei Netzwerkabruffehlern die CryptRetrieveObjectByUrlWire-Fehlerereignisse.

Die nachfolgende Abbildung enthält ein diesem Algorithmus entsprechendes Flussdiagramm.

Steps to mine data from event log

Zur Automatisierung des Problembehandlungsprozesses können Sie gemäß den oben aufgeführten Schritten Code zum Abfragen des Protokolls schreiben. Sehen Sie sich den Beispielcode in Anhang C an. Dort ist dargestellt, wie dieser Prozess zur Fehlerdiagnose angewendet werden kann. Anhang B enthält einige XPATH-Abfragen für verschiedene Fehlerszenarien, die den Abfragen im Beispielcode ähneln.

Zusammenfassung

Mit der CAPI2-Diagnose können Sie ausführliche Informationen zu verschiedenen Vorgängen im Zusammenhang mit Zertifikaten (z. B. der Überprüfung des Zertifikatpfads und der Signaturverifizierung) sammeln. Diese Informationen können für die Behandlung von PKI-Problemen in PKI-fähigen Umgebungen von Nutzen sein. Mithilfe der in diesem Dokument enthaltenen Informationen zu den Szenarien und den Abfragen können Sie Daten aus dem Protokoll interpretieren, das Ereignisprotokoll nach bestimmten Mustern durchsuchen und die Fehlerursache des Problems ermitteln. Die CAPI2-Diagnose ermöglicht eine verbesserte Behandlung von PKI-Problemen und hilft dabei, häufig auftretende Probleme in kürzerer Zeit zu beheben.

Feedback

Falls Sie Fragen oder Feedback zur CAPI2-Diagnose haben, können Sie diese in der Newsgroup microsoft.public.security.crypto veröffentlichen.

Anhänge

Inhalt dieses Abschnitts:

Anhang A: Ereignisse im Ereignisprotokoll der CAPI2-Diagnose

In der nachstehenden Tabelle sind die Ereignisse der obersten Ebene aufgeführt, die im CAPI2-Diagnose-Protokoll aufgezeichnet werden.

CAPI2-Diagnose: Ereignisse der obersten Ebene

Ereignisname Aufgabe Beschreibung

CertGetCertificateChain

Erstellen einer Kette

Zeigt die Ergebnisse der Überprüfung eines Zertifikatpfads an.

CertVerifyRevocation

Überprüfen einer Sperrung

Zeigt die Ergebnisse einer für ein oder mehrere Zertifikate ausgeführten Sperrüberprüfung an. In den meisten Fällen ist dieses Ereignis unter CertGetCertificateChain verschachtelt und wird nur dann als Ereignis der obersten Ebene ausgelöst, wenn die CertVerifyRevocation-API von einer Anwendung direkt aufgerufen wird.

CertVerifyCertificateChainPolicy

Überprüfen der Kettenrichtlinie

Zeigt die Ergebnisse einer Anwendung an, von der eine Zertifikatkette entsprechend vordefinierter Richtlinien in Windows ausgewertet wird.

CertOpenStore

Öffnen des Speichers

Zeigt die Ergebnisse des Öffnens von Zertifikatspeichern an.

CryptRetrieveObjectByUrlWire

Abrufen eines Objekts aus dem Netzwerk

Zeigt die Ergebnisse eines Netzwerkdownloads an.

CryptRetrieveObjectByUrlCache

Abrufen eines Objekts aus dem Cache

Zeigt die Ergebnisse des Abrufens eines Objekts aus dem Cache an.

CryptAcquireCertificatePrivateKey

Erwerben des privaten Zertifikatschlüssels

Zeigt die Ergebnisse eines Versuchs an, einen privaten Schlüssel für ein Zertifikat abzurufen.

WinVerifyTrust

Überprüfen der Vertrauenswürdigkeit

Zeigt die Ergebnisse einer Signaturverifizierung mit WinVerifyTrust sowie der Zertifikatkettenüberprüfung an. Enthält Informationen dazu, warum der signierte Code nicht überprüft werden konnte.

CryptCATAdminEnumCatalogFromHash

Suchen des Sicherheitskatalogs für eine Datei

Enthält Informationen zu Suchen in Katalogen. Als Teil der Signaturverifizierung wird der Hash der Datei abgerufen und im Katalog gesucht, und anschließend wird die Signatur des Katalogs überprüft. Hierbei werden der Hash der Datei, der Katalogdateipfad und der Zieldateipfad protokolliert. Der Dateihash kann als Verbindung zwischen diesen und dem entsprechenden WinVerifyTrust-Ereignis verwendet werden.

Nachstehend sind Ereignisse niedrigerer Ebenen aufgeführt, die unter den Ereignissen der obersten Ebene im CAPI2-Diagnose-Protokoll verschachtelt sind.

CAPI2-Diagnose-Protokoll: Ereignisse niedrigerer Ebenen

Ereignisname Aufgabe Beschreibung

CertAIAUrlRetrievalWire

Abrufen des Ausstellerzertifikats aus dem Netzwerk

Zeigt die Ergebnisse des Abrufs des Ausstellerzertifikats über das Netzwerk an.

CertAIAUrlRetrievalCache

Abrufen des Ausstellerzertifikats aus dem Cache

Zeigt die Ergebnisse des Abrufs des Ausstellerzertifikats aus dem Cache an.

CertAutoRootUrlRetrievalWire

Abrufen des Stammzertifikats eines Drittanbieters aus dem Netzwerk

Zeigt die Ergebnisse des Downloads eines Drittanbieter-Stammzertifikats als Teil des automatischen Stammupdates an.

CertAutoRootUrlRetrievalCache

Abrufen des Stammzertifikats eines Drittanbieters aus dem Cache

Zeigt die Ergebnisse des Abrufs des Drittanbieter-Stammzertifikats aus dem Cache an.

CertCrossCertUrlRetrievalWire

Abrufen des Kreuzzertifikats aus dem Netzwerk

Zeigt die Ergebnisse des Downloads des Kreuzzertifikats an.

CertCrossCertUrlRetrievalCache

Abrufen des Kreuzzertifikats aus dem Cache

Zeigt die Ergebnisse des Abrufs des Kreuzzertifikats aus dem Cache an.

CertRejectAIAUrlRetrieval

Unterdrücken eines Abrufs des Ausstellerzertifikats

Enthält Informationen dazu, warum der Abruf des Ausstellerzertifikats unterdrückt wurde. Die Gründe hierfür können ähnlich sein wie bei der Überschreitung der Höchstanzahl an URLs.

CertRejectedRevocationInfo

Ablehnen von Sperrinformationen

Enthält Informationen dazu, warum eine bestimmte Zertifikatsperrliste oder OCSP-Antwort abgelehnt wurde. Das Ereignis gibt an, ob die Zertifikatsperrliste bzw. die OCSP-Antwort aus dem Cache, dem Speicher oder dem Netzwerk abgerufen wurde. Es ist unter dem CertVerifyRevocation-Ereignis verschachtelt.

X509Objects

X509-Objekte

Enthält Einzelheiten zu den in der Aktivität verwendeten Zertifikatobjekten. Einzelheiten zu X.509-Objekten (z. B. Zertifikate, Zertifikatsperrlisten und OCSP-Antworten) werden als Teil dieses Ereignisses protokolliert.

Anhang B: XPATH-Beispielabfragen

XPATHs können zum Abfragen von Informationen im Ereignisprotokoll verwendet werden, um Probleme zu behandeln. Wenn Sie die Daten aus dem Ereignisprotokoll in einer XML-Datei speichern, können Sie die folgenden XPATHs zum Ermitteln bestimmter Informationen im Protokoll verwenden.

In der nachstehenden Tabelle sind die im Abschnitt Behandlung häufig auftretender Probleme in diesem Dokument erläuterten Aufgaben zusammen mit ihren XPATH-Ausdrücken aufgeführt.

XPATH-Abfragen: Behandlung häufig auftretender Probleme (Abschnitt)

Aufgabe XPATH-Ausdruck

Suchen nach dem Kette erstellen-Fehlerereignis

//Event[System/Level=2]//CertGetCertificateChain

Suchen nach dem Kette erstellen-Fehlerereignis im Zusammenhang mit einer bestimmten Anwendung (z. B. Internet Explorer)

//Event[System/Level=2]//CertGetCertificateChain[EventAuxInfo[@ProcessName='iexplore.exe']]

Suchen aller Ereignisse mit einer bestimmten Aufgabe

//CorrelationAuxInfo[@TaskId='" + taskid + "']/parent::*

Abfragen des Fehlerstatusflags für Kettenelemente

//CertGetCertificateChain[ChainElement[TrustStatus[ErrorStatus[@CERT_TRUST_IS_OFFLINE_REVOCATION]]]]

In der nachstehenden Tabelle sind die im Abschnitt Fehler bei der Pfadüberprüfung in diesem Dokument erläuterten Fehler zusammen mit ihren XPATH-Ausdrücken aufgeführt.

XPATH-Abfragen: Fehler bei der Pfadüberprüfung (Abschnitt)

Fehler XPATH-Ausdruck

Das Zertifikat oder eines der Zertifikate in der Kette ist abgelaufen.

//CertGetCertificateChain/CertificateChain[TrustStatus[ErrorStatus[@CERT_TRUST_IS_NOT_TIME_VALID]]

Weitere Pfadüberprüfungsfehler finden Sie, indem Sie das entsprechende ErrorStatus-Flag im obigen Ausdruck ersetzen.

In der nachstehenden Tabelle sind die im Abschnitt Fehler beim Netzwerkabruf in diesem Dokument erläuterten Fehler zusammen mit ihren XPATH-Ausdrücken aufgeführt.

XPATH-Abfragen: Fehler beim Netzwerkabruf (Abschnitt)

Fehler XPATH-Ausdruck

HTTP 404-Fehler

//CryptRetrieveObjectByUrlWire[AuxInfo[@httpStatusCode='404']]

Weitere HTTP-Fehler finden Sie, indem Sie 404 durch den entsprechenden Statuscode ersetzen.

Zeitüberschreitungsfehler

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='NetworkRetrievalTimeout']]]

Wenn das Objekt zu groß ist, zeigen Sie die Ereignisse im Hintergrundthread an.

objecturl=//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='NetworkRetrievalTimeout']]]/URL

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='PendingNetworkRetrievalComplete']] and URL=’{objecturl}’ and Result[@value=’0’]]

Wenn der Server nicht verfügbar ist, tritt beim Aufrufen von WinHttpSendRequest ein Fehler auf.

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='Call_WinHttpSendRequest']]]

Fehler beim Herstellen der Verbindung über einen Proxy

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='BadProxy']]]

So ermitteln Sie den fehlerhaften Proxyserver

//CryptRetrieveObjectByUrlWire/AdditionalInfo/Action[@name='BadProxy']/@parameter1

LDAP-Fehler

Abfragen von Fehlern in Aufrufen von LDAP-APIs

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='Call_ldap_connect']]]

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='Call_ldap_bind']]]

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='Call_ldap_search']]]

Fehler

XPATH-Ausdruck

HTTP 404-Fehler

//CryptRetrieveObjectByUrlWire[AuxInfo[@httpStatusCode='404']]

Weitere HTTP-Fehler finden Sie, indem Sie 404 durch den entsprechenden Statuscode ersetzen.

Zeitüberschreitungsfehler

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='NetworkRetrievalTimeout']]]

Wenn das Objekt zu groß ist, zeigen Sie die Ereignisse im Hintergrundthread an.

objecturl=//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='NetworkRetrievalTimeout']]]/URL

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='PendingNetworkRetrievalComplete']] and URL=’{objecturl}’ and Result[@value=’0’]]

Wenn der Server nicht verfügbar ist, tritt beim Aufrufen von WinHttpSendRequest ein Fehler auf.

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='Call_WinHttpSendRequest']]]

Fehler beim Herstellen der Verbindung über einen Proxy

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='BadProxy']]]

So ermitteln Sie den fehlerhaften Proxyserver

//CryptRetrieveObjectByUrlWire/AdditionalInfo/Action[@name='BadProxy']/@parameter1

LDAP-Fehler

Abfragen von Fehlern in Aufrufen von LDAP-APIs

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='Call_ldap_connect']]]

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='Call_ldap_bind']]]

//CryptRetrieveObjectByUrlWire[AdditionalInfo[Action[@name='Call_ldap_search']]]

In der nachstehenden Tabelle sind die im Abschnitt Fehler aufgrund einer fehlerhaften Sperrüberprüfung in diesem Dokument erläuterten Fehler zusammen mit ihren XPATH-Ausdrücken aufgeführt.

XPATH-Abfragen: Fehler bei der Sperrüberprüfung (Abschnitt)

Fehler XPATH-Ausdruck

Zertifikatsperrliste ist abgelaufen

//CertRejectedRevocationInfo[Action[@name='CheckTimeValidity']]

Signatur der Zertifikatsperrliste kann nicht überprüft werden

//CertRejectedRevocationInfo[Action[@name='IsCrlSignatureValid']]

OCSP-Antwort kann nicht überprüft werden

Wenn die Signatur der OCSP-Antwort nicht überprüft werden kann:

//CertRejectedRevocationInfo[Action[@name='IsResponseSignatureValid']]

Wenn beim Decodieren der OCSP-Antwort ein Fehler aufgetreten ist:

//CertRejectedRevocationInfo[Action[@name='Call_CryptDecodeObject_OCSP_RESPONSE']]

Nicht autorisierter OCSP-Signaturgeber

//CertRejectedRevocationInfo[Action[@name=’GetOCSPSignerCertificate']]

Decodieren der OCSP-Antwort nicht möglich

//CertRejectedRevocationInfo[Action[@name=’Call_CryptDecodeObject_OCSP_RESPONSE']]

Die Zertifikatsperrliste oder die OCSP-Antwort weist eine nicht unterstützte wichtige Erweiterung auf

//CertRejectedRevocationInfo[Action[@name='IsCrlCriticalExtensionSupported’]]

//CertRejectedRevocationInfo[Action[@name='IsResponseCriticalExtensionSupported']]

Der OCSP-Antwortstatus lautet nicht "Erfolgreich"

//CertRejectedRevocationInfo[Action[@name='CheckResponseStatus']]

Anhang C: Beispielcodes zum Identifizieren von Mustern

Mit diesem Beispielcode wird veranschaulicht, wie die Ursache des Fehlers im Falle des im Abschnitt Fehler beim Anmelden mit einer Smartcard beschriebenen Szenarios ermittelt wird. Es wird eine Implementierung des im Abschnitt Allgemeine Überlegungen zur automatisierten Problembehandlung erläuterten Prozesses dargestellt. Dieses Beispiel ist beliebig erweiterbar, sodass Sie weitere Fehlerszenarien mit einbeziehen können. Speichern Sie zum Ausführen dieses Beispiels die Ereignisse aus dem CAPI2-Diagnose-Ereignisprotokoll in einer XML-Datei. Geben Sie den Namen dieser XML-Datei während der Ausführung des Beispiels als Befehlszeilenargument an.

Die Hauptfunktionen in diesem Beispielcode lauten folgendermaßen:

  • IdentifyPattern: Der Startpunkt für die Identifizierung des Fehlermusters zu einer bestimmten Sequenz korrelierter Ereignisse.

  • ClassifyError: Klassifizierung des Pfadüberprüfungsfehlers auf oberster Ebene basierend auf den ErrorStatus-Flags in CertGetCertificateChain.

  • CheckHTTPErrorPattern: Überprüfung der Klasse der durch HTTP-Fehler entstandenen Abruffehler. Möglicherweise gibt es ähnliche Funktionen wie CheckProxyErrorPattern oder CheckTimeoutErrorPattern.

  • Funktionen des Hilfsprogramms: Die restlichen Funktionen gehören zu einem Hilfsprogramm und dienen der Abfrage bestimmter Informationen aus dem Ereignisprotokoll.


Using System; 
using System.IO; 
using System.Xml; 
using System.Xml.XPath; 
using System.Collections; 
using System.Text;

namespace CAPIDiagPatternIdentifier 
{ 
 class PatternIdentifier { 
  // Die Klassifizierung von Fehlersymptomen auf oberster Ebene 
  const int OTHER_ERROR = 0; 
  const int REVOCATION_FAILURE = 1; 
  const int RETRIEVAL_ERROR = 2; 
  const int SIGNATURE_INVALID = 3; 
  const int UNTRUSTED_ROOT = 4; 
  const int PARTIAL_CHAIN = 5; 
  const int REVOKED = 6;    

  const string filePath = ".\\"; 
  //Der Protokoll-Namespace 
  const string logns = "http://schemas.microsoft.com/win/2004/08/events/event";    

  // Definieren Sie Fehlerabfragen und Nachrichtenzeichenfolgen hier 
  // Diese können zur Suche nach bestimmten Mustern im Protokoll verwendet werden.

  const string err404qry = "//ns:CryptRetrieveObjectByUrlWire[ns:AuxInfo[@httpStatusCode='404']]"; 
  const string err404msg = "Zertifikatsperrliste wurde unter der URL des Zertifikatsperrlisten-Verteilungspunkts nicht gefunden:";     

  private XmlDocument doc; 
  private XPathNavigator xpath; 
  private XmlNamespaceManager nsmanager;
  
  public PatternIdentifier(string[] args) { 
   // Erstellen des XmlDocument object 
   doc = new XmlDocument(); 
   // Öffnen Sie das über die Befehlszeile angegebene Protokoll 
   FileStream fs = new FileStream(args[0], FileMode.Open); 
   // Laden Sie das Protokoll in ein XML DOM 
   doc.Load(fs); 
   xpath = doc.CreateNavigator(); 
   nsmanager = new XmlNamespaceManager(xpath.NameTable); nsmanager.AddNamespace("ns", logns); 
  }

  public String GetTaskId(XmlNode eventNode) { 
   String TaskId = null; 
   XPathNavigator navigator = eventNode.CreateNavigator(); 
   XPathNodeIterator itr = navigator.Select("@TaskId"); 
   if (itr.MoveNext())  { 
    TaskId = itr.Current.Value; 
   } 
   return TaskId; 
  }

  private String GetProcessName(XPathNavigator currentNode)  { 
   String processName = null; 
   XPathNodeIterator itr = currentNode.Select("//@ProcessName"); 
   if (itr.MoveNext())  { 
    processName = itr.Current.Value; 
   } 
   return processName ; 
  }

  // Eine gängige Funktion zur Überprüfung aller Netzwerkfehler 
  privates bool CheckNetworkRetrievalPattern(XPathNavigator currentNode, String evtQuery, string errString)  { 
   XPathExpression evtqry = xpath.Compile(evtQuery); 
   evtqry.SetContext(nsmanager); 
   if (currentNode.Matches(evtqry) && (currentNode IHasXmlNode lautet))   { 
    XmlNode node = ((IHasXmlNode)currentNode).GetNode(); 
    string URL = (node.SelectSingleNode("ns:URL", nsmanager)).InnerXml; 
    System.Console.WriteLine("Fehler beim Netzwerkabruf. "+ errString + URL); 
    return true; 
   } 
   return false; 
  }

  // Überprüfung auf HTTP-Fehler 
  privates bool CheckHTTPErrorPattern(XPathNavigator currentNode)  { 
   if (CheckNetworkRetrievalPattern(currentNode, err404qry, err404msg)) return true; 
   // Fügen Sie hier weitere HTTP-Fehler hinzu 
   return false; 
  }

  private bool isInArray(ArrayList al, string val)  { 
   for (int i = 0; i < al.Count; ++i)   { 
    if (val == (string)al[i])    { 
     return true; 
    } 
   } 
   return false; 
  }
     
  public void IdentifyPattern(XPathNodeIterator eventNodes, string TaskId)  { 
   if (eventNodes.Count > 0)   { 
    while (eventNodes.MoveNext())    {
     String fileRef = null; 
     String subjectName = null; 
     String processName = null ; 
     int errorType = 0; 
     // Überprüfung erforderlich, an welchem Kettenelement sich ein Fehler befindet 
     XPathExpression errQuery = xpath.Compile("//ns:CertGetCertificateChain[ns:Result[@value!='0']]"); 
     errQuery.SetContext(nsmanager); 
     if (eventNodes.Current.Matches(errQuery))     { 
      // Es ist bekannt, dass ein Kettenelement einen Fehler aufweist 
      // Sammeln Sie weitere Daten zum Element und zum Fehler 
      errorType = ClassifyError(eventNodes, ref fileRef, ref subjectName, ref processName); 
      } 
      // Nun wird versucht, die Ursache für diesen Fehler zu ermitteln. 
      switch (errorType)    { 
       case RETRIEVAL_ERROR: 
      { 
        while (eventNodes.MoveNext())     { 
         if (CheckHTTPErrorPattern(eventNodes.Current)) break; 
         //Suchen Sie hier nach weiteren Netzwerkfehlern 
        } 
        break; 
       } 
      //Fügen Sie weitere Fehler pro Klassifizierungsfall hinzu 
      case OTHER_ERROR: 
       { 
        //Alle anderen Fehler, die in den obigen Fällen nicht enthalten waren. 
        break; 
       } 
      } 
     } 
    eventNodes = null; 
   } 
  }

//Klassifizierung von Fehlersymptomen auf oberster Ebene (Schritt 2 des Algorithmus) 
//Suchen Sie das Kettenelement, das dem jeweiligen Fehler Symptom entspricht  
  private int ClassifyError(XPathNodeIterator eventNodes, ref String fileRef, ref String subjectName, ref String processName)  { 
   processName = GetProcessName(eventNodes.Current); 
   System.Console.WriteLine("Fehler verursachende Anwendung: " + processName); 
   XPathNodeIterator chainElement = eventNodes.Current.SelectDescendants("ChainElement", logns, false); 
   while (chainElement.MoveNext())   { 
   XPathExpression statusQuery1 = xpath.Compile("//ns:ChainElement[ns:TrustStatus[ns:ErrorStatus[@CERT_TRUST_REVOCATION_STATUS_UNKNOWN]]]");    XPathExpression statusQuery2 = xpath.Compile("//ns:ChainElement[ns:TrustStatus[ns:ErrorStatus[@CERT_TRUST_IS_OFFLINE_REVOCATION]]]"); 
   XPathExpression statusQuery3 = xpath.Compile("//ns:ChainElement[ns:TrustStatus[ns:ErrorStatus[@CERT_TRUST_IS_NOT_SIGNATURE_VALID]]]");       XPathExpression statusQuery4 = xpath.Compile("//ns:ChainElement[ns:TrustStatus[ns:ErrorStatus[@CERT_TRUST_IS_UNTRUSTED_ROOT]]]"); 
   XPathExpression statusQuery5 = xpath.Compile("//ns:ChainElement[ns:TrustStatus[ns:ErrorStatus[@CERT_TRUST_IS_PARTIAL_CHAIN]]]"); 
   XPathExpression statusQuery6 = xpath.Compile("//ns:ChainElement[ns:TrustStatus[ns:ErrorStatus[@CERT_TRUST_IS_REVOKED]]]");    statusQuery1.SetContext(nsmanager); statusQuery2.SetContext(nsmanager); 
   statusQuery3.SetContext(nsmanager); 
   statusQuery4.SetContext(nsmanager); 
   statusQuery5.SetContext(nsmanager); 
   statusQuery6.SetContext(nsmanager); 
   chainElement.Current.MoveToChild("Certificate", logns); 
   fileRef = chainElement.Current.GetAttribute("fileRef", ""); 
   subjectName = chainElement.Current.GetAttribute("subjectName", ""); 
   chainElement.Current.MoveToParent(); 
   if (chainElement.Current.Matches(statusQuery5))     { 
     System.Console.WriteLine("Fehler bei der Pfadüberprüfung für das Zertifikat von subjectName:" + subjectName + " (" + fileRef + ") da keine vollständige Kette erstellt werden konnte"); 
     return PARTIAL_CHAIN; 
    } 
    else if (chainElement.Current.Matches(statusQuery4))     { 
     System.Console.WriteLine("Fehler bei der Pfadüberprüfung für das Zertifikat von subjectName:" + subjectName + " (" + fileRef + ") da keine Kette zu einem vertrauenswürdigen Stammzertifikat erstellt wurde"); 
     return UNTRUSTED_ROOT; 
    } 
    else if (chainElement.Current.Matches(statusQuery3))     { 
     System.Console.WriteLine("Fehler bei der Pfadüberprüfung für das Zertifikat von subjectName:" + subjectName + " (" + fileRef + ") da die Signatur nicht überprüft werden konnte."); 
     return SIGNATURE_INVALID; 
    } 
    else if (chainElement.Current.Matches(statusQuery2))     { 
     System.Console.WriteLine("Fehler bei der Sperrüberprüfung für das Zertifikat von subjectName:" + subjectName + " (" + fileRef + ") da der Prüfserver offline war"); 
     return RETRIEVAL_ERROR; 
    } 
    else if (chainElement.Current.Matches(statusQuery1))     { 
     System.Console.WriteLine("Sperrstatus für das Zertifikat von subjectName:" + subjectName + " (" + fileRef + ") konnte nicht festgelegt werden"); 
     return REVOCATION_FAILURE; 
    } 
    else if (chainElement.Current.Matches(statusQuery6))    { 
     System.Console.WriteLine("Certificate is revoked"); 
     return REVOKED; 
    } 
   } 
   return OTHER_ERROR; 
  }
  
//Die XML-Ereignisprotokolldatei ist das Befehlszeilenargument zum Programm 
  static void Main(string[] args)  { 
   PatternIdentifier mainProg = new PatternIdentifier(args); 
   XmlNode root = mainProg.doc.DocumentElement; 
//Identifizieren Sie die TaskId zu allen Fehlerereignissen 
   XmlNodeList errEvents = root.SelectNodes("//ns:Event[ns:System/ns:Level=2]//ns:CorrelationAuxInfo",mainProg.nsmanager); 
   ArrayList tasks = new ArrayList(); 
   foreach (XmlNode errEvent in errEvents)   { 
    string taskId = null; 
    taskId = mainProg.GetTaskId(errEvent); 
    if (!mainProg.isInArray(tasks, taskId))    { 
     tasks.Add(taskId); 
    } 
   } 
//Korrelieren Sie zu jeder TaskId alle Ereignisse mit derselben taskId, und identifzieren Sie im korrelierten Ereignissatz ein Fehlermuster. 
   for (int i = 0; i < tasks.Count; ++i)   { 
    string TaskId = (string)tasks[i]; 
    XPathExpression eventQuery = mainProg.xpath.Compile("//ns:CorrelationAuxInfo[@TaskId='" + TaskId + "']/parent::*");     eventQuery.SetContext(mainProg.nsmanager); 
    XPathNodeIterator eventNodes = mainProg.xpath.Select(eventQuery); 
    mainProg.IdentifyPattern(eventNodes,TaskId); 
   } 
   System.Console.Read(); 
  } 
 } 
}

Anhang D: Filtern mithilfe der Ereignisanzeige

Zum Filtern bestimmter Ereignisse können Sie manuelle Abfragen in die Ereignisanzeige eingeben.

So geben Sie manuelle Abfragen in die Ereignisanzeige ein
  1. Öffnen Sie die Ereignisanzeige. Klicken Sie zum Öffnen der Ereignisanzeige imStartmenü auf Systemsteuerung, doppelklicken Sie auf Verwaltung, und doppelklicken Sie dann auf Ereignisanzeige.

  2. Wenn das Dialogfeld Benutzerkontensteuerung eingeblendet wird, bestätigen Sie die angegebene Aktion und klicken dann auf Weiter.

  3. Erweitern Sie im Konsolenbereich Ereignisanzeige, erweitern Sie Anwendungs- und Dienstprotokolle sowie Microsoft und Windows, und erweitern Sie anschließend CAPI2.

  4. Klicken Sie mit der rechten Maustaste auf Betriebsbereit, und wählen Sie Aktuelles Protokoll filtern aus.

  5. Wählen Sie die Registerkarte XML aus, und aktivieren Sie das Kontrollkästchen Manuell bearbeiten.

  6. Geben Sie zum Filtern des Protokolls eine entsprechende Abfrage in das Textfeld ein.

    1. Wenn Sie nach allen CertGetCertificateChain-Fehlerereignisse mit dem Prozessnamen iexplore.exe suchen möchten, geben Sie die folgende Abfrage in das Textfeld ein:

      <QueryList> <Query Id="0" Path="Microsoft-Windows-CAPI2/Operational"> <Select Path="Microsoft-Windows-CAPI2/Operational">Event[System[(Level=2)] und UserData[CertGetCertificateChain[EventAuxInfo[@ProcessName='iexplore.exe']]]]</Select> </Query> </QueryList>
      
    2. Wenn Sie korrelierten Ereignisse ermitteln möchten, die dem CertGetCertificateChain-Fehlerereignis entsprechen, können Sie im Filter der Ereignisanzeige die folgende Abfrage verwenden ({taskid} entspricht hier der Task-ID für das CertGetCertificateChain-Fehlerereignis):

      <QueryList> <Query Id="0" Path="Microsoft-Windows-CAPI2/Operational"> <Select Path="Microsoft-Windows-CAPI2/Operational">*[*[*[CorrelationAuxInfo[@TaskId='{taskid}']]]]</Select> </Query> </QueryList>
      

Anhang E: Zertifikatbezogene Tools für Windows

Die CAPI2-Diagnose ist unter Windows Vista verfügbar. Es stehen vorhandene Diagnosetools zur Verfügung, die zur Problembehandlung unter früheren Windows-Versionen verwendet werden können. Mit dem Tool CryptoAPI Monitor (CAPIMON) kann der Administrator die CryptoAPI-Aufrufe und die Ergebnisse einer Anwendung überwachen. CAPIMON wurde zur Problembehandlung in vorhandenen Anwendungen entwickelt, von denen Fehler nicht ordnungsgemäß gemeldet werden. Hiermit wird die Eingabe und die Ausgabe bestimmter APIs erfasst, anstatt auf die Aufzeichnung oder Protokollierung von Fehlern durch die Anwendung zu vertrauen. CAPIMON eignet sich gut zur Problembehandlung unter früheren Windows-Versionen in Situationen, wo es nicht möglich ist, die Ursache von Fehlern in der Fehleraufzeichnung der Anwendung zu finden. Sie können CAPIMON unter http://go.microsoft.com/fwlink/?LinkId=82293 (möglicherweise in englischer Sprache) herunterladen.

Zum Überprüfen von Zertifikaten, Schlüsselpaaren und Zertifikatketten können Sie das Befehlszeilentool certutil.exe verwenden. Außerdem können in Certutil.exe Zertifikatdienste konfiguriert und die Konfigurationsinformationen angezeigt werden. Weitere Informationen zu Certutil finden Sie unter http://go.microsoft.com/fwlink/?LinkId=82294 (möglicherweise in englischer Sprache).

Weitere Informationen

Weitere Informationen finden Sie in den folgenden Dokumenten (möglicherweise in englischer Sprache):

  1. RFC: "Internetprofil für Public Key-Infrastruktur-Zertifikat und -Zertifikatsperrliste"

  2. RFC: "X.509-Internet-PKI-OCSP"

  3. Problembehandlung bei der Zertifikatsperrung und Statusüberprüfung

  4. Bewährt Methoden zum Implementieren einer Public Key-Infrastruktur unter Microsoft Windows Server 2003

  5. Windows Vista-Datenschutzrichtlinie

  6. Kryptografiefunktionen

  7. Reduzieren der Supportkosten mit Windows Vista

  8. Verweisen auf Infosets mit XPATH

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2014 Microsoft