Certificado IKEv2 no iPhone: inscrição manual ou gerenciada

Escolher RSA porque a ferramenta de certificados do gateway o usa por padrão é uma decisão tomada antes da pergunta que importa: como estes iPhone serão inscritos? Uma conexão digitada pelo usuário e um perfil de configuração entregue pela gestão expõem ajustes diferentes, e algumas escolhas de certificado existem apenas em um desses caminhos. Acerte a ordem e o plano do certificado fica curto; erre e você emitirá uma credencial que o telefone não usará. Trate os passos abaixo como uma sequência, porque cada um estreita as opções disponíveis para o seguinte.

Passo um: escolha o caminho de inscrição

A configuração manual significa que o usuário introduz o endereço do servidor, escolhe o método de autenticação e fornece qualquer credencial que a interface permita. A inscrição gerenciada significa que um perfil carrega o endereço, os identificadores e uma referência a um payload de credenciais. O caminho gerenciado pode expressar combinações que a tela manual não consegue, por isso a decisão do certificado deve vir depois desta escolha, não antes.

Ambos os caminhos podem autenticar um telefone. Eles diferem no que se pode configurar e em quem possui a identidade, então escolha um deliberadamente em vez de misturar um perfil gerenciado com entrada manual de credenciais.

Passo dois: escolha algoritmos para o caminho escolhido

Para iPhone configurados manualmente, as notas de interoperabilidade com iOS do strongSwan recomendam um certificado de servidor RSA, porque o cliente manual pode não aceitar um certificado de servidor ECDSA; as mesmas notas tratam o macOS separadamente. Leia isso como orientação para o conjunto de clientes suportados, não como uma lei permanente sobre dispositivos Apple. Um perfil gerenciado tem mais margem: pode selecionar explicitamente um tipo de certificado, incluindo uma identidade de cliente ECDSA, quando o payload e o gateway o suportam.

Valide as versões de iOS que você realmente suporta antes de implantar qualquer coisa. Um telefone de laboratório na versão mais recente não descreve um parque que inclui dispositivos mais antigos, e um algoritmo que funciona no laboratório ainda pode falhar no telefone mais antigo do campo. Obtenha o intervalo de versões da gestão de dispositivos, não da memória. Se o parque abrange várias versões, teste a mais antiga primeiro, porque é onde a interface manual é mais restritiva.

Passo três: leia os campos do perfil como coisas separadas

Várias chaves de nome semelhante descrevem objetos diferentes. O endereço remoto é o host que o telefone disca. O identificador remoto é a identidade IKE que ele espera que o gateway apresente. A referência ao certificado no payload aponta para uma credencial de cliente, e o campo de tipo de certificado seleciona o tipo usado para autenticação de máquina IKEv2. Nenhum deles é o algoritmo de assinatura da CA, embora as palavras se sobreponham.

A referência de payload IKEv2 da Apple lista RSA como tipo de certificado padrão com variantes ECDSA explícitas, e liga a chave do nome do emissor a configurações de autenticação específicas. Leia essas relações na referência do método escolhido em vez de copiar uma chave de uma implantação que funciona.

Passo quatro: faça a identidade do gateway coincidir com o certificado

Use um nome de gateway explícito, por exemplo vpn.example.com e coloque um nome alternativo de sujeito correspondente no certificado do servidor. O guia Apple do strongSwan também espera o uso estendido de chave para autenticação do servidor. Escolher RSA ou ECDSA não muda nada disso: um algoritmo não pode reparar uma divergência de nome, um EKU ausente ou uma cadeia incompleta.

Distribuir a âncora de confiança é uma tarefa separada de afirmar a identidade. O telefone precisa de uma cadeia de certificados que possa validar, e deve ser configurado para esperar o nome que você realmente colocou no certificado.

Que outra plataforma se conecte com sucesso é evidência sobre as regras de validação dessa plataforma, não permissão para relaxar as do telefone. Mantenha as verificações idênticas entre clientes, a menos que tenha um motivo documentado para diferir.

Passo cinco: separe a identidade do cliente da confiança na CA

Um certificado de cliente e sua chave privada não são o mesmo objeto que o certificado de CA em que o telefone confia. Empacotar um certificado de CA dentro de uma identidade PKCS#12 não o instala automaticamente como âncora de confiança em todos os dispositivos suportados, então trate a distribuição de confiança como um passo próprio com sua própria verificação.

Se o projeto usar EAP baseado em senha, o telefone precisa da autenticação de conta prevista mais a validação do servidor. Esse caminho não justifica enviar uma única chave privada de cliente compartilhada para todo o parque, que é um projeto diferente com um modo de falha muito pior.

Termine o plano pensando na renovação e na revogação: quem reemite a credencial do cliente, como o perfil é atualizado e como um telefone perdido é cortado. Registre a versão do perfil e as versões de dispositivo com que você validou, porque esse registro é o que torna a próxima troca de certificado uma mudança de rotina.