Jak OpenVPN řeší certifikát a klíč: vložený PEM, nebo cesta k souboru

Zpráva říká, že OpenVPN nemůže načíst vložený certifikát, a název souboru, který nosíte v hlavě, tvrdí opak. To, co parser dostal, je důležitější než to, co obsahuje souborový systém, protože direktiva cert přijímá dva zcela odlišné druhy hodnoty. Jedním je cesta, kterou otevře; druhým je text PEM, který přišel uvnitř konfigurace. Dokud nevíte, jaký tvar běžící klient dostal, je každá oprava jen odhad.

Dva tvary úložiště, jedna direktiva

Direktivy cert, key a ca přijímají každá cestu nebo vložený blok. Když je hodnotou cesta, OpenVPN tento soubor otevře a objekt přečte z disku. Když konfigurace obsahuje blok ohraničený značkami cert, stejná direktiva místo toho spotřebuje obsah mezi těmito značkami a samostatný soubor se na tom nepodílí.

Oba tvary nakonec vytvoří stejný druh objektu, a proto se funkční nasazení může mezi nimi přesouvat bez jakékoli další změny. Profil, který nese vložený klientský certifikát a soukromý klíč, je soběstačný a zkopírování na jiný stroj funguje i bez kopírování adresáře s certifikáty.

Opak neplatí. Položit client.crt vedle profilu, který vkládá vlastní data, nic nezmění, protože se na tento soubor nic v konfiguraci neodkazuje. To je nejčastější důvod, proč soubor, který zjevně existuje, vypadá jako ignorovaný.

Jak se vložený blok změní na objekt

Vložený obsah se z konfigurace vytáhne a předá parseru PEM jako text. Ten očekává obvyklé hranice: řádek BEGIN, datovou část base64 a odpovídající řádek END. Pokud byl blok zkrácen neúspěšným kopírováním, obalen do HTML stránkou pro stahování nebo otevřen v editoru, který normalizoval pomlčky, parser selže na obsahu, který vypadá přítomně.

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

Proto je také formulace chyby zavádějící. Slovo vložený popisuje, kam se zavaděč podíval, ne co tam našel. Soubor uvedený v konfiguraci a objekt do ní vložený mohou vyvolat stejnou stížnost, když jsou základní bajty nepoužitelné.

Ověřte, který tvar načtený profil skutečně používá, ne který soubor váš editor náhodou otevřel:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

Jak se vyhodnocuje odkaz na cestu

Hodnota cesty se otevírá relativně k pracovnímu adresáři klienta, nikoli k adresáři obsahujícímu konfiguraci. Pod systemd je tímto pracovním adresářem to, co nastaví jednotka, a interaktivní spuštění z vašeho shellu zdědí něco zcela jiného. Proto stejný konfigurační soubor může při ručním testu fungovat a jako služba selhat.

Relativní cesty dědí stejnou nejednoznačnost. Když uvidíte holý název souboru, ptejte se, jaký je aktuální adresář procesu v produkci, místo abyste předpokládali, že odpovídá vašemu terminálu.

U certifikátu uloženého zvlášť potvrdí offline rozbor objekt ještě předtím, než začnete ladit cokoli nad ním:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

Tyto příkazy dokazují, že soubory jsou čitelné a strukturálně platné. Nedokazují, že protistrana důvěřuje vydavateli, že certifikát je stále uvnitř své doby platnosti nebo že k němu klíč patří.

Co vám chyba parseru může a nemůže říct

Selhání rozboru lokalizuje problém na jeden vstup a jednu fázi. Neříká, který ze dvou tvarů úložiště klient použil, ani neříká, zda by byl objekt přijat. To jsou samostatné otázky se samostatnými důkazy.

Jakmile rozbor uspěje, další selhání patří pozdější fázi. Odmítnutí důvěry, nesoulad účelu nebo nesoulad klíče hlásí protistrana nebo vrstva TLS, ne zavaděč. Opakované nahrazení stejného souboru tuto chybu neposune.

Citlivou polovinu držte během vyšetřování mimo veřejné zprávy. Sdílejte názvy direktiv, text chyby a strukturu bloku, s odstraněným klíčovým materiálem a jakoukoli identifikující datovou částí. Příručka openvpn(8) dokumentuje oba tvary souborových direktiv a chování pracovního adresáře, které za nimi stojí.