IKEv2 sertifikāta SAN: kāpēc identitātes pārbaude neizdodas

Jūsu sertifikāts ir saistīts ar uzticamu CA, datumi ir kārtībā, un partneris joprojām atsakās pabeigt 1. fāzi ar identitātes kļūdu. Sasniedzamība un derīgs paraksts ir tikai puse no tā, ko pārbauda IKEv2 klients. Otra puse ir tas, vai gaidītā identitāte sertifikātā parādās pareizajā laukā, un šo gaidu nosaka profils, nevis sertifikāta faila nosaukums.

Simptoms vienmēr ir vienā formā

Savienojuma profils tiek mainīts no resursdatora nosaukuma uz IP adresi vai atjaunināts no sertifikāta, kuram bija DNS nosaukums, uz tādu, kuram ir tikai adreses, untunelis pārstāj slēgt vienošanos. Tīkla ceļā nekas nemainījās. Klients sasniedz partneri, saņem sertifikātu un noraida partnera identitāti, jo identifikators, kuru tam lika gaidīt, nav attēlots laukā, kuru tas pieņem. Atjauninājumi ir ierastais iemesls, jo aizvietotājsertifikāts bieži nāk no citas veidnes nekā tas, kuru tas aizstāj.

Pēc tam abas puses reģistrē kaut ko neizmantojamu, tāpēc kļūme parasti tiek ziņota kā sertifikāta problēma. Klienta žurnālā var būt nosaukta vēlamā identitāte, un šis nosaukums ir pavediens, kas jums vajadzīgs, nevis derīguma termiņš.

Saskaņojiet identifikatora tipu, ne tikai vērtību

dNSName SAN un iPAddress SAN ir dažādi lauki ar dažādiem atbilstības noteikumiem, tāpēc sertifikāts, kurā 203.0.113.10 ir DNS virkne, neapmierina klientu, kas gaida IP identitāti. Mūsdienu validatori lielākoties ignorē vispārējo nosaukumu, tāpēc draudzīgā etiķete sertifikāta informācijā neko nepierāda par to, kas atbildīs. Ja problēmu novēršanas laikā resursdatora nosaukums tika aizstāts ar adresi, pieņemiet, ka gaidītā identitāte pārvietojās kopā ar to, līdz neesat pārbaudījis. Salīdziniet profila virkni ar SAN virkni burtu pa burtam, jo beigu punkts vai lieka atstarpe ir pietiekama.

Aizstājējzīmes ir tikai DNS ērtība un ievēro savus atbilstības noteikumus, kas ir vēl viens iemesls, kāpēc uz IP balstītam profilam nekad nevajadzētu paļauties uz tām.

Atrodiet, kur katrs klients glabā gaidu

strongSwan gadījumā vērtība, kas tiek salīdzināta ar sertifikātu, nāk no partnera identitātes iestatījuma: rightid klasiskajā konfigurācijā, vai id attālā savienojuma sadaļas id swanctl. Tā dokumentācija par Apple IKEv2 savietojamību šeit ir noderīga, jo izklāsta identitātes konvencijas, ko izmanto profilu vadīts klients, un šīs konvencijas izskaidro neatbilstību klasi, kas tīklā šķiet nejauša.

Apple konfigurācijas profilos ir attālā identifikatora lauks, un tieši tur esošo vērtību klients pārbauda, nevis servera adresi savienojuma iestatījumos. Windows un ierīču klientiem katram ir savs lauks ar savu noklusējumu, un noklusējums bieži seko jūsu ievadītajai adresei. Kad divi lauki nesaskan, uzvar tas, ko klients faktiski lasa, un tas reti ir tas, ko jūs rediģējāt.

Labojiet profilu vai sertifikātu apzināti

Pirms kaut ko mainīt, pārbaudiet partnera sertifikātu ar apstiprinātiem rīkiem un uzskaitiet SAN ierakstus ar to tipiem. Šai pārbaudei nav vajadzīga privātā atslēga un augšupielāde, un tā jautājumu atrisina dažu sekunžu laikā. Ja izvietojums paredz vienu DNS identitāti, sertifikātam tā jāietver kā dNSName ieraksts, un, ja izvietojums paredz adresi, sertifikātam vajag iPAddress ierakstu tieši šai adresei.

Kad sertifikāts ir nepareizs, lūdziet operatoram labotu ar konkrēto gaidīto identifikatoru. Kad profils ir nepareizs, labojiet profilu un atstājiet sertifikātu mierā. Identitātes validācijas izslēgšana likvidē kļūdu un noņem pārbaudi, ka tunelis runā ar paredzēto partneri.

Dokumentējiet gaidīto identitāti katrai klienta platformai, jo vērtība, ko viens klients iegūst automātiski, citā var būt jānorāda skaidri.

Sniedziet atjaunināšanas pieprasījumam četrus faktus

Pierakstiet gaidīto identifikatoru un tā tipu, SAN ierakstus, kas pašreizējam sertifikātam patiešām ir, klientu un versiju, kas veic pārbaudi, un precīzu kļūdas tekstu. No šīm četrām rindām veidots atjaunināšanas pieprasījums pirmajā reizē iegūst pareizo sertifikātu, nevis vēl vienu ar to pašu pazīstamo faila nosaukumu.