Který soubor CA patří do profilu OpenVPN jen s heslem?

Projděte čtyři otázky popořadě a dialog CA přestane být nejednoznačný. Jaký materiál operátor vlastně vydal, co profil už obsahuje, které pole se ptá a co se stane po načtení souboru? Zastavte se u první otázky, na kterou nedokážete odpovědět z pokynů samotného operátora, protože hádání za ní je cesta, jak se veřejný certifikát CA ocitne ve dvojici s privátním klíčem, který nikdy neměl opustit server.

Na pořadí záleží: poslední dvě otázky mají smysl jen tehdy, když víte, jaký materiál má existovat.

Začněte tím, co profil už nese

Otevřete profil v textovém editoru a hledejte blok ca dřív, než budete hledat soubor. Vložený blok ca s veřejným CA operátora znamená, že profil je soběstačný, a klient, který přesto žádá soubor CA, možná čte jiný profil nebo neúplný import. Pokud má profil místo toho řádek ca ukazující na cestu, je tato cesta v některých integracích relativní k pracovnímu adresáři klienta a v jiných absolutní. Poznamenejte si, kterou podobu máte, než cokoli změníte.

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Zkontrolujte dodaný balíček na soubory, na které profil odkazuje: certifikát CA, někdy samostatný klientský certifikát a klíč a případně soubor tls-auth nebo tls-crypt. Profil odkazující na čtyři soubory, který dorazí se dvěma, je neúplný a žádné ukazování na pole to nespraví. Požádejte operátora o chybějící část místo toho, abyste dosadili certifikát, který náhodou máte.

Oddělte čtyři druhy materiálu

Certifikát CA je veřejný materiál používaný k ověření identity serveru. Klientský certifikát identifikuje uživatele nebo zařízení vůči serveru. Privátní klíč je tajná polovina tohoto klientského certifikátu a nikdy nesmí být podpisovým klíčem CA ani serverovým klíčem. Materiál tls-auth nebo tls-crypt je samostatné sdílené tajemství, které chrání řídicí kanál. Tyto čtyři nejsou zaměnitelné a nasměrování pole CA na klientský certifikát vyvolá selhání ověření, které vypadá jako problém s důvěrou.

Ověřování pouze heslem mění, který ze čtyř potřebujete, ne co znamenají. S auth-user-pass a remote-cert-tls server klient stále ověřuje server proti CA, a proto se pole CA objevuje i tehdy, když žádný klientský certifikát neexistuje. O tom, zda je klientský certifikát také vyžadován, rozhoduje politika operátora a žádný dialog vám to neřekne.

Namiřte klienta na soubor důvěry

Vyberte samotný soubor certifikátu CA, ne složku, která ho obsahuje, a ne balíček .p12, který nese klientskou identitu. Ve Windows se syntaxe cesty a výběr souboru chovají jinak než linuxové příklady ve většině návodů, proto použijte to, co nainstalovaný klient přijímá, a ověřte, že soubor může číst účet, který ho spouští. Problém s oprávněním a chybějící soubor vypadají v dialogu stejně, ale produkují různé řádky protokolu. Po výběru znovu otevřete nastavení profilu a potvrďte, že klient volbu zachoval.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

Pokud klient podporuje vložené bloky, dejte přednost vloženému profilu operátora před ručně sestaveným. Vložený materiál cestuje s profilem a přežije opětovný import, zatímco absolutní cesta se zlomí ve chvíli, kdy se profil přesune na jiný stroj.

Čtěte další chybu, ne tu samou

Smyslem dodání správného CA je změnit chybu, ne ji nechat zmizet. Selhání identity serveru po načtení CA znamená, že certifikát neodpovídal očekávanému jménu nebo očekávání remote-cert-tls, což je jiná oprava než odmítnutí hesla. Odmítnutí hesla znamená, že vrstva TLS uspěla a přihlašovací údaj je špatný. Ponechte si první novou zprávu; ta je užitečná.

Klient, který se připojí, ale nikam nedosáhne, už zcela přešel důvěru a nyní čelí otázce směrování nebo DNS.

Nikdy nevypínejte ověřování, abyste prošli tímto dialogem. Klient, který přijme jakýkoli certifikát, nemá důvod žádat CA a tunel, který staví, není ten, který operátor zamýšlel.