¿Falla el inicio de sesión PIV en Windows con EAP-TLS? Revise la ruta de firma

Muestre el certificado de una tarjeta PIV en cada diálogo de Windows y el inicio de sesión VPN puede fallar igualmente, porque visibilidad y usabilidad son propiedades distintas. El certificado es un objeto público; el inicio de sesión necesita una operación de clave privada que realiza la tarjeta según sus propias reglas de acceso. Entre esos dos hechos hay cuatro etapas que fallan de cuatro maneras distintas: selección de perfil, selección de certificado, firma local y validación en el lado del servidor. Recorrerlas en orden convierte un error genérico de negociación en una pregunta concreta para quien posee la pieza siguiente.

Empiece por el perfil y el método EAP

Abra las propiedades de la conexión y lea qué método EAP usa realmente el perfil, y después lea qué certificado está configurado para seleccionar el método. Muchas implementaciones tienen a la vez un método externo basado en certificado y un método interno, y un certificado configurado a nivel de conexión no es automáticamente el que se presenta dentro de EAP-TLS. Si el perfil elige un certificado por emisor o por filtro de sujeto, ese filtro elige entre lo que Windows puede ver en el almacén correspondiente, no entre lo que la tarjeta contiene. Un filtro que no coincide con nada vuelve a un aviso o a un fallo silencioso según la configuración del perfil, por lo que conviene anotar la huella seleccionada antes de cualquier cambio.

Determine también si la conexión se ejecuta como el usuario que inició sesión o como el equipo. Ese único hecho decide qué almacenes de certificados entran en el ámbito y qué contexto de seguridad realiza la firma.

Confirme qué certificado se seleccionó

Compare la huella que Windows eligió con el requisito: uso para autenticación de cliente, una cadena que termina en una raíz de confianza, una identidad que la directiva del servidor de autenticación asigna y un periodo de validez que cubra el momento real del intento. Son comprobaciones separadas y la última atrapa más sorpresas de las que la gente espera, sobre todo con certificados emitidos de forma continua y perfiles en caché que siguen apuntando a la selección de ayer.

El contexto de usuario y de equipo es la otra mitad de la comprobación. Un certificado en el almacén personal del usuario es invisible para un servicio que se ejecuta como el equipo, y un certificado de equipo no lo presenta un intercambio EAP en modo usuario salvo que el perfil lo indique. Reimportar un certificado en el almacén equivocado produce un certificado visible y una credencial de inicio de sesión invisible. Lea la ruta del almacén en el perfil, no la del diálogo que se abrió por casualidad.

Pruebe la operación de clave sin adivinar el PIN

Una vez resuelta la selección, la pregunta es si la tarjeta realizará la firma. Windows necesita un proveedor de tarjeta compatible o un minidriver para llegar a la clave privada, y el dispositivo aplica sus propias reglas de PIN y de presencia a la operación. Una tarjeta configurada para exigir un toque en cada firma se comporta de forma distinta a una que guarda una verificación para una sesión, y ambas son configuraciones legítimas que cambian cuándo aparece un aviso. Esa diferencia explica un inicio de sesión que funciona en una inserción nueva y falla tras reanudar, sin que ningún certificado sea incorrecto.

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

El primer comando inventaría la tarjeta e informa del estado del lector y del proveedor, lo que está documentado en la guía de Microsoft para depurar tarjetas inteligentes. El segundo enumera qué puede ver realmente el contexto de usuario. Ninguno demuestra una autenticación correcta; ambos acotan dónde se detuvo.

No adivine el PIN. Las tarjetas imponen límites de reintentos, y unos cuantos intentos optimistas convierten un problema de permisos en una credencial bloqueada que necesita recuperación administrativa. Si falla una firma local, capture el estado del proveedor y el estado de la tarjeta en lugar de probar variantes. Repita el intento una vez con el mismo perfil, el mismo certificado y una ruta de lector conocida como buena, y luego compare los dos registros; cambiar varias variables a la vez produce un relato y no un resultado.

Lea ambos lados de la negociación

Una firma completada todavía no es admisión. El servidor de autenticación debe aceptar la cadena, comprobar la revocación, asignar la identidad según sus reglas actuales y autorizar la solicitud; el cliente, a su vez, debe validar el certificado del servidor como exige el perfil. Una alerta TLS generada por el servidor se ve en el registro del cliente igual que una generada localmente, por lo que el lado que la emite importa más que el texto de la alerta.

Recoja los eventos de Windows y los del lado del servidor con marcas de tiempo alineadas, y después identifique qué lado produjo el primer fallo. RFC 5216 describe el paso de prueba de posesión en EAP-TLS, y una alerta genérica de negociación no nombra por sí sola una causa local de clave. La comparación de marcas de tiempo es lo que convierte dos registros en una secuencia.

Mantenga los límites claros en el informe

Escriba el informe como cuatro etapas con un veredicto cada una: qué perfil y contexto se ejecutaron, qué certificado seleccionó Windows, si la tarjeta firmó y qué decidió el servidor. Esa estructura hace obvio el paso siguiente y evita la reparación habitual de desactivar la validación para superar una etapa que nadie identificó.

Un certificado de software como comparación temporal es una prueba legítima de administrador, pero cambia el modelo de credenciales y de garantía, así que corresponde a un cambio aprobado y no a una solución silenciosa en producción. La misma disciplina se aplica a los intentos de PIN y a la reemisión de credenciales antes de conocer la etapa que falla. Una tarjeta de sustitución que falla igual es una prueba cara de que el problema nunca estuvo en la tarjeta.