¿Fallan o inicio de sesión PIV en Windows con EAP-TLS? Revise a ruta de sinatura

Mostre o certificado dunha tarxeta PIV en cada diálogo de Windows e o inicio de sesión VPN pode fallar igualmente, porque visibilidade e usabilidade son propiedades distintas. O certificado é un obxecto público; o inicio de sesión necesita unha operación de clave privada que realiza a tarxeta segundo as súas propias regras de acceso. Entre eses dous feitos hai catro etapas que fallan de catro maneiras distintas: selección de perfil, selección de certificado, sinatura local e validación no lado do servidor. Percorrelas en orde converte un erro xenérico de negociación nunha pregunta concreta para quen posúe a peza seguinte.

Comece polo perfil e polo método EAP

Abra as propiedades da conexión e lea que método EAP usa realmente o perfil, e despois lea que certificado está configurado para seleccionar o método. Moitas implantacións teñen á vez un método externo baseado en certificado e un método interno, e un certificado configurado a nivel de conexión non é automaticamente o que se presenta dentro de EAP-TLS. Se o perfil escolle un certificado por emisor ou por filtro de suxeito, ese filtro escolle entre o que Windows pode ver no almacén correspondente, non entre o que a tarxeta contén. Un filtro que non coincide con nada volve a unha solicitude ou a un fallo silencioso segundo a configuración do perfil, por iso convén anotar a impresión dixital seleccionada antes de calquera cambio.

Determine tamén se a conexión se executa como o usuario que iniciou sesión ou como o equipo. Ese único feito decide que almacéns de certificados entran no ámbito e que contexto de seguridade realiza a sinatura.

Confirme que certificado se seleccionou

Compare a impresión dixital que Windows escolleu co requisito: uso para autenticación de cliente, unha cadea que remata nunha raíz de confianza, unha identidade que a política do servidor de autenticación asigna e un período de validez que cubra o momento real do intento. Son comprobacións separadas e a última atrapa máis sorpresas do que a xente espera, sobre todo con certificados emitidos de forma continua e perfís na caché que seguen apuntando á selección de onte.

O contexto de usuario e de equipo é a outra metade da comprobación. Un certificado no almacén persoal do usuario é invisible para un servizo que se executa como o equipo, e un certificado de equipo non o presenta un intercambio EAP en modo usuario salvo que o perfil o indique. Reimportar un certificado no almacén equivocado produce un certificado visible e unha credencial de inicio de sesión invisible. Lea a ruta do almacén no perfil, non a do diálogo que se abriu por casualidade.

Probe a operación de clave sen adiviñar o PIN

Unha vez resolta a selección, a pregunta é se a tarxeta realizará a sinatura. Windows necesita un provedor de tarxeta compatible ou un minidriver para chegar á clave privada, e o dispositivo aplica as súas propias regras de PIN e de presenza á operación. Unha tarxeta configurada para esixir un toque en cada sinatura compórtase de forma distinta a unha que garda unha verificación para unha sesión, e ambas son configuracións lexítimas que cambian cando aparece unha solicitude. Esa diferenza explica un inicio de sesión que funciona nunha inserción nova e falla tras retomar, sen que ningún certificado sexa incorrecto.

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

O primeiro comando inventaría a tarxeta e informa do estado do lector e do provedor, o que está documentado na guía de Microsoft para depurar tarxetas intelixentes. O segundo enumera que pode ver realmente o contexto de usuario. Ningún demostra unha autenticación correcta; ambos acoutan onde se detivo.

Non adiviñe o PIN. As tarxetas impoñen límites de reintentos, e uns cantos intentos optimistas converten un problema de permisos nunha credencial bloqueada que necesita recuperación administrativa. Se falla unha sinatura local, capture o estado do provedor e o estado da tarxeta en lugar de probar variantes. Repita o intento unha vez co mesmo perfil, o mesmo certificado e unha ruta de lector coñecida como boa, e despois compare os dous rexistros; cambiar varias variábeis á vez produce un relato e non un resultado.

Lea ambos os dous lados da negociación

Unha sinatura completada aínda non é admisión. O servidor de autenticación debe aceptar a cadea, comprobar a revocación, asignar a identidade segundo as súas regras actuais e autorizar a solicitude; o cliente, pola súa parte, debe validar o certificado do servidor como esixe o perfil. Unha alerta TLS xerada polo servidor vese no rexistro do cliente igual que unha xerada localmente, por iso o lado que a emite importa máis que o texto da alerta.

Recompile os eventos de Windows e os do lado do servidor con marcas de tempo aliñadas, e despois identifique que lado produciu o primeiro fallo. RFC 5216 describe o paso de proba de posesión en EAP-TLS, e unha alerta xenérica de negociación non nomea por si soa unha causa local de clave. A comparación de marcas de tempo é o que converte dous rexistros nunha secuencia.

Manteña os límites claros no informe

Escriba o informe como catro etapas cun veredicto cada unha: que perfil e contexto se executaron, que certificado seleccionou Windows, se a tarxeta asinou e que decidiu o servidor. Esa estrutura fai obvio o paso seguinte e evita a reparación habitual de desactivar a validación para superar unha etapa que ninguén identificou.

Un certificado de software como comparación temporal é unha proba lexítima de administrador, pero cambia o modelo de credenciais e de garantía, así que pertence a un cambio aprobado e non a unha solución silenciosa en produción. A mesma disciplina se aplica aos intentos de PIN e á reemisión de credenciais antes de coñecer a etapa que falla. Unha tarxeta de substitución que falla igual é unha proba cara de que o problema nunca estivo na tarxeta.