Prijava v VPN s potrdilom na Macu: identiteta, uporaba ključa ali zaupanje v prehod?
Za prijavo s potrdilom stojijo tri odločitve: katera identiteta je izbrana, ali sme komponenta VPN uporabiti svoj ključ in ali je prehodu zaupati.
Prijave v VPN, ki temeljijo na potrdilu, od Maca zahtevajo nekaj ožjega od gesla: uporabi ta določeni zasebni ključ, v tem kontekstu izvajanja, da dokažeš identiteto temu prehodu. Ko spodleti, sporočilo običajno opiše le zadnjo stvar, ki je šla narobe, in ta je le redko vzrok. Prehod skozi tri odločitve v vrstnem redu, v katerem jih sprejema sistem, ohranja diagnozo pošteno in preprečuje, da bi lokalno težavo z dovoljenji obravnavali kot neuspeh preverjanja verige.
Pojdi skozi prijavo v vrstnem redu, v katerem to stori Mac
Najprej odjemalec izbere identiteto: potrdilo, seznanjeno z uporabnim zasebnim ključem, na voljo prek podprte shrambe ali ponudnika poverilnic. Nato komponenta VPN zahteva kriptografsko operacijo s tem ključem, in lokalni model avtorizacije odgovori. Šele ko oba uspeta, se zgodi rokovanje na daljavo, kjer Mac oceni prehod, prehod pa oceni dokaz odjemalca.
| 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 |
Preberi tabelo od zgoraj navzdol in ustavi se pri prvi vrstici, ki spodleti. Vse pod neuspehom je nedokazano, zato je »potrdilu se ne zaupa« tako pogost in tako nezanesljiv sklep.
Kaj lokalno dovoljenje v resnici pokriva
V modelu zbirke ključev macOS imajo zaščiteni predmeti pravila dostopa, specifična za operacijo, in seznam zaupanja vrednih aplikacij. Podpisovanje z zasebnim ključem je ena od teh operacij, pravila pa veljajo za izvršljivo datoteko, ki to izvaja, ne za potrdilo kot dokument. Applov priročnik o nadzoru dostopa potegne tudi črto med tem modelom ter zbirko ključev iCloud in ureditvami dostopnih skupin, zato se nasvet, napisan za eno, ne prenese na drugo.
Sledita dve posledici. Javno potrdilo, vidno na seznamu, ne dokazuje, da lahko ozadnja komponenta VPN sploh doseže ta ključ. In dovoljenje, dano čelni aplikaciji, ne pove ničesar o ločenem pomočniku ali omrežni razširitvi, ker gre za drugo kodo z drugimi identitetami.
Ugotovi dejansko izvedbo in njen podprti mehanizem za souporabo poverilnic, namesto da bi kopiral pot do izvršljive datoteke iz starega odjemalca. Najprej potrdi, katero identiteto bo sistem sploh ponudil:
security find-identity -v -p ssl-clientKako brati errSecInteractionNotAllowed
To stanje poroča o nedovoljeni interakciji s Security Server in ne pove ničesar o verigah potrdil. Beri ga skupaj z operacijo, ki ga je povzročila: zahteva za podpis, izdana iz konteksta, ki ne more prikazati poziva, bo spodletela na ta način, tudi kadar sta ključ in potrdilo povsem veljavna. Začeti je treba pri operaciji, ki ga je zabeležila, ne pri shrambi potrdil. Karkoli spremeniš pri sidrih zaupanja, bo napako pustilo točno tam, kjer je bila.
Zato kodo obravnavaj kot razlog za pregled konteksta izvajanja in avtorizacije. Če jo imaš za dokaz, da CA prehoda ni zaupanja vreden, te pošlje v napačno polovico težave, in sprememba, ki jo tam narediš, na napako sploh ne bo vplivala.
Popravi ozko, ne široko
Začni z navodili za vpis ali uvoz, ki jih da lastnik povezave. Zabeleži različico odjemalca, obseg profila, izbrano identiteto in prvo pomembno lokalno napako, ker te štiri dejstva potrebuje predaja podpori in od njih je odvisna poznejša primerjava. Upravljani profil ali identiteta s strojno podporo lahko zahteva, da skrbnik ali ponudnik popravi predajo, in nobena količina lokalnih klikov tega ne nadomesti.
Kjer izdelek pričakuje uporabnikovo odobritev, preveri, katera komponenta jo zahteva, in odobri samo ta dostop po podprtem toku. Kjer komponenta v kontekstu, v katerem teče, ne more sprožiti poziva, mora priprava slediti poti, ki jo dokumentira dobavitelj, in ne pogovornemu oknu, izvlečenemu iz drugega terminala.
V starejših nasvetih sta dve spremembi povezani in obe sta preširoki. Če vsaki aplikaciji daš dostop do zasebnega ključa, se lokalna uporaba ključa razširi daleč prek zahteve, nastavitev potrdila na Always Trust pa spremeni vrednotenje potrdil za vse na stroju. Nobena ne izraža »ta odobrena izvedba VPN, ki uporablja to predvideno identiteto«.
Preveri lokalno, preden prebereš prehod
Po popravilu potrdi, da lokalna operacija uspe preden razlagaš katerikoli odgovor z druge strani. Če podpisovanje zdaj deluje, je poznejša zavrnitev imena, verige ali sprejema odjemalca nov rezultat in ne ponovitev, in pripada drugi odločitvi z drugim odgovornim.
Koristna predaja poimenuje, katera od treh odločitev je spodletela, in se tam ustavi. Nikoli ne vključuje zasebnega ključa in nikoli ne ponastavi nepovezanih predmetov zbirke ključev v upanju, da bo čist začetek pomagal. Ti dve navadi uvedi pred incidentom in ne med njim, ko je skušnjava, da bi poskusil vse hkrati, najmočnejša. Zahtevek z besedami »zbirka ključev znova zgrajena« naslednjemu bralcu skoraj ničesar ne pove o prvotni okvari.