VPN pieteikšanās ar sertifikātu Mac datorā: identitāte, atslēgas lietojums vai vārtejas uzticēšanās?
Aiz pieteikšanās ar sertifikātu slēpjas trīs lēmumi: kura identitāte tiek izvēlēta, vai VPN komponente drīkst lietot savu atslēgu un vai vārtejai uzticas.
VPN pieteikšanās ar sertifikātu lūdz Mac datoram kaut ko šaurāku par paroli: lietot šo konkrēto privāto atslēgu, šajā izpildes kontekstā, lai pierādītu identitāti tai vārtejai. Kad tas neizdodas, ziņojums parasti apraksta tikai pēdējo lietu, kas nogāja greizi, un tā reti ir cēlonis. Trīs lēmumu izstaigāšana tādā secībā, kādā tos pieņem sistēma, saglabā diagnozi godīgu un neļauj lokālu atļauju problēmu uztvert kā ķēdes validācijas kļūmi.
Izstaigājiet pieteikšanos tādā secībā, kādā to dara Mac
Vispirms klients izvēlas identitāti: sertifikāts, kas sapārots ar lietojamu privāto atslēgu, pieejams caur atbalstīto krātuvi vai akreditācijas datu nodrošinātāju. Pēc tam VPN komponente pieprasa veikt kriptogrāfisku darbību ar šo atslēgu, un lokālais autorizācijas modelis atbild. Tikai pēc tam, kad abas izdodas, notiek attālinātā roku saspiešana, kurā Mac novērtē vārteju, bet vārteja novērtē klienta pierādījumu.
| 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 |
Lasiet tabulu no augšas uz leju un apstājieties pie pirmās neizdevušās rindas. Viss zem neizdošanās nav pierādīts, tāpēc „sertifikātam neuzticas“ ir tik izplatīts un tik neuzticams secinājums.
Ko lokālā atļauja patiešām aptver
macOS atslēgu saišķa modelī aizsargātie vienumi nes sev līdzi darbībai raksturīgus piekļuves noteikumus un uzticamu lietotņu sarakstu. Parakstīšana ar privāto atslēgu ir viena no šādām darbībām, un noteikumi attiecas uz izpildāmo failu, kas to veic, nevis uz sertifikātu kā dokumentu. Apple piekļuves kontroles uzziņa arī novelk robežu starp šo modeli un iCloud atslēgu saišķi un piekļuves grupu kārtību, tāpēc vienam rakstīts padoms nepārnesas uz otru.
No tā izriet divas sekas. Tas, ka publiskais sertifikāts ir redzams sarakstā, nepierāda, ka VPN fona komponente vispār var sasniegt šo atslēgu. Un priekšgala lietotnei piešķirtā atļauja neko nepasaka par atsevišķu palīgu vai tīkla paplašinājumu, jo tie ir cits kods ar citām identitātēm.
Nosakiet faktisko ieviešanu un tās atbalstīto akreditācijas datu koplietošanas mehānismu, nevis kopējiet izpildāmā faila ceļu no veca klienta. Vispirms apstipriniet, kādu identitāti sistēma vispār piedāvās:
security find-identity -v -p ssl-clientKā lasīt errSecInteractionNotAllowed
Šis statuss ziņo par neatļautu mijiedarbību ar Security Server un neko nepasaka par sertifikātu ķēdēm. Lasiet to kopā ar darbību, kas to radīja: parakstīšanas pieprasījums, kas izsūtīts no konteksta, kurš nevar parādīt dialogu, neizdosies tieši tāpat, arī tad, ja atslēga un sertifikāts abi ir pilnīgi derīgi. Sākt jāsāk ar darbību, kas to reģistrēja, nevis ar sertifikātu krātuvi. Jebkuras izmaiņas uzticēšanās enkuros atstās kļūdu tieši tur, kur tā bija.
Tāpēc uztveriet kodu kā iemeslu pārbaudīt izpildes kontekstu un autorizāciju. Uztverot to kā pierādījumu, ka vārtejas CA nav uzticama, jūs nonākat problēmas nepareizajā pusē, un tur veiktās izmaiņas kļūdu neietekmēs vispār.
Labojiet šauri, nevis plaši
Sāciet ar savienojuma īpašnieka reģistrācijas vai importēšanas norādēm. Pierakstiet klienta versiju, profila apjomu, izvēlēto identitāti un pirmo būtisko lokālo kļūdu, jo tieši šie četri fakti ir vajadzīgi nodošanai atbalstam un no tiem atkarīgs vēlāks salīdzinājums. Pārvaldīts profils vai aparatūras atbalstīta identitāte var prasīt, lai administrators vai pakalpojumu sniedzējs salabotu nodošanu, un neviens lokālu klikšķu daudzums to neaizstāj.
Kur produkts gaida lietotāja apstiprinājumu, pārbaudiet, kura komponente to prasa, un apstipriniet tikai šo piekļuvi atbalstītajā plūsmā. Kur komponentei nav iespējas izcelt dialogu tajā kontekstā, kurā tā darbojas, nodrošināšanai jāiet pa ražotāja dokumentēto ceļu, nevis pa dialogu, kas izvilkts no cita termināļa loga.
Vecākos padomos divas izmaiņas tiek piedāvātas kopā, un abas ir pārāk plašas. Ja katrai lietotnei piešķir piekļuvi privātajai atslēgai, lokālais atslēgas lietojums paplašinās krietni pāri prasībai, un sertifikāta iestatīšana uz Always Trust maina sertifikātu novērtēšanu visam datorā. Neviena no tām neizsaka „šī apstiprinātā VPN ieviešana, izmantojot šo paredzēto identitāti“.
Pārbaudiet lokāli, pirms lasāt vārteju
Pēc labojuma apstipriniet, ka lokālā darbība izdodas pirms interpretējat jebkādu atbildi no otras puses. Ja parakstīšana tagad strādā, vēlāka nosaukuma, ķēdes vai klienta uzņemšanas noraidīšana ir jauns rezultāts, nevis atkārtošanās, un tā pieder citam lēmumam ar citu atbildīgo.
Noderīga nodošana nosauc, kurš no trim lēmumiem neizdevās, un tur apstājas. Tā nekad neietver privāto atslēgu un nekad neatjauno nesaistītus atslēgu saišķa vienumus cerībā, ka tīrs sākums palīdzēs. Šos divus ieradumus nosakiet pirms incidenta, nevis tā laikā, kad kārdinājums izmēģināt visu uzreiz ir visspēcīgākais. Biļete ar uzrakstu „atslēgu saišķis pārbūvēts“ nākamajam lasītājam par sākotnējo defektu nepasaka gandrīz neko.