Mac IKEv2 ECDSA: que tipo de certificado corresponde ao cliente?
Nun Mac, ECDSA256 nos axustes de IKEv2 describe o certificado de identidade local, non a pasarela nin a sinatura do emisor. Le cada rol antes de escoller.
En macOS, a escolla de ECDSA nun axuste de cliente IKEv2 responde a unha pregunta estreita: que certificado demostra a identidade do Mac. Non describe o certificado da pasarela, a sinatura que emitiu o certificado do cliente nin a proposta de cifrado do túnel. Tratar eses catro papeis como unha soa cuestión de compatibilidade é a forma en que un axuste local correcto acaba culpado dun desaxuste do lado do servidor. A decisión é pequena, pero as probas que se usan para tomala deben ser precisas.
O campo nomea un certificado: a identidade local
A API Network Extension de Apple expón un tipo de certificado para a credencial do cliente, incluído NEVPNIKEv2CertificateType.ECDSA256, documentado como o tipo de certificado ECDSA p-256. A propiedade aplícase ao certificado subministrado mediante identityReference ou identityData.
Isto significa que a decisión trata do certificado que presenta o Mac, máis a clave privada que o acompaña. Escolle o tipo que coincida coa clave pública dese certificado folla e subministra a identidade mediante o mecanismo admitido. Se o Mac non ten unha clave privada utilizábel para a identidade, a escolla do tipo non pode salvar a conexión.
Os perfís xestionados toman a mesma decisión mediante CertificateType da carga de IKEv2, xunto cunha referencia de certificado como PayloadCertificateUUID. Eses campos teñen requisitos previos e un esquema para a versión do sistema operativo de destino; un valor de tipo espido copiado nun perfil non é instalábel, e unha xanela de axustes pode non expor todas as opcións da API. Comproba os requisitos previos da carga para esa versión antes do despregamento.
Decide por rol, non pola etiqueta do certificado
Le o campo que estás a piques de cambiar e pregunta a que certificado apunta. As etiquetas dun visor de certificados mesturan o suxeito, o emisor e o algoritmo de sinatura, e só unha delas pertence á escolla 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 visor de certificados mostra unha sinatura ECDSA da CA, iso describe a clave de sinatura do emisor. A clave propia do cliente pode seguir sendo RSA, e o campo de tipo debe seguir a clave do cliente, non a liña de sinatura. Esta única confusión explica moitos informes de "ECDSA está configurado pero a conexión falla". Compara o tipo de clave da folla co tipo seleccionado no perfil antes de cambiar nada.
A decisión simplifícase unha vez identificada a folla: ECDSA256 para unha clave de cliente p-256, outro tipo admitido para unha clave distinta. Se o certificado do cliente e a súa clave non coinciden, corrixe ese par antes de cambiar o perfil de VPN.
O certificado da pasarela é unha decisión aparte
A pasarela presenta o seu propio certificado e o Mac valídao contra unha áncora de confianza e un nome esperado. Que ese certificado use ECDSA, RSA ou outro tipo de clave é unha propiedade do servidor, non do axuste de identidade do cliente.
O soporte local dun certificado de cliente ECDSA non demostra que todos os certificados de pasarela, curvas ou configuracións de autenticación do servidor vaian interoperar. Comproba a identidade do servidor, a súa cadea e o seu método de autenticación IKE como entradas separadas, e proba co perfil que realmente se despregará.
Se o certificado da pasarela é o problema, o síntoma adoita aparecer durante a validación do par, non na selección de identidade. Le a etapa de fallo antes de cambiar o tipo de cliente, porque un fallo de confianza e un desaxuste de clave do cliente non comparten solución.
A sinatura do emisor e o grupo de acordo de claves non son o tipo do cliente
X.509 mantén a clave pública do suxeito e a sinatura do emisor en campos distintos. A información de clave pública do suxeito describe a clave do certificado; o algoritmo de sinatura describe a clave da CA e a operación de sinatura. Só a primeira coincide co axuste de tipo de certificado.
As propostas de IKE e Child SA son outro eixe. Un tipo de certificado ECDSA non é unha escolla de cifrado ESP, e cambiar o grupo de acordo de claves non selecciona un tipo de certificado. Un perfil pode ter propostas válidas e o tipo de identidade equivocado, ou o tipo de identidade correcto e unha proposta que o par rexeita.
Mantén as tres liñas separadas no rexistro de cambios: certificado e clave de identidade, entradas de confianza da pasarela e algoritmos das propostas. Combinalas nunha soa nota de "axustes cripto" fai que o seguinte fallo sexa imposíbel de atribuír.
Verifica a decisión cos campos que configuraches
Comproba a identidade á que o perfil fai referencia realmente, e despois confirma que o certificado desa referencia ten a clave pública esperada e unha clave privada utilizábel. O tipo mostrado na interface, o certificado referenciado e a clave no dispositivo teñen que coincidir.
A continuación confirma as entradas da pasarela: o nome do servidor esperado, a áncora de confianza e o método de autenticación IKE. Por último, conéctate e le onde se detén o handshake. Un fallo antes do intercambio de identidade apunta fóra deste axuste; un fallo na validación do par apunta ao lado da pasarela.
Anota o tipo escollido, a referencia de identidade e o suxeito do certificado da pasarela nas notas de despregamento. A próxima actualización do perfil pode cambiar calquera deles, e tres valores nomeados compáranse máis rápido que unha captura de pantalla dun panel de axustes.