Inicio de sesión VPN con certificado en el Mac: ¿identidad, uso de la clave o confianza en la puerta de enlace?
Tres decisiones hay detrás de un inicio de sesión con certificado: qué identidad se elige, si el componente VPN puede usar su clave y si se confía en la puerta de enlace.
Los inicios de sesión VPN basados en certificados piden al Mac algo más estrecho que una contraseña: usar esta clave privada concreta, en este contexto de ejecución, para demostrar una identidad a esa puerta de enlace. Cuando falla, el mensaje suele describir solo lo último que salió mal, que rara vez es la causa. Recorrer las tres decisiones en el orden en que las toma el sistema mantiene el diagnóstico honesto y evita que un problema local de permisos se trate como un fallo de validación de la cadena.
Recorra el inicio de sesión en el orden que sigue el Mac
Primero el cliente elige una identidad: un certificado emparejado con una clave privada utilizable, disponible a través del almacén compatible o del proveedor de credenciales. Después el componente VPN pide realizar una operación criptográfica con esa clave, y el modelo local de autorización responde. Solo cuando ambos tienen éxito se produce el intercambio remoto, donde el Mac evalúa la puerta de enlace y la puerta de enlace evalúa la prueba del cliente.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
Lea la tabla de arriba abajo y deténgase en la primera fila que falle. Todo lo que queda por debajo de un fallo no está probado, y por eso «el certificado no es de confianza» es una conclusión tan habitual y tan poco fiable.
Qué cubre en realidad el permiso local
En el modelo de llavero de macOS, los elementos protegidos llevan reglas de acceso específicas de la operación y una lista de aplicaciones de confianza. Firmar con una clave privada es una de esas operaciones, y las reglas se aplican al ejecutable que la realiza, no al certificado como documento. La referencia de control de acceso de Apple también traza una línea entre este modelo y el llavero de iCloud y los arreglos de grupos de acceso, así que un consejo escrito para uno no se traslada al otro.
Se derivan dos consecuencias. Que un certificado público sea visible en una lista no demuestra que el componente en segundo plano del VPN pueda siquiera llegar a esa clave. Y el permiso concedido a una aplicación frontal no dice nada sobre un asistente o una extensión de red separados, porque son código distinto con identidades distintas.
Identifique la implementación real y su mecanismo compatible de compartición de credenciales en lugar de copiar una ruta de ejecutable de un cliente antiguo. Confirme qué identidad ofrecerá el sistema en primer lugar:
security find-identity -v -p ssl-clientLectura del código errSecInteractionNotAllowed
Ese estado informa de una interacción no permitida con el servidor de seguridad y no dice nada sobre las cadenas de certificados. Léalo junto con la operación que lo produjo: una solicitud de firma emitida desde un contexto que no puede mostrar un aviso fallará de esta manera incluso cuando la clave y el certificado sean perfectamente válidos. El lugar por donde empezar es la operación que lo registró, no el almacén de certificados. Cualquier cambio en los anclajes de confianza dejará el error exactamente donde estaba.
Por tanto, trate el código como un motivo para examinar el contexto de ejecución y la autorización. Tratarlo como prueba de que la CA de la puerta de enlace no es de confianza lo envía a la mitad equivocada del problema, y el cambio que haga allí no afectará en absoluto al error.
Repare de forma estrecha, no amplia
Empiece por las instrucciones de inscripción o importación del propietario de la conexión. Anote la versión del cliente, el alcance del perfil, la identidad seleccionada y el primer error local relevante, porque esos cuatro hechos son lo que necesita un traspaso a soporte y de lo que depende una comparación posterior. Un perfil gestionado o una identidad respaldada por hardware puede requerir que el administrador o el proveedor repare el traspaso, y ningún clic local lo sustituye.
Donde el producto espera una aprobación del usuario, confirme qué componente la pide y apruebe solo ese acceso por el flujo compatible. Donde el componente no tiene forma de mostrar un aviso en el contexto en que se ejecuta, el aprovisionamiento debe seguir la ruta que documenta el proveedor, no un diálogo sacado de otra ventana de terminal.
En consejos antiguos se agrupan dos cambios, y ambos son demasiado amplios. Dar acceso a la clave privada a todas las aplicaciones amplía el uso local de la clave mucho más allá del requisito, y poner el certificado en «Confiar siempre» cambia la evaluación de certificados para todo lo que hay en la máquina. Ninguno de los dos expresa «esta implementación VPN aprobada, con esta identidad prevista».
Compruebe localmente antes de leer la puerta de enlace
Tras una reparación, confirme que la operación local tiene éxito antes de interpretar cualquier respuesta del otro lado. Si ahora la firma funciona, un rechazo posterior de nombre, cadena o admisión de cliente es un resultado nuevo y no una recurrencia, y pertenece a otra decisión con otro propietario.
Un traspaso útil nombra cuál de las tres decisiones falló y se detiene ahí. Nunca incluye la clave privada, y nunca restablece elementos del llavero no relacionados con la esperanza de que una pizarra limpia ayude. Establezca esos dos hábitos antes del incidente y no durante, cuando la tentación de probarlo todo a la vez es más fuerte. Un ticket que dice «reconstruimos el llavero» no dice casi nada al siguiente lector sobre el fallo original.