IKEv2 sertifikaat ja SAN: miks identiteedikontroll ebaõnnestub

Teie sertifikaadi ahel viib usaldusväärse CA-ni, kuupäevad on korras, ja partner keeldub ikkagi faasi 1 lõpetamast identiteediveaga. Kättesaadavus ja kehtiv allkiri on vaid pool sellest, mida IKEv2 klient kontrollib. Teine pool on see, kas oodatav identiteet esineb sertifikaadis õiges väljas, ja selle ootuse määrab profiil, mitte sertifikaadi failinimi.

Sümptom on alati sama kujuga

Ühenduse profiil muudetakse hostinimest IP-aadressiks või uuendatakse sertifikaadist, mis kandis DNS-nime, selliseks, mis kannab ainult aadresse, ja tunnel lõpetab läbirääkimise. Võrguteel ei muutunud midagi. Klient jõuab partnerini, saab sertifikaadi ja lükkab partneri identiteedi tagasi, sest identifikaator, mida tal paluti oodata, ei ole esindatud väljal, mille ta vastu võtab. Uuendused on tavaline vallandaja, kuna asendussertifikaat pärineb sageli teisest mallist kui see, mille see asendab.

Seejärel logivad mõlemad pooled midagi kasutut, mistõttu teatatakse tõrkest tavaliselt sertifikaadiprobleemina. Kliendi logi võib nimetada identiteeti, mida ta soovis, ja see nimi on vihje, mida vajate, mitte aegumiskuupäev.

Sobitage identifikaatori tüüp, mitte ainult väärtus

dNSName SAN ja iPAddress SAN on erinevad väljad erinevate sobivusreeglitega, seega sertifikaat, mis kannab 203.0.113.10 DNS-stringina, ei rahulda klienti, kes ootab IP-identiteeti. Kaasaegsed valideerijad eiravad üldnime suures osas, nii et sertifikaadi üksikasjades olev sõbralik silt ei tõesta midagi selle kohta, mis sobib. Kui tõrkeotsingu käigus asendati hostinimi aadressiga, eeldage, et oodatav identiteet liikus sellega kaasa, kuni olete kontrollinud. Võrrelge profiili stringi SAN-i stringiga märk märgi haaval, sest lõpus olev punkt või üleliigne tühik on piisav.

Metamärgid on mugavus ainult DNS-i jaoks ja järgivad oma sobivusreegleid, mis on veel üks põhjus, miks IP-põhine profiil ei tohiks neile kunagi lootma jääda.

Leidke, kuhu iga klient ootuse salvestab

StrongSwanis pärineb sertifikaadiga võrreldav väärtus partneri identiteedi seadest: rightid klassikalises konfiguratsioonis või kaugühenduse jaotise id swanctlis. Apple IKEv2 koostalitlusvõime dokumentatsioon on siin kasulik, sest see selgitab identiteedi tavasid, mida profiilijuhitav klient kasutab, ja need tavad selgitavad ühte mittevastavuste klassi, mis võrgus juhuslikuna näib.

Apple'i konfiguratsiooniprofiilid kannavad kaugidentifikaatori välja, ja seal olev väärtus on see, mida klient kontrollib, mitte serveri aadress ühenduse seadetes. Windowsi ja seadmete klientidel on kõigil oma väli oma vaikeväärtusega, ja vaikeväärtus järgib sageli aadressi, mille te sisestasite. Kui kaks välja erinevad, võidab see, mida klient tegelikult loeb, ja see on harva see, mida te muutsite.

Parandage profiil või sertifikaat teadlikult

Uurige partneri sertifikaati heakskiidetud tööriistadega ja loetlege SAN-i kirjed nende tüüpidega, enne kui midagi muudate. See uurimine ei vaja privaatvõtit ega üleslaadimist ning lahendab küsimuse sekunditega. Kui juurutus kavatseb ühte DNS-identiteeti, peab sertifikaat seda kandma dNSName-kirjena, ja kui see kavatseb aadressi, vajab sertifikaat iPAddress-kirjet täpselt selle aadressi jaoks.

Kui sertifikaat on vale, taotlege operaatorilt parandatud sertifikaati konkreetse oodatava identifikaatoriga. Kui profiil on vale, parandage profiil ja jätke sertifikaat puutumata. Identiteedi valideerimise väljalülitamine paneb vea kaduma ja eemaldab kontrolli, et tunnel räägib partneriga, keda te kavatsesite.

Dokumenteerige oodatav identiteet kliendiplatvormi kohta, sest väärtus, mille üks klient tuletab automaatselt, võib teisel osutuda vajalikuks selgesõnaliselt esitada.

Andke uuendustaotlusele neli fakti

Kirjutage üles oodatav identifikaator ja selle tüüp, SAN-i kirjed, mis praegusel sertifikaadil tegelikult on, kontrolli tegev klient ja versioon ning vea täpne tekst. Nendest neljast realt koostatud uuendustaotlus saab esimesel korral õige sertifikaadi, mitte veel ühe sama tuttava failinimega.