Autentificare VPN cu certificat pe Mac: identitate, folosirea cheii sau încrederea în gateway?
Trei decizii stau în spatele autentificării cu certificat: ce identitate este aleasă, dacă componenta VPN poate să își folosească cheia și dacă gateway-ul este de încredere.
Autentificările VPN bazate pe certificat cer Mac-ului ceva mai îngust decât o parolă: folosește această cheie privată anume, în acest context de execuție, pentru a dovedi o identitate acelui gateway. Când eșuează, mesajul descrie de obicei doar ultimul lucru care a mers prost, iar acela este rareori cauza. Parcurgerea celor trei decizii în ordinea în care le ia sistemul ține diagnosticul onest și împiedică tratarea unei probleme locale de permisiuni ca eșec de validare a lanțului.
Parcurge autentificarea în ordinea în care o face Mac-ul
Mai întâi clientul alege o identitate: un certificat împerecheat cu o cheie privată utilizabilă, disponibil prin depozitul sau furnizorul de acreditări acceptat. Apoi componenta VPN cere efectuarea unei operații criptografice cu acea cheie, iar modelul local de autorizare răspunde. Abia după ce ambele reușesc are loc strângerea de mână la distanță, unde Mac-ul evaluează gateway-ul, iar gateway-ul evaluează dovada clientului.
| 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 |
Citește tabelul de sus în jos și oprește-te la primul rând care eșuează. Tot ce se află sub un eșec este nedovedit, de aceea „certificatul nu este de încredere” este o concluzie atât de frecventă și atât de nesigură.
Ce acoperă de fapt permisiunea locală
În modelul brelocului din macOS, elementele protejate poartă reguli de acces specifice operației și o listă de aplicații de încredere. Semnarea cu o cheie privată este una dintre acele operații, iar regulile se aplică executabilului care o face, nu certificatului ca document. Referința Apple privind controlul accesului trasează de asemenea o linie între acest model și brelocul iCloud și aranjamentele grupurilor de acces, așa că un sfat scris pentru unul nu se transferă la celălalt.
Urmează două consecințe. Un certificat public vizibil într-o listă nu dovedește că componenta din fundal a VPN-ului poate ajunge măcar la acea cheie. Iar o permisiune acordată unei aplicații din prim-plan nu spune nimic despre un ajutor sau o extensie de rețea separate, pentru că sunt cod diferit cu identități diferite.
Identifică implementarea reală și mecanismul ei acceptat de partajare a acreditărilor, în loc să copiezi o cale de executabil dintr-un client vechi. Confirmă mai întâi ce identitate va oferi sistemul:
security find-identity -v -p ssl-clientCum se citește errSecInteractionNotAllowed
Acel status raportează o interacțiune nepermisă cu Security Server și nu spune nimic despre lanțurile de certificate. Citește-l împreună cu operația care l-a produs: o cerere de semnare emisă dintr-un context care nu poate afișa o solicitare va eșua astfel chiar și atunci când cheia și certificatul sunt amândouă perfect valide. Locul de început este operația care l-a consemnat, nu depozitul de certificate. Orice ai schimba la ancorele de încredere va lăsa eroarea exact acolo unde era.
Așadar tratează codul ca motiv de a examina contextul de execuție și autorizarea. Tratarea lui ca dovadă că AC-ul gateway-ului nu este de încredere te trimite în jumătatea greșită a problemei, iar schimbarea făcută acolo nu va afecta deloc eroarea.
Repară îngust, nu larg
Începe cu instrucțiunile de înregistrare sau import ale proprietarului conexiunii. Notează versiunea clientului, sfera profilului, identitatea aleasă și prima eroare locală relevantă, pentru că aceste patru fapte sunt cele de care are nevoie o predare la suport și de care depinde o comparație ulterioară. Un profil administrat sau o identitate susținută de hardware poate cere administratorului sau furnizorului să repare predarea, iar nicio cantitate de clicuri locale nu înlocuiește asta.
Acolo unde produsul așteaptă o aprobare a utilizatorului, confirmă ce componentă o cere și aprobă doar acel acces prin fluxul acceptat. Acolo unde componenta nu are cum să ridice o solicitare în contextul în care rulează, provizionarea trebuie să urmeze ruta documentată de furnizor, nu un dialog smuls din altă fereastră de terminal.
Două modificări sunt grupate în sfaturi mai vechi și amândouă sunt prea largi. Acordarea accesului la cheia privată pentru fiecare aplicație lărgește folosirea locală a cheii mult peste cerință, iar setarea certificatului pe Always Trust schimbă evaluarea certificatelor pentru tot ce se află pe mașină. Niciuna nu exprimă „această implementare VPN aprobată, folosind această identitate prevăzută”.
Verifică local înainte de a citi gateway-ul
După o reparație, confirmă că operația locală reușește înainte de a interpreta orice răspuns de la cealaltă parte. Dacă semnarea funcționează acum, o respingere ulterioară de nume, lanț sau admitere a clientului este un rezultat nou și nu o recurență, iar ea aparține altei decizii cu alt responsabil.
O predare utilă numește care dintre cele trei decizii a eșuat și se oprește acolo. Nu include niciodată cheia privată și nu resetează niciodată elemente nelegate ale brelocului în speranța că o stare curată va ajuta. Stabilește cele două obiceiuri înainte de incident, nu în timpul lui, când ispita de a încerca totul deodată este cea mai puternică. Un tichet care spune „brelocul a fost reconstruit” aproape nu-i spune nimic cititorului următor despre defectul original.