Configuración do certificado IKEv2 no iPhone: inscrición manual ou xestionada

Escoller RSA porque a ferramenta de certificados da pasarela o usa por defecto é unha decisión tomada antes da pregunta que importa: como se inscribirán estes iPhone? Unha conexión escrita polo usuario e un perfil de configuración entregado pola xestión expoñen axustes distintos, e algunhas opcións de certificado só existen nunha desas vías. Acerte na orde e o plan do certificado vólvese curto; equivoque e emitirá unha credencial que o teléfono non usará. Trate os pasos seguintes como unha secuencia, porque cada un estreita as opcións dispoñibles para o seguinte.

Paso un: escolla a vía de inscrición

A configuración manual significa que o usuario introduce o enderezo do servidor, escolle o método de autenticación e achega calquera credencial que permita a interface. A inscrición xestionada significa que un perfil leva o enderezo, os identificadores e unha referencia a unha carga de credenciais. A vía xestionada pode expresar combinacións que a pantalla manual non pode, por iso a decisión do certificado debe chegar despois desta escolla, non antes.

Ambas as vías poden autenticar un teléfono. Diferéncianse no que se pode configurar e en quen posúe a identidade, así que escolla unha a conciencia en lugar de mesturar un perfil xestionado coa entrada manual de credenciais.

Paso dous: escolla algoritmos para a vía que escolleu

Para os iPhone configurados manualmente, as notas de interoperabilidade con iOS de strongSwan recomendan un certificado de servidor RSA, porque o cliente manual pode non aceptar un certificado de servidor ECDSA; esas mesmas notas tratan macOS por separado. Lea isto como unha guía para o conxunto de clientes admitidos, non como unha lei permanente sobre os dispositivos Apple. Un perfil xestionado ten máis marxe: pode seleccionar explicitamente un tipo de certificado, incluída unha identidade de cliente ECDSA, cando a carga e a pasarela o admiten ambas.

Valide as versións de iOS que realmente admite antes de despregar nada. Un teléfono de laboratorio coa versión máis recente non describe un parque que inclúe dispositivos máis antigos, e un algoritmo que funciona no laboratorio pode fallar igualmente no teléfono máis antigo do campo. Saque o rango de versións da xestión de dispositivos e non da memoria. Se o parque abrangue varias versións, probe primeiro a máis antiga, porque é onde a interface manual é máis restritiva.

Paso tres: lea os campos do perfil como cousas separadas

Varias claves de nome parecido describen obxectos distintos. O enderezo remoto é o host ao que chama o teléfono. O identificador remoto é a identidade IKE que espera que presente a pasarela. A referencia ao certificado da carga apunta a unha credencial de cliente, e o campo de tipo de certificado selecciona o tipo usado para a autenticación de máquina IKEv2. Ningún deles é o algoritmo de sinatura da CA, aínda que as palabras se solapen.

A referencia de carga IKEv2 de Apple enumera RSA como tipo de certificado predeterminado con variantes ECDSA explícitas, e vincula a clave de nome do emisor con axustes de autenticación concretos. Lea esas relacións na referencia do método que escolleu en lugar de copiar unha clave dun despregamento que funciona.

Paso catro: faga que a identidade da pasarela coincida co seu certificado

Use un nome de pasarela explícito, por exemplo vpn.example.com e poña un nome alternativo de suxeito coincidente no certificado do servidor. A guía de strongSwan para Apple tamén espera o uso estendido de clave para a autenticación do servidor. Escoller RSA ou ECDSA non cambia nada diso: un algoritmo non pode reparar unha discrepancia de nome, un EKU ausente nin unha cadea incompleta.

Distribuír a áncora de confianza é unha tarefa aparte de afirmar a identidade. O teléfono necesita unha cadea de certificados que poida validar, e debe configurarse para esperar o nome que realmente puxo no certificado.

Que outra plataforma se conecte con éxito é evidencia sobre as regras de validación desa plataforma, non permiso para relaxar as do teléfono. Manteña as comprobacións idénticas entre clientes salvo que teña un motivo documentado para diferencialas.

Paso cinco: separe a identidade do cliente da confianza na CA

Un certificado de cliente e a súa clave privada non son o mesmo obxecto que o certificado de CA no que confía o teléfono. Empaquetar un certificado de CA dentro dunha identidade PKCS#12 non o instala automaticamente como áncora de confianza en todos os dispositivos admitidos, así que trate a distribución de confianza como un paso propio coa súa propia verificación.

Se o deseño usa EAP baseado en contrasinal, o teléfono necesita a autenticación de conta prevista máis a validación do servidor. Esa vía non xustifica enviar unha clave privada de cliente compartida a todo o parque, que é un deseño distinto cun modo de fallo moito peor.

Remate o plan pensando na renovación e na revogación: quen reemite a credencial do cliente, como se actualiza o perfil e como se corta un teléfono perdido. Rexistre a versión do perfil e as versións de dispositivo coas que validou, porque ese rexistro é o que converte a próxima rotación de certificados nun cambio rutineiro.