Acceso VPN con certificado no Mac: identidade, uso da clave ou confianza na pasarela?

Os accesos VPN con certificado pídenlle ao Mac algo máis restrinxido ca un contrasinal: usar esta clave privada concreta, neste contexto de execución, para demostrar unha identidade a esa pasarela. Cando falla, a mensaxe adoita describir só a última cousa que foi mal, que raramente é a que o causou. Percorrer as tres decisións na orde en que as toma o sistema mantén o diagnóstico honesto, e evita que un problema de permisos local se trate como un fallo de validación da cadea.

Percorre o acceso na orde en que o fai o Mac

Primeiro o cliente escolle unha identidade: un certificado emparellado cunha clave privada utilizábel, dispoñíbel a través do almacén ou do provedor de credenciais admitido. Despois o compoñente VPN pide realizar unha operación criptográfica con esa clave, e o modelo de autorización local responde. Só despois de que ambas as dúas teñan éxito ocorre o apretón de mans remoto, onde o Mac avalía a pasarela e a pasarela avalía a proba do cliente.

Le a táboa de arriba abaixo e detente na primeira fila que falla. Todo o que está por debaixo dun fallo non está probado, e por iso “o certificado non é de confianza” é unha conclusión tan común e tan pouco fiable.

Que abrangue realmente o permiso local

No modelo de chaveiro de macOS, os elementos protexidos levan regras de acceso específicas de cada operación e unha lista de aplicacións de confianza. Asinar cunha clave privada é unha desas operacións, e as regras aplícanse ao executábel que a realiza, non ao certificado como documento. A referencia de control de acceso de Apple tamén traza unha liña entre este modelo e o chaveiro iCloud e os axustes de grupo de acceso, así que os consellos escritos para un non se trasladan ao outro.

Séguese dúas consecuencias. Que un certificado público sexa visíbel nunha lista non proba que o compoñente en segundo plano da VPN poida chegar a esa clave. E o permiso concedido a unha aplicación de interface non di nada sobre un axudante ou unha extensión de rede separados, porque son código distinto con identidades distintas.

Identifica a implementación real e o seu mecanismo admitido de compartición de credenciais en vez de copiar unha ruta de executábel dun cliente vello. Confirma que identidade ofrecerá o sistema en primeiro lugar:

security find-identity -v -p ssl-client

Ler errSecInteractionNotAllowed

Ese estado informa dunha interacción non permitida co Security Server, e non di nada sobre cadeas de certificados. Léo xunto coa operación que o produciu: unha solicitude de sinatura emitida desde un contexto que non pode presentar unha solicitude ao usuario falla deste xeito mesmo cando a clave e o certificado son perfectamente válidos. A operación que o rexistrou, non o almacén de certificados, é o lugar por onde comezar. Calquera cousa que cambies sobre as áncoras de confianza deixará o erro exactamente onde estaba.

Así que trata o código como un motivo para examinar o contexto de execución e a autorización. Tratalo como proba de que a CA da pasarela non é de confianza lévao á metade equivocada do problema, e o cambio que fagas alí non afectará o erro en absoluto.

Repara de forma estreita, non ampla

Comeza polas instrucións de rexistro ou importación do propietario da conexión. Rexistra a versión do cliente, o ámbito do perfil, a identidade escollida e o primeiro erro local relevante, porque eses catro feitos son o que precisa unha entrega a soporte e do que depende unha comparación posterior. Un perfil xestionado ou unha identidade con respaldo de hardware pode requirir que o administrador ou o provedor reparen a entrega, e ningunha cantidade de clics locais substitúe iso.

Onde o produto espera unha aprobación do usuario, confirma que compoñente a pide e aproba só ese acceso mediante o fluxo admitido. Onde o compoñente non ten forma de presentar unha solicitude no contexto en que se executa, o aprovisionamento ten que seguir a ruta que documenta o fabricante, non un diálogo sacado doutra xanela de terminal.

Dous cambios veñen xuntos nos consellos antigos, e ambos son demasiado amplos. Conceder a toda aplicación acceso á clave privada amplía o uso local da clave moito máis alá do requisito, e poñer o certificado en Always Trust cambia a avaliación de certificados para todo na máquina. Ningún dos dous expresa “esta implementación VPN aprobada, usando esta identidade prevista”.

Comproba localmente antes de ler a pasarela

Despois dunha reparación, confirma que a operación local ten éxito antes de interpretares calquera resposta da outra banda. Se a sinatura agora funciona, un rexeitamento posterior de nome, cadea ou admisión de cliente é un resultado novo e non unha recorrencia, e pertence a outra decisión con outro responsable.

Unha entrega útil nomea cal das tres decisións fallou e detense aí. Nunca inclúe a clave privada, e nunca restablece elementos do chaveiro alleos coa esperanza de que unha folla limpa axude. Establece eses dous hábitos antes do incidente e non durante el, cando a tentación de probalo todo á vez é máis forte. Unha incidencia que di “reconstruín o chaveiro” non lle di case nada ao seguinte lector sobre o fallo orixinal.