IKEv2-tanúsítvány beállítása iPhone-on: kézi vagy felügyelt regisztráció

Az RSA választása azért, mert az átjáró tanúsítványeszköze alapértelmezésben ezt használja, olyan döntés, amely az igazán fontos kérdés előtt születik: hogyan regisztrálják ezeket az iPhone-okat? A felhasználó által begépelt kapcsolat és a felügyelet által kiosztott konfigurációs profil eltérő beállításokat kínál, és egyes tanúsítványválasztások csak az egyik útvonalon léteznek. Ha jó a sorrend, a tanúsítványterv rövid lesz; ha rossz, olyan hitelesítő adatot ad ki, amelyet a telefon nem fog használni. Tekintse az alábbi lépéseket sorozatnak, mert mindegyik szűkíti a következő számára elérhető választásokat.

Első lépés: válassza ki a regisztrációs útvonalat

A kézi beállítás azt jelenti, hogy a felhasználó beírja a kiszolgáló címét, kiválasztja a hitelesítési módszert, és megadja azokat a hitelesítő adatokat, amelyeket a felület engedélyez. A felügyelt regisztráció azt jelenti, hogy egy profil hordozza a címet, az azonosítókat és egy hivatkozást egy hitelesítőadat-terhelésre. A felügyelt útvonal olyan kombinációkat tud kifejezni, amelyekre a kézi képernyő nem képes, ezért a tanúsítványról szóló döntésnek e választás után kell jönnie, nem előtte.

Mindkét útvonal képes hitelesíteni egy telefont. Abban különböznek, hogy mit lehet beállítani, és hogy ki birtokolja az identitást, ezért tudatosan válasszon egyet, ahelyett hogy a felügyelt profilt kézi hitelesítőadat-beírással keverné.

Második lépés: válassza ki az algoritmusokat a választott útvonalhoz

A kézzel beállított iPhone-okhoz a strongSwan iOS-interoperabilitási jegyzetei RSA kiszolgálótanúsítványt javasolnak, mert a kézi ügyfél esetleg nem fogad el ECDSA kiszolgálótanúsítványt; ugyanezek a jegyzetek a macOS-t külön kezelik. Ezt a támogatott ügyfélkészletre vonatkozó útmutatásként olvassa, nem az Apple-eszközökre vonatkozó állandó törvényként. A felügyelt profilnak több tere van: kifejezetten kiválaszthatja a tanúsítványtípust, beleértve az ECDSA ügyfél-identitást is, ha a terhelés és az átjáró is támogatja.

Ellenőrizze az általa ténylegesen támogatott iOS-verziókat, mielőtt bármit kivezet. Egy laboratóriumi telefon a legújabb kiadáson nem ír le olyan flottát, amely régebbi eszközöket is tartalmaz, és egy laboratóriumban működő algoritmus a terepen lévő legrégebbi telefonon még mindig meghiúsulhat. A verziótartományt az eszközfelügyeletből vegye, ne a memóriájából. Ha a flotta több kiadást ölel fel, először a legrégebbit tesztelje, mert ott a legkorlátozóbb a kézi felület.

Harmadik lépés: olvassa a profil mezőit külön dolgokként

Több hasonló nevű kulcs különböző objektumokat ír le. A távoli cím az a gazdagép, amelyet a telefon tárcsáz. A távoli azonosító az az IKE-identitás, amelyet a telefon az átjárótól elvár. A terhelés tanúsítványhivatkozása ügyfél-hitelesítő adatra mutat, a tanúsítványtípus mező pedig az IKEv2 gépi hitelesítéshez használt típust választja ki. Ezek egyike sem a CA aláírási algoritmusa, bár a szavak átfedik egymást.

Az Apple IKEv2-terhelési referenciája az RSA-t alapértelmezett tanúsítványtípusként listázza kifejezett ECDSA-változatokkal, és a kibocsátónév kulcsát meghatározott hitelesítési beállításokhoz köti. Ezeket az összefüggéseket a választott módszer referenciájában olvassa, ahelyett hogy egy kulcsot átmásolna egy működő telepítésből.

Negyedik lépés: igazítsa az átjáró identitását a tanúsítványához

Használjon kifejezett átjárónevet, például vpn.example.com és tegyen egy megfelelő alternatív tárgynevet a kiszolgálótanúsítványba. A strongSwan Apple-útmutatója a kiszolgálóhitelesítéshez használt kiterjesztett kulcshasználatot is elvárja. Az RSA vagy ECDSA választása ezen semmit nem változtat: egy algoritmus nem tud névegyezést, hiányzó EKU-t vagy hiányos láncot helyreállítani.

A bizalmi horgony terjesztése külön feladat az identitás kinyilvánításától. A telefonnak olyan tanúsítványláncra van szüksége, amelyet ellenőrizni tud, és úgy kell beállítani, hogy azt a nevet várja, amelyet valóban a tanúsítványba tett.

Az, hogy egy másik platform sikeresen csatlakozik, az adott platform ellenőrzési szabályairól szóló bizonyíték, nem engedély a telefon szabályainak lazítására. Tartsa a vizsgálatokat azonosnak az ügyfelek között, hacsak nincs dokumentált oka az eltérésre.

Ötödik lépés: válassza külön az ügyfél identitását a CA-bizalalomtól

Az ügyféltanúsítvány és a privát kulcsa nem ugyanaz az objektum, mint a CA-tanúsítvány, amelyben a telefon megbízik. Egy CA-tanúsítvány PKCS#12-identitásba csomagolása nem telepíti automatikusan bizalmi horgonyként minden támogatott eszközre, ezért a bizalom terjesztését saját ellenőrzéssel rendelkező külön lépésként kezelje.

Ha a tervezés inkább jelszóalapú EAP-t használ, a telefonnak a tervezett fiókhitelesítésre és a kiszolgáló ellenőrzésére van szüksége. Ez az útvonal nem indokolja egyetlen megosztott ügyfél-privátkulcs kiosztását a teljes flottának, ami más tervezés, sokkal rosszabb hibaállapottal.

Fejezze be a tervet a megújításra és a visszavonásra gondolva: ki adja ki újra az ügyfél-hitelesítő adatot, hogyan frissül a profil, és hogyan zárják ki az elveszett telefont. Jegyezze fel a profil verzióját és azokat az eszközverziókat, amelyek ellen ellenőrzött, mert ez a feljegyzés teszi a következő tanúsítványcserét rutinszerű változtatássá.