El certificat de la passarel·la està bé: per què l’accés IKEv2 PEAP continua fallant
Un intercanvi PEAP valida el seu propi certificat TLS de servidor dins l’autenticació IKE. Compareu les dues identitats abans de substituir el certificat de la passarel·la.
El certificat de la vostra passarel·la VPN és vigent, la cadena es valida i el client IKEv2 encara rebutja l’accés amb un missatge sobre l’interval de validesa d’un certificat. L’instint és reemetre el certificat de la passarel·la o canviar el mètode EAP, i tots dos solen ser un error. L’intent d’accés porta dues identitats de servidor separades: el certificat de la passarel·la que fa servir IKE, i el certificat que presenta qui acabi el PEAP. Una d’elles està bé, i l’altra és la raó per la qual el client s’ha aturat.
Dues identitats, un sol intent d’accés
El certificat del perfil VPN pertany a l’intercanvi IKE: demostra que la passarel·la és el parell que el perfil anomena, sota la política IKE configurada. El certificat que falla aquí pertany a una altra conversa, la sessió TLS que PEAP obre amb qui autentica l’usuari, que sovint és un servidor RADIUS com NPS i no la mateixa passarel·la. Una tercera comprovació, la credencial de l’usuari, passa dins d’aquesta sessió. Una contrasenya vàlida no pot reparar un certificat de servidor caducat, i un certificat de passarel·la vàlid no pot avalar el punt final PEAP.
Aquesta disposició en capes explica per què apareix un error de certificat en un lloc on l’únic certificat que algú havia configurat era el de la passarel·la. També explica per què reemetre aquest certificat no canvia res.
Llegiu la línia del registre segons l’etapa
Trobeu el missatge que anomena el motiu i les dates. Una queixa sobre l’interval de validesa al costat d’un error de subjecte vol dir que el servidor ha rebutjat el certificat que se li ha donat, no que l’usuari hagi rebutjat l’accés. Després trobeu l’etapa: el registre charon de strongSwan mostra IKE_SA .* established abans que comenci l’intercanvi EAP, així que un error de certificat després d’aquesta línia pertany a la identitat EAP, mentre que un error abans apunta a la passarel·la. El text de l’etapa al tauler de connexió d’un client Windows diu el mateix.
Comproveu el rellotge del client abans de tocar cap certificat. Un dispositiu que va hores desviat produeix el mateix error de validesa que un certificat realment caducat. Reajustar el rellotge és una correcció de cinc segons, i substituir un certificat que mai no era el problema és una caiguda.
Trobeu quin punt final acaba el PEAP
En un disseny de passarel·la més RADIUS, la passarel·la reenvia EAP i no l’acaba. El connector eap-radius de strongSwan lliura l’intercanvi al servidor RADIUS, que posseeix la sessió TLS de PEAP i el seu certificat. Correlacioneu un intent fallit en tots dos registres i confirmeu quin procés va triar realment un certificat per a aquesta sessió.
Per a NPS el certificat ha de ser a l’emmagatzematge de l’ordinador local, dur el propòsit d’autenticació de servidor, coincidir amb el nom que els clients esperen i ser llegible pel compte de servei. Els requisits de certificat de Microsoft per a NPS enumeren aquestes condicions. Els altres servidors EAP tenen les seves pròpies regles de selecció, així que no copieu les particularitats de NPS en un desplegament FreeRADIUS ni al revés. La regla que se salva en tots dos casos és que el punt final que acaba el PEAP posseeix el certificat que esteu a punt de canviar.
Substituïu el certificat on acaba l’EAP
Renoveu o substituïu el certificat al punt final que acaba el PEAP, mitjançant el procés admès, conservant el propòsit d’autenticació de servidor i el nom esperat. Instal·leu la cadena completa on el servei la busca i concediu al servei accés a la clau privada. Reinicieu o torneu a enllaçar el servei, perquè molts serveis guarden el certificat antic en memòria i continuen presentant-lo. Un fitxer copiat a la màquina no demostra res sobre quin certificat presenta realment el servei.
Confirmeu el canvi correlacionant el proper intent amb el registre propi del servei, o inspeccionant el certificat que la sessió ha presentat. Si aquest registre encara mostra l’empremta antiga, el reinici no ha funcionat.
No pressuposeu que el fitxer més nou d’un directori sigui el que s’utilitza. Una còpia amb el nom correcte i els permisos equivocats no canvia res. Jutgeu el canvi per la identitat presentada, no per la marca de temps d’un fitxer.
Què no cal fer
No desactiveu la validació de PEAP ni forceu un mètode intern més feble per saltar l’error. Això canvia la política i elimina la propietat d’autenticació de servidor que va atrapar el certificat caducat des del principi. Canviaríeu una comprovació que funciona per una connexió que funciona, i el proper certificat caducat arribaria sense res que l’anunciés.
No prengueu una connexió correcta d’un altre sistema operatiu com a prova que el certificat és acceptable. Aquell client pot fer servir un altre mètode EAP, un altre magatzem de confiança o cap validació de servidor, així que el seu èxit no diu res sobre la comprovació que ha fallat aquí. Manteniu una prova negativa deliberada, com un certificat amb el nom equivocat o una cadena no confiable, que falli com s’espera. Si aquesta prova ara passa, heu tret una comprovació en lloc d’arreglar un certificat. Anoteu quina identitat ha fallat, perquè la propera persona no comenci una altra vegada amb el certificat de la passarel·la.