PIV-Anmeldung scheitert unter Windows mit EAP-TLS? Prüfen Sie den Signaturpfad

Zeigen Sie das Zertifikat einer PIV-Karte in jedem Windows-Dialog an, und die VPN-Anmeldung kann trotzdem scheitern, weil Sichtbarkeit und Nutzbarkeit verschiedene Eigenschaften sind. Das Zertifikat ist ein öffentliches Objekt; die Anmeldung benötigt eine Privatschlüssel-Operation, die die Karte nach ihren eigenen Zugriffsregeln ausführt. Zwischen diesen beiden Tatsachen liegen vier Stufen, die auf vier verschiedene Arten scheitern: Profilauswahl, Zertifikatsauswahl, lokale Signatur und Validierung auf der Serverseite. Wer sie der Reihe nach durchgeht, verwandelt einen allgemeinen Handshake-Fehler in eine konkrete Frage für denjenigen, dem das nächste Stück gehört.

Beginnen Sie mit dem Profil und der EAP-Methode

Öffnen Sie die Eigenschaften der Verbindung und lesen Sie, welche EAP-Methode das Profil tatsächlich verwendet, und lesen Sie dann, welches Zertifikat die Methode auswählen soll. Viele Umgebungen haben sowohl eine zertifikatsbasierte äußere Methode als auch eine innere Methode, und ein auf Verbindungsebene konfiguriertes Zertifikat ist nicht automatisch das, das innerhalb von EAP-TLS vorgelegt wird. Wenn das Profil ein Zertifikat nach Aussteller oder nach Betrefffilter auswählt, wählt dieser Filter aus dem, was Windows im jeweiligen Speicher sehen kann, nicht aus dem, was die Karte zufällig enthält. Ein Filter, der auf nichts passt, fällt je nach Konfiguration des Profils auf eine Abfrage oder auf ein stilles Scheitern zurück, weshalb es sich lohnt, den ausgewählten Fingerabdruck vor jeder Änderung zu notieren.

Stellen Sie außerdem fest, ob die Verbindung als angemeldeter Benutzer oder als Computer läuft. Diese eine Tatsache entscheidet, welche Zertifikatsspeicher im Geltungsbereich liegen und welcher Sicherheitskontext die Signatur ausführt.

Bestätigen Sie, welches Zertifikat ausgewählt wurde

Vergleichen Sie den Fingerabdruck, den Windows gewählt hat, mit der Anforderung: Verwendung zur Clientauthentifizierung, eine Kette, die in einer vertrauenswürdigen Stammstelle endet, eine Identität, die die Richtlinie des Authentifizierungsservers abbildet, und ein Gültigkeitszeitraum, der den tatsächlichen Moment des Versuchs abdeckt. Das sind getrennte Prüfungen, und die letzte fängt mehr Überraschungen ab, als man erwartet, besonders bei laufend ausgestellten Zertifikaten und zwischengespeicherten Profilen, die noch auf die gestrige Auswahl zeigen.

Benutzer- und Computerkontext ist die andere Hälfte der Prüfung. Ein Zertifikat im persönlichen Speicher des Benutzers ist für einen Dienst, der als Computer läuft, unsichtbar, und ein Computerzertifikat wird von einem EAP-Austausch im Benutzermodus nicht vorgelegt, wenn das Profil nichts anderes sagt. Wird ein Zertifikat in den falschen Speicher reimportiert, entsteht ein sichtbares Zertifikat und eine unsichtbare Anmeldeinformation. Lesen Sie den Speicherpfad im Profil, nicht den im Dialog, der sich zufällig geöffnet hat.

Testen Sie die Schlüsseloperation, ohne die PIN zu raten

Ist die Auswahl geklärt, lautet die Frage, ob die Karte die Signatur ausführt. Windows braucht einen unterstützten Kartenanbieter oder Minidriver, um an den privaten Schlüssel zu gelangen, und das Gerät wendet seine eigenen PIN- und Anwesenheitsregeln auf die Operation an. Eine Karte, die für jede Signatur eine Berührung verlangt, verhält sich anders als eine, die eine Verifikation für eine Sitzung zwischenspeichert, und beides sind legitime Konfigurationen, die ändern, wann eine Abfrage erscheint. Dieser Unterschied erklärt eine Anmeldung, die beim frischen Einstecken gelingt und nach einem Fortsetzen scheitert, ohne dass ein Zertifikat falsch wäre.

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

Der erste Befehl inventarisiert die Karte und meldet Leser- und Anbieterstatus, was in Microsofts Anleitung zur Fehlerbehebung bei Smartcards dokumentiert ist. Der zweite listet auf, was der Benutzerkontext tatsächlich sehen kann. Keiner von beiden beweist eine erfolgreiche Authentifizierung; beide grenzen ein, wo es aufgehört hat.

Raten Sie die PIN nicht. Karten erzwingen Wiederholungsgrenzen, und ein paar optimistische Versuche verwandeln ein Berechtigungsproblem in eine gesperrte Anmeldeinformation, die eine administrative Wiederherstellung braucht. Scheitert eine lokale Signatur, erfassen Sie den Anbieterstatus und den Kartenzustand, statt Varianten zu probieren. Wiederholen Sie den Versuch einmal mit demselben Profil, demselben Zertifikat und einem bekannt guten Leserpfad, und vergleichen Sie dann die beiden Aufzeichnungen; mehrere Variablen auf einmal zu ändern ergibt eine Geschichte statt eines Ergebnisses.

Lesen Sie beide Seiten des Handshakes

Eine abgeschlossene Signatur ist noch keine Zulassung. Der Authentifizierungsserver muss die Kette akzeptieren, den Widerruf prüfen, die Identität nach seinen aktuellen Regeln abbilden und die Anfrage autorisieren; der Client muss seinerseits das Serverzertifikat validieren, wie es das Profil verlangt. Eine vom Server erzeugte TLS-Warnung sieht im Client-Protokoll genauso aus wie eine lokal erzeugte, weshalb die ausgebende Seite mehr zählt als der Warnungstext.

Sammeln Sie die Windows-Ereignisse und die Ereignisse auf der Serverseite mit abgeglichenen Zeitstempeln und bestimmen Sie dann, welche Seite den ersten Fehler erzeugt hat. RFC 5216 beschreibt den Schritt des Besitznachweises in EAP-TLS, und eine allgemeine Handshake-Warnung benennt für sich genommen keine lokale Schlüsselursache. Der Zeitstempelvergleich ist es, der zwei Protokolle in eine Abfolge verwandelt.

Halten Sie die Grenzen im Bericht sauber

Schreiben Sie den Bericht als vier Stufen mit je einem Urteil: welches Profil und welcher Kontext gelaufen ist, welches Zertifikat Windows ausgewählt hat, ob die Karte signiert hat und was der Server entschieden hat. Diese Struktur macht den nächsten Schritt offensichtlich und verhindert die übliche Reparatur, die Validierung abzuschalten, um an einer Stufe vorbeizukommen, die niemand identifiziert hat.

Ein Softwarezertifikat als vorübergehender Vergleich ist ein legitimer Administratorentest, aber es ändert das Modell von Anmeldeinformation und Zusicherung, gehört also in eine genehmigte Änderung und nicht in eine stille Umgehung in der Produktion. Dieselbe Disziplin gilt für PIN-Versuche und für das Neuausstellen von Anmeldeinformationen, bevor die scheiternde Stufe bekannt ist. Eine Ersatzkarte, die identisch scheitert, ist ein teurer Beweis dafür, dass das Problem nie auf der Karte lag.