Proč cryptoapicert v OpenVPN 3 a Connect na Windows nefunguje

Zkopírujete funkční profil OpenVPN 2 do novějšího klienta pro Windows, a certifikát, který starý klient nacházel sám, už není nabízen. Řádek, který to umožňoval, je selektor specifický pro Windows patřící klientu Community 2, a novější aplikace je jiný program s jinou cestou k přihlašovacím údajům. Profil se nezměnil kromě tohoto jediného řádku, a právě proto je rozdíl těžko vidět.

V té zprávě se směšují tři vrstvy: klient Community, základní knihovna a frontend, který někdo nainstaloval. Direktivu kdy rozuměla jen jedna z nich.

Co volba znamená tam, kde existuje

V klientu Community OpenVPN 2 na Windows cryptoapicert označuje certifikát, který má klient najít v úložišti certifikátů Windows, nikoli v souboru. Je to pohodlnost specifická pro Windows a funguje, protože tento klient umí úložiště vyjmenovat a výsledný klíč předat svému vlastnímu zásobníku TLS. Direktiva je tedy součástí konfiguračního jazyka tohoto klienta, ne vlastností protokolu OpenVPN. Nic v přenosovém formátu ji nenese.

Zkopírujte stejný řádek do jiné aplikace a zkopírovali jste slovo, které nový program může analyzovat, ignorovat nebo odmítnout. Direktiva není vlastností protokolu a tato není dokonce ani vlastností každého klienta, který mluví OpenVPN.

Co místo toho nabízí základní knihovna

OpenVPN 3 Core je knihovna, kterou jiné aplikace vkládají, a externí přihlašovací údaje zpracovává přes API, nikoli vyhledáním v úložišti. Vkládající aplikace dodá řetězec certifikátů a později požádá knihovnu, aby podepsala externím klíčem, a knihovna kvůli tomu volá zpět do aplikace. To je obecnější návrh a znamená, že frontend rozhoduje, kteří poskytovatelé existují. Ve vlastním zpracování voleb knihovny se cryptoapicert objevuje mezi direktivami, které nejsou implementované, což odpovídá tomuto rozdělení odpovědnosti.

Existence těchto zpětných volání neznamená, že daná zabalená aplikace vyjmenuje osobní úložiště aktuálního uživatele, podporuje určitého poskytovatele klíčů nebo dokáže dokončit výzvu čipové karty. To jsou vlastnosti frontendu a každou z nich musí frontend zdokumentovat.

Co místo toho dělá frontend pro Windows

OpenVPN Connect jde jinou cestou: operátor importuje soubor PKCS#12 obsahující certifikát a jeho soukromý klíč do OpenVPN Certificate Store vytvořeného pro tento účel a potom přiřadí externí certifikát profilu. Je to záměrný krok importu, ne automatické objevování toho, co náhodou leží v osobním úložišti. Rozdíl je důležitý, když někdo předpokládá, že certifikát nainstalovaný pro jiný účel se prostě objeví v seznamu klienta.

Import má důsledek i pro politiku klíčů, protože export klíče do souboru P12 je přesně to, čemu má neexportovatelný klíč zabránit. To je otázka politiky, ne konfigurace, a zaslouží si odpověď dřív, než se někdo o import pokusí.

Zvolte cestu, která odpovídá politice klíče

Pokud jsou přihlašovací údaje exportovatelné a politika povoluje zdokumentovaný import, použijte chráněný proces registrace organizace a udržujte dočasný P12 a jeho heslo mimo protokoly a skripty. Pokud klíč nikdy nesmí opustit čipovou kartu nebo chráněného poskytovatele, zvolte kombinaci klienta a poskytovatele, která tento požadavek výslovně podporuje, nebo si vyžádejte potvrzení od dodavatele pro verzi, kterou jste nainstalovali. Ani jedna větev není náhradou za druhou.

Vrácení direktivy do profilu nemůže poskytnout integraci, kterou aplikace nemá. Ani novější verze klienta ji nutně nepřidá, protože schopnost patří k vlastnímu návrhu frontendu.

Jakmile místní klíč funguje, server stále kontroluje identitu certifikátu, řetězec a autorizaci. Použitelný místní klíč a přijatá identita VPN jsou oddělené výsledky a právě jejich oddělování brání tomu, aby se omezení frontendu změnilo v oslabenou politiku certifikátů.