Certificato IKEv2 su iPhone: iscrizione manuale o gestita

Scegliere RSA perché lo strumento dei certificati del gateway lo usa per impostazione predefinita è una decisione presa prima della domanda che conta: come verranno iscritti questi iPhone? Una connessione digitata dall’utente e un profilo di configurazione fornito dalla gestione espongono impostazioni diverse, e alcune scelte di certificato esistono solo su uno di questi percorsi. Mettete nell’ordine giusto la sequenza e il piano del certificato diventa breve; sbagliate e rilascerete una credenziale che il telefono non userà. Trattate i passaggi seguenti come una sequenza, perché ciascuno restringe le scelte disponibili per il successivo.

Primo passaggio: scegliete il percorso di iscrizione

L’installazione manuale significa che l’utente inserisce l’indirizzo del server, sceglie il metodo di autenticazione e fornisce qualsiasi credenziale che l’interfaccia consenta. L’iscrizione gestita significa che un profilo porta l’indirizzo, gli identificatori e un riferimento a un payload di credenziali. Il percorso gestito può esprimere combinazioni che la schermata manuale non può, perciò la decisione sul certificato deve venire dopo questa scelta e non prima.

Entrambi i percorsi possono autenticare un telefono. Differiscono in ciò che si può configurare e in chi possiede l’identità, quindi sceglietene uno deliberatamente invece di mescolare un profilo gestito con l’inserimento manuale delle credenziali.

Secondo passaggio: scegliete gli algoritmi per il percorso scelto

Per gli iPhone configurati manualmente, le note di interoperabilità iOS di strongSwan raccomandano un certificato server RSA, perché il client manuale potrebbe non accettare un certificato server ECDSA; le stesse note trattano macOS separatamente. Leggete questo come una guida per l’insieme di client supportati, non come una legge permanente sui dispositivi Apple. Un profilo gestito ha più margine: può selezionare esplicitamente un tipo di certificato, inclusa un’identità client ECDSA, quando il payload e il gateway lo supportano entrambi.

Validate le versioni di iOS che supportate davvero prima di distribuire qualcosa. Un telefono da laboratorio con la versione più recente non descrive un parco che include dispositivi più vecchi, e un algoritmo che funziona in laboratorio può comunque fallire sul telefono più vecchio sul campo. Prendete l’intervallo di versioni dalla gestione dei dispositivi, non dalla memoria. Se il parco copre più versioni, provate prima la più vecchia, perché è lì che l’interfaccia manuale è più restrittiva.

Terzo passaggio: leggete i campi del profilo come cose separate

Diverse chiavi con nomi simili descrivono oggetti diversi. L’indirizzo remoto è l’host che il telefono chiama. L’identificatore remoto è l’identità IKE che si aspetta che il gateway presenti. Il riferimento al certificato del payload indica una credenziale client, e il campo del tipo di certificato seleziona il tipo usato per l’autenticazione macchina IKEv2. Nessuno di questi è l’algoritmo di firma della CA, anche se le parole si sovrappongono.

Il riferimento al payload IKEv2 di Apple elenca RSA come tipo di certificato predefinito con varianti ECDSA esplicite, e lega la chiave del nome dell’emittente a impostazioni di autenticazione particolari. Leggete quelle relazioni nel riferimento per il metodo scelto invece di copiare una chiave da una distribuzione funzionante.

Quarto passaggio: fate corrispondere l’identità del gateway al suo certificato

Usate un nome del gateway esplicito, per esempio vpn.example.com e inserite un nome alternativo del soggetto corrispondente nel certificato del server. La guida Apple di strongSwan prevede anche l’uso esteso della chiave per l’autenticazione del server. Scegliere RSA o ECDSA non cambia nulla di questo: un algoritmo non può riparare una discrepanza di nome, un EKU mancante o una catena incompleta.

Distribuire l’ancora di fiducia è un compito separato dall’affermare l’identità. Il telefono ha bisogno di una catena di certificati che possa validare, e deve essere configurato per aspettarsi il nome che avete realmente inserito nel certificato.

Che un’altra piattaforma si connetta con successo è una prova sulle regole di validazione di quella piattaforma, non un permesso per allentare quelle del telefono. Mantenete i controlli identici tra i client, a meno che non abbiate un motivo documentato per differire.

Quinto passaggio: separate l’identità del client dalla fiducia nella CA

Un certificato client e la sua chiave privata non sono lo stesso oggetto del certificato CA di cui il telefono si fida. Inserire un certificato CA dentro un’identità PKCS#12 non lo installa automaticamente come ancora di fiducia su ogni dispositivo supportato, quindi trattate la distribuzione della fiducia come un passaggio a sé con la propria verifica.

Se il progetto usa invece EAP basato su password, il telefono ha bisogno dell’autenticazione dell’account prevista più la validazione del server. Quel percorso non giustifica l’invio di un’unica chiave privata client condivisa a tutto il parco, che è un progetto diverso con una modalità di errore molto peggiore.

Concludete il piano pensando al rinnovo e alla revoca: chi reimmette la credenziale del client, come si aggiorna il profilo e come si taglia fuori un telefono smarrito. Registrate la versione del profilo e le versioni dei dispositivi con cui avete validato, perché è quel registro che rende il prossimo cambio di certificato una modifica di routine.