SAN certifikata IKEv2: zakaj preverjanje identitete ne uspe

Vaš certifikat se veriži do zaupanja vredne CA, datumi so v redu, partner pa vseeno noče dokončati faze 1 z napako identitete. Dosegljivost in veljaven podpis sta le polovica tega, kar preverja odjemalec IKEv2. Druga polovica je, ali se pričakovana identiteta pojavi v certifikatu v pravem polju, to pričakovanje pa določi profil, ne ime datoteke certifikata.

Simptom je vedno enake oblike

Profil povezave se spremeni iz imena gostitelja v naslov IP ali obnovi iz certifikata z imenom DNS v certifikat, ki vsebuje samo naslove, inpredor preneha pogajati. Na omrežni poti se ni nič spremenilo. Odjemalec doseže partnerja, prejme certifikat in zavrne partnerjevo identiteto, ker identifikator, ki naj bi ga pričakoval, ni predstavljen v polju, ki ga sprejme. Obnove so običajen sprožilec, saj nadomestni certifikat pogosto pride iz druge predloge kot tisti, ki ga nadomešča.

Obe strani nato zapišeta nekaj neuporabnega, zato je napaka običajno prijavljena kot težava s certifikatom. Dnevnik odjemalca lahko navede želeno identiteto, in to ime je namig, ki ga želite, ne datum poteka.

Ujemajte vrsto identifikatorja, ne le vrednosti

SAN dNSName in SAN iPAddress sta različni polji z različnimi pravili ujemanja, zato certifikat z 203.0.113.10 kot nizom DNS ne zadovolji odjemalca, ki pričakuje identiteto IP. Sodobni preverjevalci večinoma ignorirajo skupno ime, zato prijazna oznaka v podrobnostih certifikata ne dokazuje ničesar o tem, kaj se bo ujemalo. Če je bilo med odpravljanjem težav ime gostitelja zamenjano z naslovom, predpostavite, da se je pričakovana identiteta premaknila z njim, dokler tega niste preverili. Primerjajte niz v profilu z nizom v SAN znak za znakom, ker zadnja pika ali odvečni presledek zadostujeta.

Nadomestni znaki so le udobje DNS in sledijo svojim pravilom ujemanja, kar je še en razlog, da se profil na osnovi IP nikoli ne sme zanašati nanje.

Poiščite, kje vsak odjemalec shranjuje pričakovanje

V strongSwannu vrednost, ki se primerja s certifikatom, prihaja iz nastavitve identitete partnerja: rightid v klasični konfiguraciji ali id razdelka oddaljene povezave v swanctl. Njegova dokumentacija o interoperabilnosti z Apple IKEv2 je tu uporabna, ker pojasnjuje konvencije identitete, ki jih uporablja odjemalec, voden s profilom, in te konvencije pojasnjujejo razred neskladij, ki so na povezavi videti naključna.

Konfiguracijski profili Apple vsebujejo polje oddaljenega identifikatorja, in prav to vrednost preverja odjemalec, ne naslova strežnika v nastavitvah povezave. Odjemalci Windows in naprav imajo vsak svoje polje z lastno privzeto vrednostjo, privzeta vrednost pa pogosto sledi naslovu, ki ste ga vnesli. Kjer se dve polji ne ujemata, zmaga tisto, ki ga odjemalec dejansko bere, in to je redko tisto, ki ste ga uredili.

Popravite profil ali certifikat, namerno

Preden karkoli spremenite, preglejte partnerjev certifikat z odobrenimi orodji in naštejte vnose SAN z njihovimi vrstami. Ta pregled ne potrebuje zasebnega ključa in nalaganja ter vprašanje razreši v nekaj sekundah. Če uvedba predvideva eno identiteto DNS, jo mora certifikat vsebovati kot vnos dNSName, in če uvedba predvideva naslov, certifikat potrebuje vnos iPAddress za točno ta naslov.

Ko je certifikat napačen, pri operaterju zahtejte popravljenega s konkretnim pričakovanim identifikatorjem. Ko je profil napačen, popravite profil in pustite certifikat pri miru. Izklop preverjanja identitete odpravi napako in odstrani preverjanje, da se predor pogovarja z želenim partnerjem.

Dokumentirajte pričakovano identiteto za vsako platformo odjemalca, ker bo morda treba vrednost, ki jo en odjemalec izpelje samodejno, na drugem navesti izrecno.

Zahtevi za obnovo dajte štiri dejstva

Zapišite pričakovani identifikator in njegovo vrsto, vnose SAN, ki jih ima trenutni certifikat dejansko, odjemalca in različico, ki izvajata preverjanje, in natančno besedilo napake. Zahteva za obnovo, sestavljena iz teh štirih vrstic, prvič dobi pravi certifikat, namesto še enega z enakim znanim imenom datoteke.