Inici de sessió VPN amb certificat al Mac: identitat, ús de la clau o confiança en la passarel·la?
Tres decisions hi ha darrere d’un inici de sessió amb certificat: quina identitat es tria, si el component VPN pot utilitzar la seva clau i si es confia en la passarel·la.
Els inicis de sessió VPN basats en certificats demanen al Mac una cosa més estreta que una contrasenya: fer servir aquesta clau privada concreta, en aquest context d’execució, per demostrar una identitat a aquella passarel·la. Quan falla, el missatge sol descriure només l’última cosa que va anar malament, que poques vegades és la que ho va causar. Recórrer les tres decisions en l’ordre en què les pren el sistema manté el diagnòstic honest i evita que un problema local de permisos es tracti com una fallada de validació de la cadena.
Recorreu l’inici de sessió en l’ordre que segueix el Mac
Primer el client tria una identitat: un certificat aparellat amb una clau privada utilitzable, disponible a través del magatzem compatible o del proveïdor de credencials. Després el component VPN demana fer una operació criptogràfica amb aquesta clau, i el model local d’autorització respon. Només quan tots dos tenen èxit es produeix l’intercanvi remot, on el Mac avalua la passarel·la i la passarel·la avalua la prova del client.
| 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 |
Llegiu la taula de dalt a baix i atureu-vos a la primera fila que falla. Tot el que hi ha sota una fallada no està provat, i per això «el certificat no és de confiança» és una conclusió tan habitual i tan poc fiable.
Què cobreix realment el permís local
En el model de clauer de macOS, els elements protegits porten regles d’accés específiques de l’operació i una llista d’aplicacions de confiança. Signar amb una clau privada és una d’aquestes operacions, i les regles s’apliquen a l’executable que la fa, no al certificat com a document. La referència de control d’accés d’Apple també traça una línia entre aquest model i el clauer d’iCloud i els arranjaments de grups d’accés, de manera que un consell escrit per a un no es trasllada a l’altre.
Se’n deriven dues conseqüències. Que un certificat públic sigui visible en una llista no demostra que el component en segon pla del VPN pugui arribar a aquesta clau. I el permís concedit a una aplicació frontal no diu res sobre un assistent o una extensió de xarxa separats, perquè són codi diferent amb identitats diferents.
Identifiqueu la implementació real i el seu mecanisme compatible de compartició de credencials en lloc de copiar una ruta d’executable d’un client antic. Confirmeu quina identitat oferirà el sistema en primer lloc:
security find-identity -v -p ssl-clientLectura del codi errSecInteractionNotAllowed
Aquest estat informa d’una interacció no permesa amb el servidor de seguretat i no diu res sobre les cadenes de certificats. Llegiu-lo juntament amb l’operació que el va produir: una sol·licitud de signatura emesa des d’un context que no pot mostrar cap avís fallarà d’aquesta manera encara que la clau i el certificat siguin perfectament vàlids. El lloc per començar és l’operació que el va registrar, no el magatzem de certificats. Qualsevol canvi en els àncores de confiança deixarà l’error exactament on era.
Per tant, tracteu el codi com un motiu per examinar el context d’execució i l’autorització. Tractar-lo com a prova que la CA de la passarel·la no és de confiança us envia a la meitat equivocada del problema, i el canvi que hi feu no afectarà gens l’error.
Repareu de manera estreta, no àmplia
Comenceu per les instruccions d’inscripció o importació del propietari de la connexió. Anoteu la versió del client, l’abast del perfil, la identitat seleccionada i el primer error local rellevant, perquè aquests quatre fets són el que necessita un traspàs a suport i del que depèn una comparació posterior. Un perfil gestionat o una identitat recolzada per maquinari pot requerir que l’administrador o el proveïdor repari el traspàs, i cap clic local ho substitueix.
On el producte espera una aprovació de l’usuari, confirmeu quin component la demana i aproveu només aquell accés pel flux compatible. On el component no té manera de mostrar un avís en el context en què s’executa, l’aprovisionament ha de seguir la ruta que documenta el proveïdor, no un diàleg tret d’una altra finestra de terminal.
En consells antics s’agrupen dos canvis, i tots dos són massa amplis. Donar accés a la clau privada a totes les aplicacions amplia l’ús local de la clau molt més enllà del requisit, i posar el certificat a «Sempre fiable» canvia l’avaluació de certificats per a tot el que hi ha a la màquina. Cap dels dos expressa «aquesta implementació VPN aprovada, amb aquesta identitat prevista».
Comproveu-ho localment abans de llegir la passarel·la
Després d’una reparació, confirmeu que l’operació local té èxit abans d’interpretar qualsevol resposta de l’altra banda. Si ara la signatura funciona, un rebuig posterior de nom, cadena o admissió de client és un resultat nou i no una recurrència, i pertany a una altra decisió amb un altre propietari.
Un traspàs útil anomena quina de les tres decisions ha fallat i s’atura aquí. Mai inclou la clau privada, i mai reinicia elements del clauer no relacionats amb l’esperança que un full net ajudi. Assenteu aquests dos hàbits abans de l’incident i no durant, quan la temptació de provar-ho tot alhora és més forta. Un tiquet que diu «hem reconstruït el clauer» no diu gairebé res al lector següent sobre la fallada original.