Mac IKEv2 ECDSA: qual tipo de certificado pertence ao cliente?
Num Mac, ECDSA256 nas definições de IKEv2 descreve o certificado de identidade local, não o gateway nem a assinatura do emissor. Leia cada papel antes de escolher.
No macOS, a escolha de ECDSA numa definição de cliente IKEv2 responde a uma pergunta estreita: que certificado prova a identidade do Mac. Não descreve o certificado do gateway, a assinatura que emitiu o certificado do cliente nem a proposta de cifra do túnel. Tratar esses quatro papéis como uma única questão de compatibilidade é a forma como uma configuração local correta acaba culpada por um desajuste do lado do servidor. A decisão é pequena, mas as provas usadas para a tomar têm de ser precisas.
O campo nomeia um certificado: a identidade local
A API Network Extension da Apple expõe um tipo de certificado para a credencial do cliente, incluindo NEVPNIKEv2CertificateType.ECDSA256, documentado como o tipo de certificado ECDSA p-256. A propriedade aplica-se ao certificado fornecido através de identityReference ou identityData.
Isto significa que a decisão diz respeito ao certificado que o Mac apresenta, mais a chave privada que o acompanha. Escolha o tipo que corresponde à chave pública desse certificado folha e forneça a identidade pelo mecanismo suportado. Se o Mac não tiver uma chave privada utilizável para a identidade, a escolha do tipo não pode salvar a ligação.
Os perfis geridos tomam a mesma decisão através de CertificateType da carga IKEv2, em conjunto com uma referência de certificado como PayloadCertificateUUID. Esses campos têm pré-requisitos e um esquema para a versão do sistema operativo de destino; um valor de tipo nu copiado para um perfil não é instalável, e uma janela de definições pode não expor todas as opções da API. Verifique os pré-requisitos da carga para essa versão antes da implementação.
Decida pelo papel, não pelo rótulo do certificado
Leia o campo que vai alterar e pergunte a que certificado aponta. Os rótulos num visualizador de certificados misturam o sujeito, o emissor e o algoritmo de assinatura, e apenas um deles pertence à escolha da identidade do cliente.
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
Se o visualizador de certificados mostrar uma assinatura ECDSA da CA, isso descreve a chave de assinatura do emissor. A chave do próprio cliente pode continuar a ser RSA, e o campo de tipo deve seguir a chave do cliente, não a linha de assinatura. Esta única confusão explica muitos relatos de "ECDSA está configurado mas a ligação falha". Compare o tipo de chave na folha com o tipo selecionado no perfil antes de alterar seja o que for.
A decisão torna-se mais simples depois de identificada a folha: ECDSA256 para uma chave de cliente p-256, outro tipo suportado para uma chave diferente. Se o certificado do cliente e a sua chave não coincidirem, corrija esse par antes de alterar o perfil VPN.
O certificado do gateway é uma decisão separada
O gateway apresenta o seu próprio certificado e o Mac valida-o contra uma âncora de confiança e um nome esperado. Se esse certificado usa ECDSA, RSA ou outro tipo de chave é uma propriedade do servidor, não da definição de identidade do cliente.
O suporte local de um certificado de cliente ECDSA não prova que todos os certificados de gateway, curvas ou configurações de autenticação do servidor vão interoperar. Verifique a identidade do servidor, a sua cadeia e o seu método de autenticação IKE como entradas separadas, e teste com o perfil que será realmente implementado.
Se o certificado do gateway for o problema, o sintoma aparece normalmente durante a validação do par e não na seleção de identidade. Leia a fase de falha antes de alterar o tipo de cliente, porque uma falha de confiança e um desajuste de chave do cliente não partilham a mesma correção.
A assinatura do emissor e o grupo de acordo de chaves não são o tipo do cliente
O X.509 mantém a chave pública do sujeito e a assinatura do emissor em campos diferentes. A informação de chave pública do sujeito descreve a chave no certificado; o algoritmo de assinatura descreve a chave da CA e a operação de assinatura. Só a primeira corresponde à definição do tipo de certificado.
As propostas IKE e Child SA são outro eixo. Um tipo de certificado ECDSA não é uma escolha de cifra ESP, e mudar o grupo de acordo de chaves não seleciona um tipo de certificado. Um perfil pode ter propostas válidas e o tipo de identidade errado, ou o tipo de identidade certo e uma proposta que o par rejeita.
Mantenha as três linhas separadas no registo de alterações: certificado e chave de identidade, entradas de confiança do gateway e algoritmos das propostas. Juntá-las numa única nota de "definições de criptografia" torna a falha seguinte impossível de atribuir.
Verifique a decisão com os campos que configurou
Verifique a identidade a que o perfil se refere realmente e confirme depois que o certificado nessa referência tem a chave pública esperada e uma chave privada utilizável. O tipo apresentado na interface, o certificado referenciado e a chave no dispositivo têm de coincidir.
De seguida confirme as entradas do gateway: o nome de servidor esperado, a âncora de confiança e o método de autenticação IKE. Por fim, ligue-se e leia onde o handshake para. Uma falha antes da troca de identidade aponta para fora desta definição; uma falha na validação do par aponta para o lado do gateway.
Registe o tipo escolhido, a referência de identidade e o sujeito do certificado do gateway nas notas de implementação. A próxima atualização do perfil pode alterar qualquer um deles, e três valores nomeados comparam-se mais depressa do que uma captura de ecrã de um painel de definições.