IKEv2 certifikat i SAN: zašto provjera identiteta ne uspijeva

Vaš certifikat vodi do pouzdanog CA, datumi su ispravni, a partner ipak odbija dovršiti fazu 1 s greškom identiteta. Dostupnost i valjan potpis samo su polovina onoga što IKEv2 klijent provjerava. Druga polovina je pojavljuje li se očekivani identitet u certifikatu u pravom polju, a to očekivanje postavlja profil, ne naziv datoteke certifikata.

Simptom uvijek ima isti oblik

Profil veze mijenja se s imena hosta na IP adresu ili se obnavlja s certifikata koji nosi DNS ime na onaj koji nosi samo adrese, i tunel prestaje pregovarati. Ništa se na mrežnom putu nije promijenilo. Klijent dođe do partnera, primi certifikat i odbije identitet partnera jer identifikator koji je trebao očekivati nije predstavljen u polju koje prihvata. Obnove su uobičajeni povod, jer zamjenski certifikat često dolazi iz drugog predloška od onoga koji zamjenjuje.

Obje strane zatim zabilježe nešto beskorisno, zbog čega se kvar obično prijavi kao problem s certifikatom. Klijentski dnevnik može navesti identitet koji je želio, i to je ime trag koji tražite, a ne datum isteka.

Uparite tip identifikatora, ne samo vrijednost

dNSName SAN i iPAddress SAN različita su polja s različitim pravilima podudaranja, pa certifikat koji nosi 203.0.113.10 kao DNS niz ne zadovoljava klijenta koji očekuje IP identitet. Moderni validatori uvelike zanemaruju uobičajeno ime, pa prijateljska oznaka u detaljima certifikata ništa ne dokazuje o tome što će se podudarati. Ako je tijekom rješavanja problema ime hosta zamijenjeno adresom, pretpostavite da se očekivani identitet premjestio s njim dok ne provjerite. Usporedite niz u profilu s nizom u SAN-u znak po znak, jer je dovoljna točka na kraju ili suvišan razmak.

Zamjenski znakovi pogodnost su samo za DNS i slijede vlastita pravila podudaranja, što je još jedan razlog da se profil zasnovan na IP-u nikada ne oslanja na njih.

Nađite gdje svaki klijent čuva očekivanje

U strongSwanu vrijednost koja se uspoređuje s certifikatom dolazi iz postavke identiteta partnera: rightid u klasičnoj konfiguraciji ili id odjeljka udaljene veze u swanctl-u. Dokumentacija o interoperabilnosti s Apple IKEv2 ovdje je korisna jer izlaže konvencije identiteta koje koristi klijent vođen profilom, a te konvencije objašnjavaju klasu nesklada koji na mreži izgleda slučajno.

Appleovi profili konfiguracije nose polje udaljenog identifikatora, a vrijednost tamo je ono što klijent provjerava, a ne adresa poslužitelja u postavkama veze. Windows i klijenti uređaja imaju svaki svoje polje sa svojim zadanim vrijednostima, a zadana vrijednost često slijedi adresu koju ste upisali. Kada se dva polja razilaze, pobjeđuje ono koje klijent stvarno čita, a to je rijetko polje koje ste uredili.

Popravite profil ili certifikat namjerno

Pregledajte certifikat partnera odobrenim alatima i navedite SAN unose s njihovim tipovima prije nego što bilo što promijenite. Taj pregled ne zahtijeva privatni ključ ni prijenos i rješava pitanje u sekundama. Ako implementacija namjerava jedan DNS identitet, certifikat ga mora nositi kao dNSName unos, a ako namjerava adresu, certifikatu treba iPAddress unos za točno tu adresu.

Kada je certifikat pogrešan, zatražite ispravljeni od operatera s konkretnim očekivanim identifikatorom. Kada je profil pogrešan, popravite profil i ostavite certifikat na miru. Isključivanje provjere identiteta uklanja grešku i uklanja provjeru da tunel razgovara s partnerom kojeg ste namjeravali.

Dokumentirajte očekivani identitet po klijentskoj platformi, jer vrijednost koju jedan klijent izvodi automatski možda treba biti izričita na drugom.

Dajte zahtjevu za obnovu četiri činjenice

Zapišite očekivani identifikator i njegov tip, SAN unose koje trenutni certifikat stvarno ima, klijenta i verziju koji obavljaju provjeru te točan tekst greške. Zahtjev za obnovu sastavljen od tih četiri retka dobiva ispravan certifikat iz prvog pokušaja, umjesto još jednog s istim poznatim nazivom datoteke.