Toegangspoort-sertifikaat is reg: waarom IKEv2 PEAP-aanmelding steeds misluk

Jou VPN-toegangspoort se sertifikaat is geldig, die ketting valideer, en die IKEv2-kliënt weier steeds die aanmelding met ’n boodskap oor ’n geldigheidsperiode van ’n sertifikaat. Die instink is om die toegangspoort-sertifikaat te heruitreik of die EAP-metode te verander, en albei is gewoonlik verkeerd. Die aanmeldpoging dra twee afsonderlike bediener-identiteite: die toegangspoort-sertifikaat wat deur IKE gebruik word, en die sertifikaat wat aangebied word deur wat ook al PEAP termineer. Een van hulle is reg, en die ander een is die rede waarom die kliënt opgehou het.

Twee identiteite, een aanmeldpoging

Die sertifikaat in die VPN-profiel behoort aan die IKE-uitruiling: dit bewys dat die toegangspoort die eweknie is wat die profiel noem, onder die gekonfigureerde IKE-beleid. Die sertifikaat wat hier misluk, behoort aan ’n ander gesprek, die TLS-sessie wat PEAP oopmaak met wat ook al die gebruiker verifieer, wat dikwels ’n RADIUS-bediener soos NPS is eerder as die toegangspoort self. ’n Derde kontrole, die gebruiker se geloofsbrief, gebeur binne daardie sessie. ’n Geldige wagwoord kan nie ’n vervalste bediener-sertifikaat herstel nie, en ’n geldige toegangspoort-sertifikaat kan nie vir die PEAP-eindpunt borg staan nie.

Hierdie gelaagdheid verduidelik waarom ’n sertifikaatfout op ’n plek verskyn waar die enigste sertifikaat wat iemand gekonfigureer het, die toegangspoort s’n was. Dit verduidelik ook waarom die heruitreiking van daardie sertifikaat niks verander nie.

Lees die logreël teen die fase

Vind die boodskap wat die rede en die datums noem. ’n Klag oor die geldigheidsperiode langs ’n onderwerp-fout beteken die bediener het die sertifikaat wat dit gekry het, verwerp, nie dat die gebruiker die aanmelding verwerp het nie. Vind dan die fase: ’n strongSwan charon-log wys IKE_SA .* established voordat die EAP-uitruiling begin, so ’n sertifikaatfout ná daardie reël behoort aan die EAP-identiteit, terwyl ’n fout voor dit na die toegangspoort wys. Die fase-teks in ’n Windows-kliënt se verbindingspaneel sê dieselfde ding.

Kontroleer die kliënt se klok voordat jy enige sertifikaat aanraak. ’n Toestel wat ure verkeerd is, lewer dieselfde geldigheidsfout as ’n werklik vervalste sertifikaat. Om die klok terug te stel is ’n vyf-sekonde-regstelling, en om ’n sertifikaat te vervang wat nooit die probleem was nie, is ’n onderbreking.

Vind watter eindpunt PEAP termineer

In ’n toegangspoort-plus-RADIUS-ontwerp stuur die toegangspoort EAP aan en termineer dit nie. strongSwan se eap-radius-inprop gee die uitruiling aan die RADIUS-bediener oor, wat die PEAP TLS-sessie en sy sertifikaat besit. Korreleer een mislukte poging oor albei logs en bevestig watter proses werklik ’n sertifikaat vir daardie sessie gekies het.

Vir NPS moet die sertifikaat in die plaaslike rekenaar se stoor sit, die bediener-verifikasie-doel dra, ooreenstem met die naam wat kliënte verwag, en vir die diensrekening leesbaar wees. Die Microsoft se sertifikaatvereistes vir NPS lys daardie voorwaardes. Ander EAP-bediener het hul eie keuringsreëls, so moenie NPS-besonderhede in ’n FreeRADIUS-ontplooiing kopieer of omgekeerd nie. Die reël wat albei opstellings oorleef, is dat die eindpunt wat PEAP termineer, die sertifikaat besit wat jy op die punt staan om te verander.

Vervang die sertifikaat waar EAP termineer

Hernu of vervang die sertifikaat op die eindpunt wat PEAP termineer, deur die ondersteunde proses, en behou die bediener-verifikasie-doel en die verwagte naam. Installeer die volle ketting waar die diens dit soek en gee die diens toegang tot die privaat sleutel. Herbegin of herbind die diens, want baie dienste hou die ou sertifikaat in die geheue en hou aan om dit voor te lê. ’n Lêer wat na die masjien gekopieer is, bewys niks oor watter sertifikaat die diens werklik voorlê nie.

Bevestig die verandering deur die volgende poging met die diens se eie log te korreleer, of deur die sertifikaat te inspekteer wat die sessie voorgelê het. As daardie log steeds die ou duimafdruk wys, het die herbegin nie geslaag nie.

Moenie aanvaar dat die nuutste lêer in ’n gids die een is wat gebruik word nie. ’n Kopie met die regte naam en die verkeerde regte verander niks. Beoordeel die verandering aan die hand van die voorgele identiteit, nie aan die hand van ’n lêertydstempel nie.

Wat nie te doen nie

Moet nie PEAP-validasie deaktiveer of ’n swakker binne-metode afdwing om verby die fout te kom nie. Dit verander die beleid en verwyder die bediener-verifikasie-eienskap wat die vervalste sertifikaat in die eerste plek gevang het. Jy sou ’n werkende kontrole vir ’n werkende verbinding verruil, en die volgende vervalste sertifikaat sou opdaag met niks om dit aan te kondig nie.

Moenie ’n ander bedryfstelsel se suksesvolle verbinding as bewys beskou dat die sertifikaat aanvaarbaar is nie. Daardie kliënt mag ’n ander EAP-metode gebruik, ’n ander truststore of glad geen bediener-validasie nie, so sy sukses sê niks oor die kontrole wat hier gefaal het nie. Hou een doelbewuste negatiewe toets, soos ’n sertifikaat met die verkeerde naam of ’n onvertroude ketting, wat soos verwag faal. As daardie toets nou slaag, het jy ’n kontrole verwyder eerder as om ’n sertifikaat reg te maak. Skryf neer watter identiteit gefaal het, sodat die volgende persoon nie weer met die toegangspoort-sertifikaat begin nie.