Configuració del certificat IKEv2 a l’iPhone: inscripció manual o gestionada

Triar RSA perquè l’eina de certificats de la passarel·la l’usa per defecte és una decisió presa abans de la pregunta que importa: com s’inscriuran aquests iPhone? Una connexió escrita per l’usuari i un perfil de configuració lliurat per la gestió exposen paràmetres diferents, i algunes opcions de certificat només existeixen en una d’aquestes vies. Encerta l’ordre i el pla del certificat es torna curt; equivoca’t i emetràs una credencial que el telèfon no utilitzarà. Tracta els passos següents com una seqüència, perquè cadascun estreny les opcions disponibles per al següent.

Pas u: trieu la via d’inscripció

La configuració manual vol dir que l’usuari introdueix l’adreça del servidor, tria el mètode d’autenticació i aporta qualsevol credencial que la interfície permeti. La inscripció gestionada vol dir que un perfil porta l’adreça, els identificadors i una referència a una càrrega de credencials. La via gestionada pot expressar combinacions que la pantalla manual no pot, i per això la decisió del certificat ha de venir després d’aquesta tria, no abans.

Totes dues vies poden autenticar un telèfon. Es diferencien en què podeu configurar i en qui posseeix la identitat, així que trieu-ne una de manera deliberada en lloc de barrejar un perfil gestionat amb entrada manual de credencials.

Pas dos: trieu algorismes per a la via que heu triat

Per als iPhone configurats manualment, les notes d’interoperabilitat amb iOS de strongSwan recomanen un certificat de servidor RSA, perquè el client manual pot no acceptar un certificat de servidor ECDSA; aquestes mateixes notes tracten macOS per separat. Llegeix-ho com una guia per al conjunt de clients suportats, no com una llei permanent sobre els dispositius Apple. Un perfil gestionat té més marge: pot seleccionar explícitament un tipus de certificat, inclosa una identitat de client ECDSA, quan la càrrega i la passarel·la ho suporten totes dues.

Valideu les versions d’iOS que realment suporteu abans de desplegar res. Un telèfon de laboratori amb la versió més recent no descriu un parc que inclou dispositius més antics, i un algorisme que funciona al laboratori pot fallar igualment al telèfon més antic del camp. Traieu el ventall de versions de la gestió de dispositius, no de la memòria. Si el parc abasta diverses versions, proveu primer la més antiga, perquè és on la interfície manual és més restrictiva.

Pas tres: llegiu els camps del perfil com a coses separades

Diverses claus amb noms similars descriuen objectes diferents. L’adreça remota és l’amfitrió que el telèfon marca. L’identificador remot és la identitat IKE que espera que la passarel·la presenti. La referència al certificat de la càrrega apunta a una credencial de client, i el camp de tipus de certificat selecciona el tipus usat per a l’autenticació de màquina IKEv2. Cap d’aquests no és l’algorisme de signatura de la CA, tot i que les paraules se solapen.

La referència de càrrega IKEv2 d’Apple llista RSA com a tipus de certificat per defecte amb variants ECDSA explícites, i lliga la clau del nom d’emissor a paràmetres d’autenticació concrets. Llegeix aquestes relacions a la referència del mètode que heu triat en lloc de copiar una clau d’un desplegament que funciona.

Pas quatre: feu que la identitat de la passarel·la coincideixi amb el seu certificat

Feu servir un nom de passarel·la explícit, com ara vpn.example.com i poseu un nom alternatiu de subjecte coincident al certificat del servidor. La guia de strongSwan per a Apple també espera l’ús estès de clau per a autenticació del servidor. Triar RSA o ECDSA no canvia res d’això: un algorisme no pot reparar una discrepància de nom, un EKU absent o una cadena incompleta.

Distribuir l’àncora de confiança és una tasca separada d’afirmar la identitat. El telèfon necessita una cadena de certificats que pugui validar, i s’ha de configurar per esperar el nom que realment heu posat al certificat.

Que una altra plataforma es connecti amb èxit és evidència sobre les regles de validació d’aquella plataforma, no permís per relaxar les del telèfon. Mantingueu les comprovacions idèntiques entre clients tret que tingueu un motiu documentat per diferenciar-les.

Pas cinc: separeu la identitat del client de la confiança en la CA

Un certificat de client i la seva clau privada no són el mateix objecte que el certificat de CA en què confia el telèfon. Empaquetar un certificat de CA dins d’una identitat PKCS#12 no l’instal·la automàticament com a àncora de confiança a tots els dispositius suportats, així que tracteu la distribució de confiança com un pas propi amb la seva pròpia verificació.

Si el disseny fa servir EAP basat en contrasenya, el telèfon necessita l’autenticació de compte prevista més la validació del servidor. Aquesta via no justifica enviar una clau privada de client compartida a tot el parc, que és un disseny diferent amb un mode de fallada molt pitjor.

Acabeu el pla pensant en la renovació i la revocació: qui reemet la credencial del client, com s’actualitza el perfil i com es talla un telèfon perdut. Enregistreu la versió del perfil i les versions de dispositiu amb què heu validat, perquè aquest registre és el que fa que la propera rotació de certificats sigui un canvi rutinari.