Certificatul IKEv2 pe iPhone: înregistrare manuală sau gestionată

A alege RSA doar pentru că instrumentul de certificate al gateway-ului îl folosește implicit este o decizie luată înainte de întrebarea care contează: cum vor fi înregistrate aceste iPhone-uri? O conexiune tastată de utilizator și un profil de configurare livrat de management expun setări diferite, iar unele opțiuni de certificat există doar pe una dintre aceste căi. Puneți ordinea corect și planul certificatului devine scurt; greșiți și veți emite o acreditare pe care telefonul nu o va folosi. Tratați pașii de mai jos ca pe o secvență, pentru că fiecare restrânge opțiunile disponibile pentru următorul.

Primul pas: alegeți calea de înregistrare

Configurarea manuală înseamnă că utilizatorul introduce adresa serverului, alege metoda de autentificare și furnizează orice acreditare pe care interfața o permite. Înregistrarea gestionată înseamnă că un profil poartă adresa, identificatorii și o referință la un payload de acreditări. Calea gestionată poate exprima combinații pe care ecranul manual nu le poate, de aceea decizia privind certificatul trebuie să vină după această alegere, nu înainte.

Ambele căi pot autentifica un telefon. Ele diferă în ce puteți configura și în cine deține identitatea, așa că alegeți una în mod deliberat în loc să amestecați un profil gestionat cu introducerea manuală a acreditărilor.

Al doilea pas: alegeți algoritmii pentru calea aleasă

Pentru iPhone-urile configurate manual, notele de interoperabilitate iOS ale strongSwan recomandă un certificat de server RSA, pentru că clientul manual poate să nu accepte un certificat de server ECDSA; aceleași note tratează macOS separat. Citiți asta ca îndrumare pentru setul de clienți acceptat, nu ca o lege permanentă despre dispozitivele Apple. Un profil gestionat are mai mult spațiu: poate selecta explicit un tip de certificat, inclusiv o identitate de client ECDSA, când payload-ul și gateway-ul îl acceptă amândouă.

Validați versiunile iOS pe care le acceptați cu adevărat înainte de a implementa orice. Un telefon de laborator pe cea mai nouă versiune nu descrie un parc care include dispozitive mai vechi, iar un algoritm care funcționează în laborator poate eșua totuși pe cel mai vechi telefon din teren. Luați intervalul de versiuni din managementul dispozitivelor, nu din memorie. Dacă parcul cuprinde mai multe versiuni, testați mai întâi cea mai veche, pentru că acolo interfața manuală este cea mai restrictivă.

Al treilea pas: citiți câmpurile profilului ca lucruri separate

Mai multe chei cu nume asemănător descriu obiecte diferite. Adresa la distanță este gazda pe care telefonul o apelează. Identificatorul la distanță este identitatea IKE pe care telefonul se așteaptă ca gateway-ul să o prezinte. Referința la certificat din payload indică o acreditare de client, iar câmpul de tip de certificat selectează tipul folosit pentru autentificarea de mașină IKEv2. Niciuna dintre ele nu este algoritmul de semnătură al CA, deși cuvintele se suprapun.

Referința de payload IKEv2 a Apple listează RSA ca tip de certificat implicit, cu variante ECDSA explicite, și leagă cheia numelui emitentului de anumite setări de autentificare. Citiți acele relații în referința pentru metoda aleasă, în loc să copiați o cheie dintr-o implementare care funcționează.

Al patrulea pas: potriviți identitatea gateway-ului cu certificatul său

Folosiți un nume explicit de gateway, de exemplu vpn.example.com și puneți un nume alternativ de subiect care se potrivește în certificatul serverului. Ghidul Apple al strongSwan așteaptă și utilizarea extinsă a cheii pentru autentificarea serverului. Alegerea RSA sau ECDSA nu schimbă nimic din asta: un algoritm nu poate repara o nepotrivire de nume, un EKU lipsă sau un lanț incomplet.

Distribuirea ancorei de încredere este o sarcină separată de afirmarea identității. Telefonul are nevoie de un lanț de certificate pe care îl poate valida și trebuie configurat să aștepte numele pe care l-ați pus efectiv în certificat.

Faptul că o altă platformă se conectează cu succes este o dovadă despre regulile de validare ale acelei platforme, nu o permisiune de a relaxa regulile telefonului. Păstrați verificările identice între clienți, cu excepția cazului în care aveți un motiv documentat să diferiți.

Al cincilea pas: separați identitatea clientului de încrederea în CA

Un certificat de client și cheia sa privată nu sunt același obiect ca certificatul CA în care telefonul are încredere. Împachetarea unui certificat CA într-o identitate PKCS#12 nu îl instalează automat ca ancoră de încredere pe fiecare dispozitiv acceptat, așa că tratați distribuirea încrederii ca pe un pas separat, cu verificarea sa proprie.

Dacă designul folosește EAP bazat pe parolă, telefonul are nevoie de autentificarea contului prevăzută plus validarea serverului. Acea cale nu justifică trimiterea unei singure chei private de client partajate către întregul parc, ceea ce este un design diferit, cu un mod de eșec mult mai grav.

Încheiați planul gândindu-vă la reînnoire și revocare: cine reemite acreditarea clientului, cum se actualizează profilul și cum este deconectat un telefon pierdut. Înregistrați versiunea profilului și versiunile de dispozitiv față de care ați validat, pentru că acea înregistrare este cea care face următoarea schimbare de certificat o modificare de rutină.