Lüüsi sertifikaat on korras: miks IKEv2 PEAP sisselogimine siiski ebaõnnestub

Teie VPN-lüüsi sertifikaat on kehtiv, ahel valideerub ja IKEv2 klient keeldub siiski sisselogimisest sõnumiga sertifikaadi kehtivusvahemiku kohta. Esimene impulss on lüüsi sertifikaat uuesti välja anda või EAP-meetodit vahetada, ja mõlemad on tavaliselt vale. Sisselogimiskatse kannab kaht eraldiseisvat serveri identiteeti: lüüsi sertifikaat, mida IKE kasutab, ja sertifikaat, mille esitab see, mis PEAP-i lõpetab. Üks neist on korras ja teine on põhjus, miks klient seiskus.

Kaks identiteeti, üks sisselogimiskatse

VPN-profiilis olev sertifikaat kuulub IKE vahetusele: see tõestab, et lüüs on see osapool, kelle profiil nimetab, vastavalt seadistatud IKE-poliitikale. Sertifikaat, mis siin ebaõnnestub, kuulub teisele vestlusele, TLS-sessioonile, mille PEAP avab sellega, kes kasutajat autendib, sageli RADIUS-server nagu NPS, mitte lüüs ise. Kolmas kontroll, kasutaja mandaat, toimub selle sessiooni sees. Kehtiv parool ei saa parandada aegunud serveri sertifikaati ja kehtiv lüüsi sertifikaat ei saa PEAP-i lõpp-punkti eest garanteerida.

See kihistus selgitab, miks sertifikaadiviga ilmub kohas, kus ainus seadistatud sertifikaat oli lüüsi oma. See selgitab ka, miks selle sertifikaadi uuesti väljaandmine ei muuda midagi.

Lugege logirida etapi suhtes

Leidke sõnum, mis nimetab põhjuse ja kuupäevad. Kehtivusvahemiku kaebus subjekti vea kõrval tähendab, et server lükkas tagasi sertifikaadi, mille ta sai, mitte et kasutaja lükkas sisselogimise tagasi. Seejärel leidke etapp: strongSwani charon-logi näitab IKE_SA .* established enne EAP vahetuse algust, seega pärast seda rida olev sertifikaadiviga kuulub EAP identiteedile, samas kui viga enne seda osutab lüüsile. Windowsi kliendi ühenduspaneeli etapi tekst ütleb sama.

Kontrollige kliendi kella enne mis tahes sertifikaadi puudutamist. Seade, mis on tunde vale, annab sama kehtivusvea nagu tõeliselt aegunud sertifikaat. Kella ümberseadistamine on viie sekundi parandus ja sertifikaadi asendamine, mis kunagi probleem ei olnud, on katkestus.

Tehke kindlaks, milline lõpp-punkt PEAP-i lõpetab

Lüüsi ja RADIUS-e lahenduses edastab lüüs EAP-i ega lõpeta seda. strongSawni eap-radius pistikmoodul annab vahetuse RADIUS-serverile, kellele kuulub PEAP TLS-sessioon ja selle sertifikaat. Korreleerige üks ebaõnnestunud katse mõlemas logis ja kinnitage, milline protsess sellele sessioonile tegelikult sertifikaadi valis.

NPS-i puhul peab sertifikaat olema kohaliku arvuti hoidlas, kandma serveri autentimise otstarvet, vastama nimele, mida kliendid ootavad, ja olema teenusekontole loetav. Microsofti sertifikaadinõuded NPS-ile loetlevad need tingimused. Teistel EAP-serveritel on oma valikureeglid, seega ärge kopeerige NPS-i eripärasid FreeRADIUS-e paigaldusse ega vastupidi. Reegel, mis kehtib mõlemal juhul, on see, et PEAP-i lõpetav lõpp-punkt omab sertifikaati, mida kavatsete muuta.

Asendage sertifikaat seal, kus EAP lõpeb

Uuendage või asendage sertifikaat lõpp-punktis, mis PEAP-i lõpetab, toetatud protseduuri kaudu, säilitades serveri autentimise otstarbe ja oodatava nime. Paigaldage täielik ahel sinna, kus teenus seda otsib, ja andke teenusele juurdepääs privaatvõtmele. Taaskäivitage või siduge teenus uuesti, sest paljud teenused hoiavad vana sertifikaati mälus ja esitavad seda edasi. Masinasse kopeeritud fail ei tõesta midagi selle kohta, millist sertifikaati teenus tegelikult esitab.

Kinnitage muudatus, korreleerides järgmise katse teenuse enda logiga või kontrollides sertifikaati, mille sessioon esitas. Kui see logi näitab endiselt vana sõrmejälge, ei võtnud taaskäivitus mõju.

Ärge eeldage, et kataloogi uusim fail on see, mida kasutatakse. Õige nime ja vale õigustega koopia ei muuda midagi. Hinnake muudatust esitatud identiteedi järgi, mitte faili ajatempli järgi.

Mida mitte teha

Ärge lülitage PEAP-i valideerimist välja ega suruge peale nõrgemat sisemist meetodit, et veast mööda saada. See muudab poliitikat ja eemaldab serveri autentimise omaduse, mis aegunud sertifikaadi üldse kinni püüdis. Te vahetaksite töötava kontrolli töötava ühenduse vastu ja järgmine aegunud sertifikaat saabuks ilma millegi poolt teada andmata.

Ärge pidage teise operatsioonisüsteemi õnnestunud ühendust tõestuseks, et sertifikaat on vastuvõetav. See klient võib kasutada teist EAP-meetodit, teist usaldushoidlat või üldse ilma serveri valideerimiseta, seega ei ütle tema edu midagi siin ebaõnnestunud kontrolli kohta. Hoidke üks meelega negatiivne test, näiteks vale nimega sertifikaat või ebausaldusväärne ahel, mis ebaõnnestub ootuspäraselt. Kui see test nüüd läbib, eemaldasite kontrolli, mitte ei parandanud sertifikaati. Kirjutage üles, milline identiteet ebaõnnestus, et järgmine inimene ei alustaks jälle lüüsi sertifikaadist.