Certificatul gateway-ului este în regulă: de ce autentificarea IKEv2 PEAP tot eșuează

Certificatul gateway-ului VPN este valabil, lanțul se validează, iar clientul IKEv2 refuză totuși autentificarea cu un mesaj despre un interval de valabilitate al certificatului. Primul impuls este să reemiteți certificatul gateway-ului sau să schimbați metoda EAP, și ambele sunt de obicei greșite. Încercarea de autentificare poartă două identități de server separate: certificatul gateway-ului folosit de IKE, și certificatul prezentat de ceea ce termină PEAP. Una dintre ele este în regulă, iar cealaltă este motivul pentru care clientul s-a oprit.

Două identități, o singură încercare de autentificare

Certificatul din profilul VPN aparține schimbului IKE: dovedește că gateway-ul este partenerul numit de profil, conform politicii IKE configurate. Certificatul care eșuează aici aparține unei alte conversații, sesiunea TLS pe care PEAP o deschide cu ceea ce autentifică utilizatorul, adesea un server RADIUS precum NPS și nu gateway-ul însuși. O a treia verificare, acreditările utilizatorului, are loc în interiorul acelei sesiuni. O parolă validă nu poate repara un certificat de server expirat, iar un certificat de gateway valid nu poate garanta pentru punctul final PEAP.

Această stratificare explică de ce o eroare de certificat apare într-un loc în care singurul certificat configurat era cel al gateway-ului. Explică și de ce reemiterea acelui certificat nu schimbă nimic.

Citiți linia din jurnal în raport cu etapa

Găsiți mesajul care numește motivul și datele. O reclamație despre intervalul de valabilitate lângă o eroare de subiect înseamnă că serverul a respins certificatul care i-a fost dat, nu că utilizatorul a respins autentificarea. Apoi găsiți etapa: un jurnal charon al strongSwan arată IKE_SA .* established înainte de a începe schimbul EAP, deci o eroare de certificat după acea linie aparține identității EAP, în timp ce o eroare dinaintea ei indică gateway-ul. Textul etapei din panoul de conectare al unui client Windows spune același lucru.

Verificați ceasul clientului înainte de a atinge vreun certificat. Un dispozitiv care rămâne în urmă cu ore produce aceeași eroare de valabilitate ca un certificat cu adevărat expirat. Reglarea ceasului este o corecție de cinci secunde, iar înlocuirea unui certificat care nu a fost niciodată problema este o cădere.

Aflați care punct final termină PEAP

Într-un proiect cu gateway plus RADIUS, gateway-ul transmite EAP și nu îl termină. Pluginul eap-radius al strongSwan predă schimbul serverului RADIUS, care deține sesiunea TLS a PEAP și certificatul ei. Corelați o încercare eșuată în ambele jurnale și confirmați care proces a ales de fapt un certificat pentru acea sesiune.

Pentru NPS certificatul trebuie să fie în magazinul computerului local, să poarte scopul de autentificare a serverului, să corespundă numelui așteptat de clienți și să fie lizibil pentru contul de serviciu. Cerințele de certificat Microsoft pentru NPS enumeră aceste condiții. Alte servere EAP au propriile reguli de selecție, așa că nu copiați particularitățile NPS într-o implementare FreeRADIUS sau invers. Regula care rezistă în ambele cazuri este că punctul final care termină PEAP deține certificatul pe care sunteți pe cale să îl schimbați.

Înlocuiți certificatul acolo unde se termină EAP

Reînnoiți sau înlocuiți certificatul pe punctul final care termină PEAP, prin procesul acceptat, păstrând scopul de autentificare a serverului și numele așteptat. Instalați lanțul complet acolo unde serviciul îl caută și acordați serviciului acces la cheia privată. Reporniți sau reconectați serviciul, pentru că multe servicii păstrează certificatul vechi în memorie și continuă să îl prezinte. Un fișier copiat pe mașină nu dovedește nimic despre certificatul pe care serviciul îl prezintă de fapt.

Confirmați schimbarea corelând următoarea încercare cu jurnalul propriu al serviciului, sau inspectând certificatul pe care sesiunea l-a prezentat. Dacă acel jurnal încă arată amprenta veche, repornirea nu a prins.

Nu presupuneți că fișierul cel mai nou dintr-un director este cel folosit. O copie cu numele corect și permisiunile greșite nu schimbă nimic. Judecați schimbarea după identitatea prezentată, nu după marca de timp a unui fișier.

Ce să nu faceți

Nu dezactivați validarea PEAP și nu forțați o metodă internă mai slabă pentru a trece de eroare. Asta schimbă politica și elimină proprietatea de autentificare a serverului care a prins certificatul expirat de la bun început. Ați schimba o verificare care funcționează pe o conexiune care funcționează, iar următorul certificat expirat ar veni fără nimic care să îl anunțe.

Nu luați o conexiune reușită a altui sistem de operare drept dovadă că certificatul este acceptabil. Acel client poate folosi altă metodă EAP, alt depozit de încredere sau nicio validare a serverului, așa că succesul lui nu spune nimic despre verificarea care a eșuat aici. Păstrați un test negativ deliberat, cum ar fi un certificat cu numele greșit sau un lanț neîncrezut, care eșuează așa cum se așteaptă. Dacă testul trece acum, ați eliminat o verificare în loc să reparați un certificat. Notați care identitate a eșuat, ca următoarea persoană să nu înceapă din nou cu certificatul gateway-ului.