Nastavení certifikátu IKEv2 na iPhonu: ruční versus spravovaná registrace

Volba RSA proto, že nástroj certifikátů brány ji používá jako výchozí, je rozhodnutí učiněné dřív než otázka, na které záleží: jak budou tyto iPhony zaregistrovány? Připojení zadané uživatelem a konfigurační profil dodaný správou nabízejí různá nastavení a některé volby certifikátu existují jen na jedné z těchto cest. Nastavte pořadí správně a plán certifikátu se zkrátí; uděláte chybu a vydáte přihlašovací údaj, který telefon nepoužije. Berte níže uvedené kroky jako posloupnost, protože každý zužuje volby pro ten následující.

První krok: zvolte cestu registrace

Ruční nastavení znamená, že uživatel zadá adresu serveru, zvolí metodu ověřování a poskytne jakýkoli údaj, který rozhraní povolí. Spravovaná registrace znamená, že profil nese adresu, identifikátory a odkaz na datovou část s přihlašovacími údaji. Spravovaná cesta umí vyjádřit kombinace, které ruční obrazovka neumí, a proto musí rozhodnutí o certifikátu přijít po této volbě, ne před ní.

Obě cesty dokážou telefon ověřit. Liší se v tom, co lze nastavit a komu patří identita, proto jednu zvolte vědomě, místo abyste míchali spravovaný profil s ručním zadáváním údajů.

Druhý krok: zvolte algoritmy pro zvolenou cestu

Pro ručně nastavené iPhony doporučují poznámky strongSwan k interoperabilitě s iOS certifikát serveru RSA, protože ruční klient nemusí přijmout certifikát serveru ECDSA; tytéž poznámky řeší macOS samostatně. Čtěte to jako pokyn pro podporovanou sadu klientů, ne jako trvalý zákon o zařízeních Apple. Spravovaný profil má více prostoru: může výslovně zvolit typ certifikátu, včetně identity klienta ECDSA, když to datová část i brána podporují.

Než cokoli nasadíte, ověřte verze iOS, které skutečně podporujete. Laboratorní telefon s nejnovější verzí nepopisuje flotilu, která zahrnuje starší zařízení, a algoritmus, který funguje v laboratoři, může na nejstarším telefonu v terénu přesto selhat. Rozsah verzí berte ze správy zařízení, ne z paměti. Pokud flotila zahrnuje několik verzí, testujte nejprve tu nejstarší, protože právě tam je ruční rozhraní nejomezující.

Třetí krok: čtěte pole profilu jako oddělené věci

Několik podobně pojmenovaných klíčů popisuje různé objekty. Vzdálená adresa je hostitel, kterého telefon vytáčí. Vzdálený identifikátor je identita IKE, kterou telefon očekává od brány. Odkaz na certifikát v datové části ukazuje na přihlašovací údaj klienta a pole typu certifikátu volí typ používaný pro strojové ověřování IKEv2. Nic z toho není podpisový algoritmus CA, i když se slova překrývají.

Referenční dokumentace Apple k datové části IKEv2 uvádí RSA jako výchozí typ certifikátu s výslovnými variantami ECDSA a klíč jména vydavatele spojuje s určitými nastaveními ověřování. Tyto vztahy čtěte v referenci pro zvolenou metodu, místo abyste kopírovali jeden klíč z funkčního nasazení.

Čtvrtý krok: slaďte identitu brány s jejím certifikátem

Použijte výslovný název brány, například vpn.example.com a vložte odpovídající alternativní jméno subjektu do certifikátu serveru. Pokyny strongSwan pro Apple také očekávají rozšířené použití klíče pro ověřování serveru. Volba RSA nebo ECDSA na tom nic nemění: algoritmus neopraví neshodu jména, chybějící EKU ani neúplný řetězec.

Distribuce kořene důvěry je samostatný úkol od tvrzení identity. Telefon potřebuje řetězec certifikátů, který dokáže ověřit, a musí být nastaven tak, aby očekával jméno, které jste do certifikátu skutečně vložili.

Úspěšné připojení jiné platformy je důkaz o pravidlech ověřování této platformy, nikoli povolení uvolnit pravidla telefonu. Udržujte kontroly shodné napříč klienty, pokud nemáte zdokumentovaný důvod se lišit.

Pátý krok: oddělte identitu klienta od důvěry v CA

Klientský certifikát a jeho soukromý klíč nejsou stejný objekt jako certifikát CA, kterému telefon důvěřuje. Zabudování certifikátu CA do identity PKCS#12 jej automaticky nenainstaluje jako kořen důvěry na každém podporovaném zařízení, proto berte distribuci důvěry jako vlastní krok s vlastním ověřením.

Pokud návrh místo toho používá EAP založený na hesle, potřebuje telefon zamýšlené ověření účtu plus ověření serveru. Tato cesta neospravedlňuje rozeslání jednoho sdíleného soukromého klíče klienta celé flotile, což je jiný návrh s mnohem horším režimem selhání.

Dokončete plán s ohledem na obnovu a odvolání: kdo znovu vydá klientský údaj, jak se profil aktualizuje a jak se odřízne ztracený telefon. Zaznamenejte verzi profilu a verze zařízení, proti kterým jste ověřovali, protože právě tento záznam dělá z příští výměny certifikátu rutinní změnu.