Přihlášení k VPN certifikátem na Macu: identita, použití klíče, nebo důvěra k bráně?
Za přihlášením certifikátem stojí tři rozhodnutí: která identita se vybere, zda smí komponenta VPN použít svůj klíč a zda se bráně důvěřuje.
Přihlášení k VPN založená na certifikátech žádají od Macu něco užšího než heslo: použít tento konkrétní soukromý klíč v tomto kontextu spuštění k prokázání identity té bráně. Když selže, zpráva obvykle popisuje jen poslední, co se pokazilo, což je zřídka příčina. Procházení tří rozhodnutí v pořadí, v jakém je systém činí, udržuje diagnózu poctivou a brání tomu, aby se místní problém s oprávněními považoval za selhání ověření řetězce.
Projděte přihlášení v pořadí, v jakém ho provádí Mac
Nejprve klient vybere identitu: certifikát spárovaný s použitelným soukromým klíčem, dostupný přes podporované úložiště nebo poskytovatele pověření. Potom komponenta VPN požádá o kryptografickou operaci s tímto klíčem a místní model autorizace odpoví. Teprve když obojí uspěje, dojde ke vzdálenému handshake, kde Mac vyhodnotí bránu a brána vyhodnotí důkaz klienta.
| 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 |
Čtěte tabulku shora dolů a zastavte se u prvního řádku, který selže. Vše pod selháním je neprokázané, a proto je „certifikát není důvěryhodný“ tak častý a tak nespolehlivý závěr.
Co místní oprávnění skutečně pokrývá
V modelu klíčenky macOS nesou chráněné položky pravidla přístupu specifická pro operaci a seznam důvěryhodných aplikací. Podepisování soukromým klíčem je jednou z těchto operací a pravidla se vztahují na spustitelný soubor, který ji provádí, nikoli na certifikát jako dokument. Referenční příručka Apple pro řízení přístupu také vytyčuje hranici mezi tímto modelem a klíčenkou iCloud a uspořádáními přístupových skupin, takže rada napsaná pro jedno se nepřenáší na druhé.
Z toho plynou dva důsledky. Viditelnost veřejného certifikátu v seznamu nedokazuje, že se na pozadí běžící komponenta VPN ke klíči vůbec dostane. A oprávnění udělené front-endové aplikaci neříká nic o samostatném pomocníkovi nebo síťovém rozšíření, protože jde o jiný kód s jinými identitami.
Určete skutečnou implementaci a její podporovaný mechanismus sdílení pověření, místo abyste kopírovali cestu ke spustitelnému souboru ze starého klienta. Potvrďte, kterou identitu systém vůbec nabídne:
security find-identity -v -p ssl-clientČtení kódu errSecInteractionNotAllowed
Tento stav hlásí zakázanou interakci se serverem zabezpečení a o řetězcích certifikátů neříká nic. Čtěte jej společně s operací, která jej vyvolala: žádost o podpis vydaná z kontextu, který nemůže zobrazit výzvu, selže právě tak, i když jsou klíč i certifikát zcela platné. Místem, kde začít, je operace, která to zaznamenala, ne úložiště certifikátů. Jakákoli změna důvěryhodných kotev ponechá chybu přesně tam, kde byla.
Berte tedy kód jako důvod prozkoumat kontext spuštění a autorizaci. Pokud jej berete jako důkaz, že CA brány není důvěryhodná, pošlete se na špatnou polovinu problému a změna, kterou tam provedete, chybu vůbec neovlivní.
Opravujte úzce, ne široce
Začněte s pokyny vlastníka připojení k registraci nebo importu. Zaznamenejte verzi klienta, rozsah profilu, vybranou identitu a první relevantní místní chybu, protože tyto čtyři skutečnosti potřebuje předání podpoře a na nich závisí pozdější srovnání. Spravovaný profil nebo identita podložená hardwarem může vyžadovat, aby předání opravil správce nebo poskytovatel, a sebevíc místního klikání to nenahradí.
Tam, kde produkt očekává schválení uživatele, potvrďte, která komponenta o ně žádá, a schvalte pouze tento přístup podporovaným postupem. Tam, kde komponenta nemůže v kontextu, ve kterém běží, vyvolat výzvu, musí zřizování jít cestou, kterou dodavatel dokumentuje, ne dialogem vylákaným z jiného terminálového okna.
Ve starších radách se dva kroky sdružují a oba jsou příliš široké. Udělení přístupu ke klíči každé aplikaci rozšiřuje místní použití klíče daleko za požadavek a nastavení certifikátu na „Vždy důvěryhodný“ mění vyhodnocování certifikátů pro vše na počítači. Ani jedno nevyjadřuje „tato schválená implementace VPN s touto zamýšlenou identitou“.
Ověřte to místně, než začnete číst bránu
Po opravě potvrďte, že místní operace uspěje, než začnete interpretovat jakoukoli odpověď z druhé strany. Pokud podepisování nyní funguje, pozdější odmítnutí podle jména, řetězce nebo vpuštění klienta je nový výsledek, nikoli opakování, a patří k jinému rozhodnutí s jiným vlastníkem.
Užitečné předání pojmenuje, které ze tří rozhodnutí selhalo, a tam skončí. Nikdy neobsahuje soukromý klíč a nikdy neresetuje nesouvisející položky klíčenky v naději, že čistý štít pomůže. Zažijte tyto dva návyky před incidentem, ne během něj, kdy je pokušení vyzkoušet všechno najednou nejsilnější. Tiket, který říká „znovu jsme postavili klíčenku“, neřekne dalšímu čtenáři o původní závadě téměř nic.