Certificado VPN de Mac: por qué el selector de identidad sigue vacío

Instalaste el certificado, aparece en Acceso a Llaveros con un nombre descriptivo y el selector de identidad del cliente VPN sigue vacío. El cliente no busca un certificado. Busca una identidad: un certificado emparejado con la clave privada capaz de demostrar su posesión, guardado donde el cliente tiene permiso para leerlo.

Lo que pide el cliente es una identidad

El marco de seguridad de Apple trata un certificado y una identidad como objetos distintos. Un certificado son datos públicos. Una identidad es ese certificado más su clave privada, y solo la identidad puede completar un desafío. Un certificado de CA de confianza, en cambio, permite a un cliente evaluar un emisor; no convierte a la máquina en titular de una credencial de cliente emitida.

Por eso, importar un archivo .cer nunca produce una identidad de cliente utilizable. El archivo solo contiene material público, y por mucho que lo renombres o lo marques como de confianza, no se convierte en un par de claves.

Tres razones por las que el selector sigue vacío

La primera es una clave privada ausente, lo que significa que el proceso de inscripción o de importación no entregó ninguna. La segunda es un almacén que el cliente no consulta: un perfil con ámbito de usuario busca en el llavero del usuario, y un elemento colocado en un almacén del sistema puede resultarle invisible. La tercera es un desajuste de propósito o de política: el certificado existe, pero no es válido para la autenticación de clientes según las reglas del despliegue.

security find-identity -v -p ssl-client

Esto enumera las identidades que el sistema considera válidas para la autenticación de clientes. Si el recuento es cero, el problema está antes del cliente VPN y ninguna edición del perfil lo arreglará. Si la identidad aparece aquí pero no en el cliente, la diferencia está en el almacén o en el ámbito del cliente.

Dónde vive la clave privada y quién puede usarla

Cuando importas una identidad con Acceso a Llaveros, el diálogo de importación ofrece un llavero de destino. Qué destino es correcto depende del cliente y de si el perfil tiene ámbito de usuario o de dispositivo. Una respuesta antigua que recomienda el llavero del sistema no es una regla universal, y copiar elementos entre almacenes no es una reparación.

System Roots es una colección de confianza. Poner un certificado ahí cambia qué emisores confía el sistema; no crea una clave privada y no es un almacén de identidades. Mover certificados no relacionados para llenar un selector es el tipo de arreglo que deja una máquina con un conjunto de confianza ampliado de forma permanente.

El acceso a la clave privada es un control aparte. Conceder a todas las aplicaciones permiso para usar la clave resuelve el problema de selección de un cliente y entrega la misma capacidad a todo lo demás en la máquina. Concédelo al cliente que lo necesita y comprueba si la clave está respaldada por hardware o marcada como no exportable; si lo está, hay que usar el proveedor admitido en lugar de una copia exportada.

Cómo apunta el perfil a la credencial

En una configuración IKEv2 nativa administrada, el perfil hace referencia a su carga de credenciales mediante PayloadCertificateUUID. Lo que importa es la identidad referenciada y cómo se aprovisionó; editar un nombre para mostrar en el perfil no repara una referencia que apunta a la carga equivocada o a una que nunca entregó una clave.

Un proveedor de terceros puede usar un mecanismo de selección completamente distinto, como su propio almacén o un aviso del sistema. Lee la documentación de ese proveedor en lugar de trasladar suposiciones de perfiles nativos, y verifica la referencia en el perfil que está realmente instalado, no en el borrador de la consola de administración.

Selección y aceptación son hitos separados

Un selector poblado significa que el cliente puede encontrar y usar una identidad. No dice nada sobre si la puerta de enlace la aceptará. El servidor sigue comprobando el emisor, la ventana de validez, el estado de revocación y la asignación de esa credencial a una cuenta.

Prueba ambas etapas de forma explícita, en ese orden. Confirma que se ofrece la identidad, conéctate y luego pide al propietario de la puerta de enlace que confirme qué credencial se presentó y qué regla de asignación la consumió. Si el cliente ofrece una identidad y el servidor la rechaza, el trabajo restante está del lado del servidor. Reinstalar el certificado en el Mac no cambiará ese resultado, por muchas veces que se repita.