Prijava na VPN certifikatom na Macu: identitet, upotreba ključa ili povjerenje u pristupnik?

Prijave na VPN certifikatom traže od Maca nešto uže od lozinke: upotrijebi ovaj određeni privatni ključ, u ovom kontekstu izvršavanja, da dokažeš identitet tom pristupniku. Kad ne uspije, poruka obično opisuje samo posljednju stvar koja je pošla po zlu, a ona rijetko je uzrok. Prolaženje kroz tri odluke redom kojim ih sustav donosi održava dijagnozu poštenom i sprječava da se lokalni problem s dopuštenjima tretira kao neuspjeh provjere lanca.

Prođite prijavu redom kojim to čini Mac

Najprije klijent odabire identitet: certifikat uparen s upotrebljivim privatnim ključem, dostupan kroz podržano spremište ili pružatelja vjerodajnica. Zatim VPN komponenta zatraži kriptografsku radnju tim ključem, a lokalni model autorizacije odgovara. Tek nakon što oboje uspije, dogodi se udaljeni handshake, gdje Mac ocjenjuje pristupnik, a pristupnik ocjenjuje klijentov dokaz.

Čitajte tablicu odozgo prema dolje i zaustavite se na prvom retku koji ne uspije. Sve ispod neuspjeha nije dokazano, zato je “certifikat nije pouzdan” tako čest i tako nepouzdan zaključak.

Što lokalno dopuštenje zapravo pokriva

U modelu keychaina na macOS-u zaštićene stavke nose pravila pristupa specifična za radnju i popis pouzdanih aplikacija. Potpisivanje privatnim ključem jedna je od tih radnji, a pravila se primjenjuju na izvršnu datoteku koja je izvodi, ne na certifikat kao dokument. Appleova referenca za kontrolu pristupa također povlači crtu između ovog modela i iCloud keychaina te rasporeda pristupnih grupa, pa se savjet napisan za jedno ne prenosi na drugo.

Slijede dvije posljedice. To što je javni certifikat vidljiv na popisu ne dokazuje da pozadinska komponenta VPN-a uopće može doći do tog ključa. A dopuštenje dano čeonoj aplikaciji ne govori ništa o zasebnom pomoćniku ili mrežnom proširenju, jer je to drugi kod s drugim identitetima.

Utvrdite stvarnu implementaciju i njezin podržani mehanizam dijeljenja vjerodajnica umjesto kopiranja putanje izvršne datoteke iz starog klijenta. Najprije potvrdite koji će identitet sustav uopće ponuditi:

security find-identity -v -p ssl-client

Čitanje errSecInteractionNotAllowed

Taj status izvješćuje o nedopuštenoj interakciji sa Security Serverom i ne govori ništa o lancima certifikata. Čitajte ga zajedno s radnjom koja ga je proizvela: zahtjev za potpisivanje izdan iz konteksta koji ne može prikazati upit propast će na taj način čak i kad su ključ i certifikat savršeno valjani. Radnja koja ga je zabilježila, a ne spremište certifikata, mjesto je od kojeg treba početi. Sve što promijenite oko sidara povjerenja ostavit će pogrešku točno ondje gdje je bila.

Zato kôd shvatite kao razlog za pregled konteksta izvršavanja i autorizacije. Shvaćanje toga kao dokaza da pristupnikov CA nije pouzdan vodi vas u pogrešnu polovicu problema, a promjena koju ondje napravite neće uopće utjecati na pogrešku.

Popravljajte usko, ne široko

Počnite s uputama za upis ili uvoz koje daje vlasnik veze. Zabilježite verziju klijenta, opseg profila, odabrani identitet i prvu relevantnu lokalnu pogrešku, jer ta četiri podatka treba predaja podršci i o njima ovisi kasnija usporedba. Upravljani profil ili identitet potkrijepljen hardverom može zahtijevati da administrator ili pružatelj poprave predaju, i nijedna količina lokalnog klikanja to ne zamjenjuje.

Gdje proizvod očekuje korisničko odobrenje, potvrdite koja komponenta traži i odobrite samo taj pristup kroz podržani tijek. Gdje komponenta nema načina pokrenuti upit u kontekstu u kojem radi, provisioniranje mora slijediti put koji dobavljač dokumentira, a ne dijalog izmamljen iz nekog drugog terminala.

Dvije se promjene u starijim savjetima vežu zajedno, a obje su preširoke. Davanje pristupa privatnom ključu svakoj aplikaciji proširuje lokalnu upotrebu ključa daleko iznad zahtjeva, a postavljanje certifikata na Always Trust mijenja ocjenjivanje certifikata za sve na stroju. Nijedna ne izražava “ova odobrena VPN implementacija, s ovim namjeravanim identitetom”.

Provjerite lokalno prije čitanja pristupnika

Nakon popravka potvrdite da lokalna radnja uspijeva prije nego što protumačite bilo kakav odgovor s druge strane. Ako potpisivanje sada radi, kasnije odbijanje imena, lanca ili klijentskog pristupa nov je rezultat, a ne ponavljanje, i pripada drugoj odluci s drugim vlasnikom.

Korisna predaja imenuje koja od tri odluke nije uspjela i tu staje. Nikada ne uključuje privatni ključ i nikada ne resetira nepovezane stavke keychaina u nadi da će čist početak pomoći. Te dvije navike uspostavite prije incidenta, a ne tijekom njega, kad je napast da se sve isproba odjednom najjača. Kartica koja kaže “ponovno izgrađen keychain” sljedećem čitatelju ne govori gotovo ništa o izvornoj grešci.