Mac VPN sertifikaadiga sisselogimine: identiteet, võtme kasutamine või lüüsi usaldus?
Sertifikaadiga sisselogimise taga on kolm otsust: milline identiteet valitakse, kas VPN-komponent tohib oma võtit kasutada ja kas lüüsi usaldatakse.
Sertifikaadipõhised VPN-sisselogimised nõuavad Macilt midagi kitsamat kui parool: kasutada seda konkreetset privaatvõtit, selles käituskontekstis, et tõestada identiteeti sellele lüüsile. Kui see ebaõnnestub, kirjeldab teade tavaliselt ainult viimast asja, mis valesti läks, ja see on harva põhjus. Kolme otsuse läbimine samas järjekorras, milles süsteem need teeb, hoiab diagnoosi ausana ja takistab kohaliku õiguste probleemi käsitlemist ahela valideerimise tõrkena.
Käige sisselogimine läbi samas järjekorras nagu Mac
Kõigepealt valib klient identiteedi: kasutatava privaatvõtmega seotud sertifikaat, mis on saadaval toetatud hoidla või volituste pakkuja kaudu. Seejärel palub VPN-komponent selle võtmega krüptograafilist toimingut teha ja kohalik autoriseerimismudel vastab. Alles pärast mõlema õnnestumist toimub kaugkätlus, kus Mac hindab lüüsi ja lüüs hindab kliendi tõestust.
| 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 |
Lugege tabelit ülalt alla ja peatuge esimesel real, mis ebaõnnestub. Kõik tõrke all on tõestamata, mistõttu „sertifikaat ei ole usaldusväärne“ on nii tavaline ja nii ebausaldusväärne järeldus.
Mida kohalik luba tegelikult katab
macOS-i võtmehoidla mudelis kannavad kaitstud üksused toimingupõhiseid juurdepääsureegleid ja usaldusväärsete rakenduste loendit. Privaatvõtmega allkirjastamine on üks neist toimingutest ja reeglid kehtivad seda teostavale käivitatavale failile, mitte sertifikaadile kui dokumendile. Apple'i juurdepääsukontrolli viide tõmbab ka piiri selle mudeli ning iCloudi võtmehoidla ja juurdepääsugruppide korralduste vahele, nii et ühe jaoks kirjutatud nõuanne ei kandu teisele üle.
Sellest tuleneb kaks tagajärge. Avaliku sertifikaadi nähtavus loendis ei tõesta, et VPN-i taustakomponent selle võtmeni üldse jõuab. Ja esirakendusele antud luba ei ütle midagi eraldi abiprogrammi ega võrgulaiendi kohta, sest need on erinev kood erinevate identiteetidega.
Tehke kindlaks tegelik teostus ja selle toetatud volituste jagamise mehhanism, selle asemel et kopeerida käivitatava faili tee vanast kliendist. Kinnitage, millist identiteeti süsteem üldse pakub:
security find-identity -v -p ssl-clientKoodi errSecInteractionNotAllowed lugemine
See olek teatab keelatud suhtlusest turvaserveriga ega ütle midagi sertifikaadiahelate kohta. Lugege seda koos toiminguga, mis selle tekitas: kontekstist väljastatud allkirjastamistaotlus, mis ei saa viipa näidata, ebaõnnestub nii ka siis, kui võti ja sertifikaat on mõlemad täiesti kehtivad. Alustada tuleb toimingust, mis selle logis, mitte sertifikaadihoidlast. Iga muudatus usaldusankrutes jätab vea täpselt sinna, kus see oli.
Kohelge seega koodi põhjusena uurida käituskonteksti ja autoriseerimist. Selle käsitlemine tõendina, et lüüsi CA ei ole usaldusväärne, saadab teid probleemi valesse poolde ja seal tehtud muudatus ei mõjuta viga üldse.
Parandage kitsalt, mitte laialt
Alustage ühenduse omaniku registreerimis- või importimisjuhistest. Kirjutage üles kliendi versioon, profiili ulatus, valitud identiteet ja esimene asjakohane kohalik viga, sest need neli fakti on see, mida tugiteenusele üleandmine vajab ja millest hilisem võrdlus sõltub. Hallatav profiil või riistvaratoega identiteet võib nõuda, et administraator või teenusepakkuja üleandmise parandaks, ja ükski kohalik klõpsamine ei asenda seda.
Kui toode ootab kasutaja kinnitust, tehke kindlaks, milline komponent seda palub, ja kinnitage ainult see juurdepääs toetatud voo kaudu. Kui komponendil pole võimalust käituskontekstis viipa esile tuua, peab seadistamine järgima tarnija dokumenteeritud teed, mitte mõnest teisest terminaliaknast välja meelitatud dialoogi.
Vanemates nõuannetes pakendatakse kaks muudatust kokku ja mõlemad on liiga laiad. Igale rakendusele privaatvõtmele juurdepääsu andmine laiendab kohalikku võtmekasutust kaugele üle nõude, ja sertifikaadi seadmine režiimi Alati usalda muudab sertifikaatide hindamist kõige jaoks masinas. Kumbki ei väljenda „see kinnitatud VPN-i teostus, selle kavandatud identiteediga“.
Kontrollige kohapeal enne lüüsi lugemist
Pärast parandust kinnitage, et kohalik toiming õnnestub, enne kui tõlgendate mis tahes vastust teiselt poolelt. Kui allkirjastamine nüüd töötab, on hilisem nime, ahela või kliendi vastuvõtu tagasilükkamine uus tulemus, mitte kordumine, ja see kuulub teise otsuse juurde teise omanikuga.
Kasulik üleandmine nimetab, milline kolmest otsusest ebaõnnestus, ja lõpeb sellega. See ei sisalda kunagi privaatvõtit ega lähtesta kunagi mitteseotud võtmehoidla üksusi lootuses, et puhas leht aitab. Kujundage need kaks harjumust enne juhtumit, mitte selle ajal, kui kiusatus kõike korraga proovida on kõige tugevam. Pilet, mis ütleb „ehitasime võtmehoidla uuesti üles“, ei ütle järgmisele lugejale algse rikke kohta peaaegu midagi.