El certificado de la puerta de enlace está bien: por qué el inicio de sesión IKEv2 PEAP sigue fallando

El certificado de su puerta de enlace VPN está vigente, la cadena se valida y el cliente IKEv2 sigue rechazando el inicio de sesión con un mensaje sobre un intervalo de validez de certificado. El primer impulso es reemitir el certificado de la puerta de enlace o cambiar el método EAP, y ambos suelen ser un error. El intento de inicio de sesión lleva dos identidades de servidor distintas: el certificado de la puerta de enlace que usa IKE y el certificado que presenta quien termina PEAP. Una de ellas está bien, y la otra es la razón por la que el cliente se detuvo.

Dos identidades, un intento de inicio de sesión

El certificado del perfil VPN pertenece al intercambio IKE: demuestra que la puerta de enlace es el par que nombra el perfil, bajo la política IKE configurada. El certificado que falla aquí pertenece a otra conversación, la sesión TLS que PEAP abre con quien autentica al usuario, que a menudo es un servidor RADIUS como NPS y no la propia puerta de enlace. Una tercera comprobación, la credencial del usuario, ocurre dentro de esa sesión. Una contraseña válida no puede reparar un certificado de servidor caducado, y un certificado de puerta de enlace válido no puede responder por el extremo PEAP.

Este apilamiento explica por qué aparece un error de certificado en un lugar donde el único certificado que alguien configuró era el de la puerta de enlace. También explica por qué reemitir ese certificado no cambia nada.

Lea la línea del registro contra la etapa

Busque el mensaje que nombra el motivo y las fechas. Una queja sobre el intervalo de validez junto a un error de sujeto significa que el servidor rechazó el certificado que se le entregó, no que el usuario rechazara el inicio de sesión. Luego localice la etapa: un registro charon de strongSwan muestra IKE_SA .* established antes de que empiece el intercambio EAP, así que un error de certificado después de esa línea pertenece a la identidad EAP, mientras que un error anterior apunta a la puerta de enlace. El texto de la etapa en el panel de conexión de un cliente Windows dice lo mismo.

Compruebe el reloj del cliente antes de tocar cualquier certificado. Un dispositivo que va horas desfasado produce el mismo error de validez que un certificado realmente caducado. Ajustar el reloj es una corrección de cinco segundos, y sustituir un certificado que nunca fue el problema es una caída.

Averigüe qué extremo termina PEAP

En un diseño de puerta de enlace más RADIUS, la puerta de enlace reenvía EAP y no lo termina. El complemento eap-radius de strongSwan entrega el intercambio al servidor RADIUS, que posee la sesión TLS de PEAP y su certificado. Correlacione un intento fallido en ambos registros y confirme qué proceso eligió realmente un certificado para esa sesión.

Para NPS el certificado debe estar en el almacén del equipo local, llevar el propósito de autenticación de servidor, coincidir con el nombre que esperan los clientes y ser legible por la cuenta de servicio. Los requisitos de certificados de Microsoft para NPS enumeran esas condiciones. Otros servidores EAP tienen sus propias reglas de selección, así que no copie las particularidades de NPS en una implementación de FreeRADIUS ni al revés. La regla que vale en ambos casos es que el extremo que termina PEAP posee el certificado que está a punto de cambiar.

Sustituya el certificado donde termina EAP

Renueve o sustituya el certificado en el extremo que termina PEAP, mediante el proceso admitido, conservando el propósito de autenticación de servidor y el nombre esperado. Instale la cadena completa donde el servicio la busca y conceda al servicio acceso a la clave privada. Reinicie o vuelva a enlazar el servicio, porque muchos servicios guardan el certificado antiguo en memoria y siguen presentándolo. Un archivo copiado en la máquina no demuestra nada sobre qué certificado presenta realmente el servicio.

Confirme el cambio correlacionando el siguiente intento con el registro propio del servicio, o inspeccionando el certificado que presentó la sesión. Si ese registro aún muestra la huella antigua, el reinicio no surtió efecto.

No suponga que el archivo más reciente de un directorio es el que se usa. Una copia con el nombre correcto y los permisos equivocados no cambia nada. Juzgue el cambio por la identidad presentada, no por la marca de tiempo de un archivo.

Qué no hacer

No desactive la validación de PEAP ni fuerce un método interno más débil para superar el error. Eso cambia la política y elimina la propiedad de autenticación de servidor que atrapó el certificado caducado en primer lugar. Cambiaría una comprobación que funciona por una conexión que funciona, y el siguiente certificado caducado llegaría sin nada que lo anunciara.

No tome una conexión correcta de otro sistema operativo como prueba de que el certificado es aceptable. Ese cliente puede usar otro método EAP, otro almacén de confianza o ninguna validación de servidor, así que su éxito no dice nada sobre la comprobación que falló aquí. Mantenga una prueba negativa deliberada, como un certificado con el nombre equivocado o una cadena no confiable, que falle como se espera. Si esa prueba ahora pasa, ha eliminado una comprobación en lugar de arreglar un certificado. Anote qué identidad falló, para que la siguiente persona no empiece otra vez con el certificado de la puerta de enlace.