VPN certifikát na Macu: proč výběr identity zůstává prázdný

Nainstalovali jste certifikát, objeví se v Keychain Access s přátelským názvem, a výběr identity v klientu VPN je stále prázdný. Klient nehledá certifikát. Hledá identitu: certifikát spárovaný se soukromým klíčem, který může prokázat držení, uložený tam, kde jej klient smí číst.

Co klient žádá, je identita

Bezpečnostní rámec Apple považuje certifikát a identitu za různé objekty. Certifikát jsou veřejná data. Identita je tento certifikát plus jeho soukromý klíč a pouze identita může dokončit výzvu. Důvěryhodný certifikát CA mezitím klientovi umožňuje vyhodnotit vydavatele; nečiní ze stroje držitele vydaného klientského pověření.

Proto import souboru .cer nikdy nevytvoří použitelnou identitu klienta. Soubor nese pouze veřejný materiál a žádné přejmenování ani důvěra z něj neudělá pár klíčů.

Tři důvody, proč výběr zůstává prázdný

Prvním je chybějící soukromý klíč, což znamená, že jej proces registrace nebo importu nedodal. Druhým je úložiště, které klient neprohledává: profil omezený na uživatele hledá v uživatelově klíčence a položka umístěná v systémovém úložišti pro něj může být neviditelná. Třetím je nesoulad účelu nebo zásad, kdy certifikát existuje, ale není platný pro ověřování klienta podle pravidel nasazení.

security find-identity -v -p ssl-client

Toto vypisuje identity, které systém považuje za platné pro ověřování klienta. Pokud je počet nula, problém je výše než klient VPN a žádná úprava profilu jej neopraví. Pokud se identita objeví zde, ale ne v klientu, rozdíl je v úložišti nebo rozsahu klienta.

Kde žije soukromý klíč a kdo jej smí používat

Když importujete identitu přes Keychain Access, dialog importu nabídne cílovou klíčenku. Které cílové úložiště je správné, závisí na klientovi a na tom, zda je profil omezený na uživatele, nebo na zařízení. Stará odpověď doporučující systémovou klíčenku není univerzální pravidlo a kopírování položek mezi úložišti není oprava.

System Roots je sbírka důvěry. Umístění certifikátu tam mění, kterým vydavatelům systém důvěřuje; nevytváří soukromý klíč a není to úložiště identit. Přesouvání nesouvisejících certifikátů, aby se naplnil výběr, je druh opravy, který stroj ponechá s trvale rozšířenou sadou důvěry.

Přístup k soukromému klíči je samostatná kontrola. Udělení oprávnění každé aplikaci používat klíč řeší problém výběru u jednoho klienta a předává stejnou schopnost všemu ostatnímu na stroji. Udělte je klientovi, který jej potřebuje, a zkontrolujte, zda je klíč hardwarově podporovaný nebo označený jako neexportovatelný; pokud ano, musí se použít podporovaný poskytovatel, nikoli exportovaná kopie.

Jak profil ukazuje na pověření

Ve spravované nativní konfiguraci IKEv2 profil odkazuje na svůj datový obsah pověření přes PayloadCertificateUUID. Důležitá je odkazovaná identita a způsob, jakým byla zřízena; úprava zobrazovaného názvu v profilu neopraví odkaz, který ukazuje na špatný datový obsah nebo na takový, který nikdy nedodal klíč.

Poskytovatel třetí strany může používat zcela jiný mechanismus výběru, například vlastní úložiště nebo systémový dotaz. Čtěte dokumentaci tohoto poskytovatele, místo abyste přenášeli předpoklady o nativním profilu, a ověřte odkaz v profilu, který je skutečně nainstalovaný, nikoli v konceptu v konzoli pro správu.

Výběr a přijetí jsou samostatné milníky

Naplněný výběr znamená, že klient dokáže identitu najít a použít. Nic to neříká o tom, zda ji brána přijme. Server stále kontroluje vydavatele, okno platnosti, stav odvolání a mapování tohoto pověření na účet.

Otestujte obě fáze výslovně, v tomto pořadí. Potvrďte, že se identita nabízí, připojte se a poté nechte vlastníka brány potvrdit, které pověření bylo předloženo a které pravidlo mapování jej spotřebovalo. Pokud klient identitu nabídne a server ji odmítne, zbývající práce je na straně serveru. Přeinstalace certifikátu na Macu tento výsledek nezmění, ať se opakuje jakkoli často.