O certificado da pasarela está ben: por que o inicio de sesión IKEv2 PEAP segue fallando

O certificado da súa pasarela VPN está vixente, a cadea valídase e o cliente IKEv2 segue rexeitando o inicio de sesión cunha mensaxe sobre un intervalo de validez de certificado. O primeiro impulso é reemitir o certificado da pasarela ou cambiar o método EAP, e ambos adoitan ser un erro. O intento de inicio de sesión leva dúas identidades de servidor distintas: o certificado da pasarela que usa IKE e o certificado que presenta quen remata PEAP. Unha delas está ben, e a outra é a razón pola que o cliente se detivo.

Dúas identidades, un intento de inicio de sesión

O certificado do perfil VPN pertence ao intercambio IKE: demostra que a pasarela é o par que nomea o perfil, baixo a política IKE configurada. O certificado que falla aquí pertence a outra conversa, a sesión TLS que PEAP abre con quen autentica o usuario, que a miúdo é un servidor RADIUS como NPS e non a propia pasarela. Unha terceira comprobación, a credencial do usuario, ocorre dentro desa sesión. Un contrasinal válido non pode reparar un certificado de servidor caducado, e un certificado de pasarela válido non pode responder polo punto final PEAP.

Esta disposición en capas explica por que aparece un erro de certificado nun lugar onde o único certificado que alguén configurou era o da pasarela. Tamén explica por que reemitir ese certificado non cambia nada.

Lea a liña do rexistro contra a etapa

Atope a mensaxe que nomea o motivo e as datas. Unha queixa sobre o intervalo de validez xunto a un erro de suxeito significa que o servidor rexeitou o certificado que se lle deu, non que o usuario rexeitase o inicio de sesión. Despois atope a etapa: un rexistro charon de strongSwan mostra IKE_SA .* established antes de que comece o intercambio EAP, así que un erro de certificado despois desa liña pertence á identidade EAP, mentres que un erro anterior apunta á pasarela. O texto da etapa no panel de conexión dun cliente Windows di o mesmo.

Comprobe o reloxo do cliente antes de tocar calquera certificado. Un dispositivo que vai horas desfasado produce o mesmo erro de validez que un certificado realmente caducado. Axustar o reloxo é unha corrección de cinco segundos, e substituír un certificado que nunca foi o problema é unha caída.

Averigüe que extremo remata PEAP

Nun deseño de pasarela máis RADIUS, a pasarela reenvía EAP e non o remata. O complemento eap-radius de strongSwan entrega o intercambio ao servidor RADIUS, que posúe a sesión TLS de PEAP e o seu certificado. Correlacione un intento fallido nos dous rexistros e confirme que proceso escolleu realmente un certificado para esa sesión.

Para NPS o certificado debe estar no almacén do equipo local, levar o propósito de autenticación de servidor, coincidir co nome que esperan os clientes e ser lexible pola conta de servizo. Os requisitos de certificados de Microsoft para NPS enumeran esas condicións. Outros servidores EAP teñen as súas propias regras de selección, así que non copie as particularidades de NPS nunha implementación de FreeRADIUS nin ao revés. A regra que vale en ambos os casos é que o extremo que remata PEAP posúe o certificado que está a piques de cambiar.

Substitua o certificado onde remata EAP

Renove ou substitua o certificado no extremo que remata PEAP, mediante o proceso admitido, conservando o propósito de autenticación de servidor e o nome esperado. Instale a cadea completa onde o servizo a busca e conceda ao servizo acceso á clave privada. Reinicie ou volva vincular o servizo, porque moitos servizos gardan o certificado antigo en memoria e seguen presentándoo. Un ficheiro copiado na máquina non demostra nada sobre que certificado presenta realmente o servizo.

Confirme o cambio correlacionando o seguinte intento co rexistro propio do servizo, ou inspeccionando o certificado que presentou a sesión. Se ese rexistro aínda mostra a impresión antiga, o reinicio non funcionou.

Non supoña que o ficheiro máis recente dun directorio é o que se usa. Unha copia co nome correcto e os permisos equivocados non cambia nada. Xulgue o cambio pola identidade presentada, non pola marca de tempo dun ficheiro.

Que non facer

Non desactive a validación de PEAP nin force un método interno máis feble para superar o erro. Iso cambia a política e elimina a propiedade de autenticación de servidor que atrapou o certificado caducado en primeiro lugar. Cambiaría unha comprobación que funciona por unha conexión que funciona, e o seguinte certificado caducado chegaría sen nada que o anunciase.

Non tome unha conexión correcta doutro sistema operativo como proba de que o certificado é aceptable. Ese cliente pode usar outro método EAP, outro almacén de confianza ou ningunha validación de servidor, así que o seu éxito non di nada sobre a comprobación que fallou aquí. Manteña unha proba negativa deliberada, como un certificado co nome equivocado ou unha cadea non confiable, que falle como se espera. Se esa proba agora pasa, eliminou unha comprobación en lugar de arranxar un certificado. Anote que identidade fallou, para que a seguinte persoa non comece outra vez co certificado da pasarela.