Certifikát IKEv2 na iPhone: ručná alebo spravovaná registrácia

Vybrať RSA len preto, že nástroj certifikátov brány ho používa predvolene, je rozhodnutie prijaté pred otázkou, na ktorej záleží: ako budú tieto iPhone zaregistrované? Pripojenie zadané používateľom a konfiguračný profil dodaný správou ponúkajú rôzne nastavenia a niektoré voľby certifikátu existujú len na jednej z týchto ciest. Nastavte poradie správne a plán certifikátu sa skráti; pomýlite sa a vydáte prihlasovací údaj, ktorý telefón nepoužije. Berte nižšie uvedené kroky ako postupnosť, pretože každý zužuje voľby dostupné pre nasledujúci.

Prvý krok: vyberte cestu registrácie

Ručné nastavenie znamená, že používateľ zadá adresu servera, vyberie metódu overovania a poskytne akýkoľvek údaj, ktorý rozhranie povolí. Spravovaná registrácia znamená, že profil nesie adresu, identifikátory a odkaz na dátovú časť s prihlasovacími údajmi. Spravovaná cesta dokáže vyjadriť kombinácie, ktoré ručná obrazovka nedokáže, preto rozhodnutie o certifikáte musí prísť po tejto voľbe, nie pred ňou.

Obe cesty dokážu overiť telefón. Líšia sa v tom, čo možno nastaviť, a v tom, komu patrí identita, preto jednu vyberte vedome, namiesto miešania spravovaného profilu s ručným zadávaním údajov.

Druhý krok: vyberte algoritmy pre zvolenú cestu

Pre ručne nastavené iPhone odporúčajú poznámky strongSwan o interoperabilite s iOS certifikát servera RSA, pretože ručný klient nemusí prijať certifikát servera ECDSA; tie isté poznámky riešia macOS samostatne. Čítajte to ako usmernenie pre podporovanú sadu klientov, nie ako trvalý zákon o zariadeniach Apple. Spravovaný profil má viac priestoru: môže výslovne zvoliť typ certifikátu vrátane identity klienta ECDSA, keď to dátová časť aj brána podporujú.

Pred nasadením čohokoľvek overte verzie iOS, ktoré skutočne podporujete. Laboratórny telefón s najnovšou verziou neopisuje flotilu, ktorá zahŕňa staršie zariadenia, a algoritmus, ktorý funguje v laboratóriu, môže na najstaršom telefóne v teréne napriek tomu zlyhať. Rozsah verzií berte zo správy zariadení, nie z pamäte. Ak flotila zahŕňa niekoľko verzií, testujte najprv tú najstaršiu, pretože práve tam je ručné rozhranie najobmedzujúcejšie.

Tretí krok: čítajte polia profilu ako oddelené veci

Niekoľko podobne pomenovaných kľúčov opisuje rôzne objekty. Vzdialená adresa je hostiteľ, ktorého telefón vytáča. Vzdialený identifikátor je identita IKE, ktorú telefón očakáva od brány. Odkaz na certifikát v dátovej časti ukazuje na prihlasovací údaj klienta a pole typu certifikátu volí typ používaný na strojové overovanie IKEv2. Nič z toho nie je podpisový algoritmus CA, aj keď sa slová prekrývajú.

Referenčná dokumentácia Apple k dátovej časti IKEv2 uvádza RSA ako predvolený typ certifikátu s výslovnými variantmi ECDSA a kľúč mena vydavateľa spája s určitými nastaveniami overovania. Tieto vzťahy čítajte v referencii pre zvolenú metódu, namiesto kopírovania jedného kľúča z fungujúceho nasadenia.

Štvrtý krok: zosúlaďte identitu brány s jej certifikátom

Použite výslovný názov brány, napríklad vpn.example.com a vložte zodpovedajúce alternatívne meno subjektu do certifikátu servera. Usmernenie strongSwan pre Apple očakáva aj rozšírené použitie kľúča na overovanie servera. Voľba RSA alebo ECDSA na tom nič nemení: algoritmus neopraví nezhodu mien, chýbajúci EKU ani neúplnú reťaz.

Distribúcia koreňa dôvery je samostatná úloha od tvrdenia identity. Telefón potrebuje reťaz certifikátov, ktorý dokáže overiť, a musí byť nastavený tak, aby očakával meno, ktoré ste do certifikátu skutočne vložili.

Úspešné pripojenie inej platformy je dôkazom o pravidlách overovania tejto platformy, nie povolením uvoľniť pravidlá telefónu. Udržujte kontroly rovnaké naprieč klientmi, ak nemáte zdokumentovaný dôvod na odlišnosť.

Piaty krok: oddeľte identitu klienta od dôvery v CA

Klientský certifikát a jeho súkromný kľúč nie sú ten istý objekt ako certifikát CA, ktorému telefón dôveruje. Zabalenie certifikátu CA do identity PKCS#12 ho automaticky nenainštaluje ako koreň dôvery na každom podporovanom zariadení, preto berte distribúciu dôvery ako vlastný krok s vlastným overením.

Ak návrh namiesto toho používa EAP založený na hesle, telefón potrebuje zamýšľané overenie účtu plus overenie servera. Táto cesta neospravedlňuje odoslanie jedného zdieľaného súkromného kľúča klienta celej flotile, čo je iný návrh s omnoho horším režimom zlyhania.

Dokončite plán s ohľadom na obnovu a odvolanie: kto znovu vydá klientsky údaj, ako sa profil aktualizuje a ako sa odreže stratený telefón. Zaznamenajte verziu profilu a verzie zariadení, voči ktorým ste overovali, pretože práve tento záznam robí z ďalšej výmeny certifikátu rutinnú zmenu.