Mostreu el certificat d’una targeta PIV a cada diàleg de Windows i l’inici de sessió a la VPN pot fallar igualment, perquè visibilitat i usabilitat són propietats diferents. El certificat és un objecte públic; l’inici de sessió necessita una operació de clau privada que fa la targeta segons les seves pròpies regles d’accés. Entre aquests dos fets hi ha quatre etapes que fallen de quatre maneres diferents: selecció de perfil, selecció de certificat, signatura local i validació al costat del servidor. Recórrer-les en ordre converteix un error genèric d’encaixada en una pregunta concreta per a qui té la peça següent.

Comenceu pel perfil i pel mètode EAP

Obriu les propietats de la connexió i llegiu quin mètode EAP fa servir realment el perfil, i després llegiu quin certificat està configurat per seleccionar el mètode. Moltes implementacions tenen alhora un mètode exterior basat en certificat i un mètode interior, i un certificat configurat a nivell de connexió no és automàticament el que es presenta dins d’EAP-TLS. Si el perfil tria un certificat per emissor o per filtre de subjecte, aquest filtre tria entre el que Windows pot veure al magatzem pertinent, no entre el que la targeta conté. Un filtre que no coincideix amb res torna a una sol·licitud o a un fracàs silenciós segons la configuració del perfil, i per això val la pena enregistrar l’empremta seleccionada abans de qualsevol canvi.

Establiu també si la connexió s’executa com a usuari amb sessió iniciada o com a màquina. Aquest sol fet decideix quins magatzems de certificats entren en abast i quin context de seguretat fa la signatura.

Confirmeu quin certificat s’ha seleccionat

Compareu l’empremta que Windows ha triat amb el requisit: ús per a autenticació de client, una cadena que acaba en una arrel de confiança, una identitat que la política del servidor d’autenticació assigna i un període de validesa que cobreixi el moment real de l’intent. Són comprovacions separades i l’última atrapa més sorpreses del que la gent espera, sobretot amb certificats emesos de manera continuada i perfils en memòria cau que encara apunten a la selecció d’ahir.

El context d’usuari i de màquina és l’altra meitat de la comprovació. Un certificat al magatzem personal de l’usuari és invisible per a un servei que s’executa com a màquina, i un certificat de màquina no el presenta un intercanvi EAP en mode usuari tret que el perfil ho digui. Reimportar un certificat al magatzem equivocat produeix un certificat visible i una credencial d’inici de sessió invisible. Llegiu el camí del magatzem al perfil, no el del diàleg que s’ha obert per casualitat.

Proveu l’operació de clau sense endevinar el PIN

Un cop resolta la selecció, la pregunta és si la targeta farà la signatura. Windows necessita un proveïdor de targeta compatible o un minidriver per arribar a la clau privada, i el dispositiu aplica les seves pròpies regles de PIN i de presència a l’operació. Una targeta configurada per exigir un toc a cada signatura es comporta de manera diferent d’una que desa una verificació per a una sessió, i totes dues són configuracions legítimes que canvien quan apareix una sol·licitud. Aquesta diferència explica un inici de sessió que funciona en una inserció nova i falla després de reprendre, sense que cap certificat sigui incorrecte.

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

La primera ordre inventaria la targeta i informa de l’estat del lector i del proveïdor, cosa que es documenta a l’orientació de Microsoft per a la depuració de targetes intel·ligents. La segona llista què pot veure realment el context d’usuari. Cap de les dues demostra una autenticació correcta; totes dues estrenyen on s’ha aturat.

No endevineu el PIN. Les targetes apliquen límits de reintents, i uns quants intents optimistes converteixen un problema de permisos en una credencial bloquejada que necessita recuperació administrativa. Si falla una signatura local, captureu l’estat del proveïdor i l’estat de la targeta en lloc de provar variants. Repetiu l’intent una vegada amb el mateix perfil, el mateix certificat i un camí de lector conegut com a bo, i després compareu els dos registres; canviar diverses variables alhora produeix una història i no un resultat.

Llegiu les dues bandes de l’encaixada

Una signatura completada encara no és admissió. El servidor d’autenticació ha d’acceptar la cadena, comprovar la revocació, assignar la identitat segons les seves regles actuals i autoritzar la petició; el client, al seu torn, ha de validar el certificat del servidor tal com exigeix el perfil. Una alerta TLS generada pel servidor es veu al registre del client igual que una generada localment, i per això el costat que l’emet importa més que el text de l’alerta.

Recolliu els esdeveniments de Windows i els del costat del servidor amb marques de temps alineades, i després identifiqueu quin costat ha produït la primera fallada. RFC 5216 descriu el pas de prova de possessió a EAP-TLS, i una alerta genèrica d’encaixada no anomena per si sola cap causa local de clau. La comparació de marques de temps és el que converteix dos registres en una seqüència.

Mantingueu les fronteres clares a l’informe

Escriviu l’informe com a quatre etapes amb un veredicte cadascuna: quin perfil i context s’han executat, quin certificat ha seleccionat Windows, si la targeta ha signat i què ha decidit el servidor. Aquesta estructura fa òbvia la passa següent i evita la reparació habitual de desactivar la validació per passar una etapa que ningú no ha identificat.

Un certificat de programari com a comparació temporal és una prova legítima d’administrador, però canvia el model de credencials i de garantia, així que pertoca a un canvi aprovat i no a una solució alternativa silenciosa en producció. La mateixa disciplina s’aplica als intents de PIN i a la reemissió de credencials abans que es conegui l’etapa que falla. Una targeta de substitució que falla igual és una prova cara que el problema no era mai a la targeta.

Articles relacionats