Autentificarea PIV eșuează pe Windows EAP-TLS? Verificați calea de semnare

Afișați certificatul unui card PIV în fiecare dialog Windows și autentificarea VPN poate eșua în continuare, pentru că vizibilitatea și utilizabilitatea sunt proprietăți diferite. Certificatul este un obiect public; autentificarea cere o operațiune cu cheie privată efectuată de card după propriile reguli de acces. Între aceste două fapte se află patru etape care eșuează în patru moduri diferite: selectarea profilului, selectarea certificatului, semnarea locală și validarea pe partea de server. Parcurgerea lor în ordine transformă o eroare generică de handshake într-o întrebare concretă pentru cel care deține următoarea piesă.

Începeți cu profilul și metoda EAP

Deschideți proprietățile conexiunii și citiți ce metodă EAP folosește de fapt profilul, apoi citiți ce certificat este configurată metoda să selecteze. Multe implementări au atât o metodă exterioară bazată pe certificat, cât și o metodă interioară, iar un certificat configurat la nivelul conexiunii nu este automat cel prezentat în interiorul EAP-TLS. Dacă profilul alege un certificat după emitent sau după un filtru de subiect, acel filtru selectează din ce vede Windows în magazinul relevant, nu din ce conține cardul din întâmplare. Un filtru care nu se potrivește cu nimic trece la o solicitare sau la o eșuare silențioasă, în funcție de configurația profilului, motiv pentru care merită înregistrată amprenta selectată înainte de orice modificare.

Stabiliți și dacă conexiunea rulează ca utilizatorul autentificat sau ca mașina. Acest singur fapt decide ce magazine de certificate sunt în scop și ce context de securitate efectuează semnătura.

Confirmați ce certificat a fost selectat

Comparați amprenta aleasă de Windows cu cerința: utilizare pentru autentificarea clientului, un lanț care se termină într-o rădăcină de încredere, o identitate pe care politica serverului de autentificare o mapează și o perioadă de valabilitate care acoperă momentul efectiv al încercării. Acestea sunt verificări separate, iar ultima prinde mai multe surprize decât se așteaptă oamenii, mai ales cu certificate emise în mod rotativ și profiluri cache care încă indică selecția de ieri.

Contextul de utilizator și de mașină este cealaltă jumătate a verificării. Un certificat din magazinul personal al utilizatorului este invizibil pentru un serviciu care rulează ca mașina, iar un certificat de mașină nu este prezentat de un schimb EAP în modul utilizator decât dacă profilul o spune. Reimportarea unui certificat în magazinul greșit produce un certificat vizibil și o acreditare de autentificare invizibilă. Citiți calea magazinului din profil, nu pe cea din dialogul care s-a deschis din întâmplare.

Testați operațiunea cu cheia fără a ghici PIN-ul

După ce selecția este stabilită, întrebarea este dacă cardul va efectua semnătura. Windows are nevoie de un furnizor de card sau de un minidriver acceptat pentru a ajunge la cheia privată, iar dispozitivul aplică propriile reguli de PIN și de prezență operațiunii. Un card configurat să ceară o atingere pentru fiecare semnătură se comportă diferit de unul care memorează o verificare pentru o sesiune, iar ambele sunt configurații legitime care schimbă momentul în care apare o solicitare. Această diferență explică o autentificare care reușește după o introducere proaspătă și eșuează după o reluare, fără ca vreun certificat să fie greșit.

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

Prima comandă inventariază cardul și raportează starea cititorului și a furnizorului, ceea ce este documentat în îndrumările Microsoft pentru depanarea cardurilor inteligente. A doua listează ce poate vedea efectiv contextul de utilizator. Niciuna nu dovedește o autentificare reușită; ambele îngustează locul unde s-a oprit.

Nu ghiciți PIN-ul. Cardurile impun limite de reîncercare, iar câteva încercări optimiste transformă o problemă de permisiuni într-o acreditare blocată care necesită recuperare administrativă. Dacă o semnătură locală eșuează, înregistrați starea furnizorului și starea cardului în loc să încercați variante. Repetați încercarea o dată cu același profil, același certificat și o cale de cititor cunoscută ca bună, apoi comparați cele două înregistrări; schimbarea mai multor variabile deodată produce o poveste, nu un rezultat.

Citiți ambele părți ale handshake-ului

O semnătură finalizată nu este încă admitere. Serverul de autentificare trebuie să accepte lanțul, să verifice revocarea, să mapeze identitatea după regulile sale actuale și să autorizeze cererea; clientul trebuie, la rândul său, să valideze certificatul serverului așa cum cere profilul. O alertă TLS generată de server arată identic în jurnalul clientului cu una generată local, motiv pentru care partea care o emite contează mai mult decât textul alertei.

Colectați evenimentele Windows și evenimentele din partea serverului cu marcaje de timp aliniate, apoi identificați care parte a produs prima eșuare. RFC 5216 descrie pasul de dovadă a deținerii în EAP-TLS, iar o alertă generică de handshake nu numește de la sine o cauză locală a cheii. Compararea marcajelor de timp este ceea ce transformă două jurnale într-o secvență.

Păstrați limitele drepte în raport

Scrieți raportul ca patru etape cu câte un verdict: ce profil și context au rulat, ce certificat a selectat Windows, dacă cardul a semnat și ce a decis serverul. Această structură face pasul următor evident și împiedică reparația obișnuită de a dezactiva validarea pentru a trece de o etapă pe care nimeni nu a identificat-o.

Un certificat software ca comparație temporară este un test administrativ legitim, dar schimbă modelul de acreditare și de asigurare, așa că aparține unei modificări aprobate, nu unei ocoliiri silențioase în producție. Aceeași disciplină se aplică încercărilor de PIN și reemiterii acreditărilor înainte de a se cunoaște etapa care eșuează. Un card de schimb care eșuează identic este o dovadă costisitoare că problema nu a fost niciodată pe card.