Ako OpenVPN rieši certifikát a kľúč: vložený PEM alebo cesta

Správa hovorí, že OpenVPN nedokáže načítať vložený certifikát, a názov súboru, ktorý nosíte v hlave, tvrdí opak. To, čo parser dostal, je dôležitejšie než to, čo obsahuje súborový systém, pretože direktíva cert prijíma dva úplne odlišné druhy hodnoty. Jedným je cesta, ktorú otvorí; druhým je text PEM, ktorý prišiel vnútri konfigurácie. Kým nebudete vedieť, aký tvar bežiaci klient dostal, je každá oprava len odhad.

Dva tvary úložiska, jedna direktíva

Direktívy cert, key a ca prijímajú každá cestu alebo vložený blok. Keď je hodnotou cesta, OpenVPN otvorí ten súbor a prečíta objekt z disku. Keď konfigurácia obsahuje blok ohraničený značkami cert, tá istá direktíva namiesto toho spotrebuje obsah medzi týmito značkami a samostatný súbor sa na tom nezúčastňuje.

Oba tvary nakoniec vytvoria rovnaký druh objektu, preto sa funkčné nasadenie môže medzi nimi presúvať bez akejkoľvek ďalšej zmeny. Profil, ktorý nesie vložený klientsky certifikát a súkromný kľúč, je sebestačný a jeho kopírovanie na iný stroj funguje aj bez kopírovania adresára s certifikátmi.

Opak neplatí. Položenie client.crt vedľa profilu, ktorý vkladá vlastné údaje, nič nemení, pretože sa na tento súbor nič v konfigurácii neodvoláva. To je najčastejší dôvod, prečo súbor, ktorý zjavne existuje, vyzerá ignorovaný.

Ako sa vložený blok zmení na objekt

Vložený obsah sa z konfigurácie vytiahne a odovzdá parseru PEM ako text. Ten očakáva obvyklé hranice: riadok BEGIN, dátovú časť base64 a zodpovedajúci riadok END. Ak bol blok skrátený neúspešným kopírovaním, obalený do HTML stránkou na stiahnutie alebo otvorený v editore, ktorý normalizoval pomlčky, parser zlyhá na obsahu, ktorý vyzerá prítomne.

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

Preto je aj formulácia chyby zavádzajúca. Slovo vložený opisuje, kam sa zavádzač pozrel, nie čo tam našiel. Súbor uvedený v konfigurácii a objekt do nej vložený môžu vyvolať rovnakú sťažnosť, keď sú základné bajty nepoužiteľné.

Overte, ktorý tvar načítaný profil skutočne používa, nie ktorý súbor váš editor náhodou otvoril:

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

Ako sa vyhodnocuje odkaz na cestu

Hodnota cesty sa otvára relatívne k pracovnému adresáru klienta, nie k adresáru obsahujúcemu konfiguráciu. Pod systemd je týmto pracovným adresárom to, čo nastaví jednotka, a interaktívne spustenie z vášho shellu zdedí niečo celkom iné. Preto ten istý konfiguračný súbor môže pri ručnom testovaní fungovať a ako služba zlyhať.

Relatívne cesty dedia rovnakú nejednoznačnosť. Keď uvidíte holý názov súboru, pýtajte sa, aký je aktuálny adresár procesu v produkcii, namiesto toho, aby ste predpokladali, že zodpovedá vášmu terminálu.

Pre certifikát uložený oddelene potvrdí offline rozbor objekt ešte predtým, než začnete čokoľvek nad ním ladiť:

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

Tieto príkazy dokazujú, že súbory sú čitateľné a štrukturálne platné. Nedokazujú, že protistrana dôveruje vydavateľovi, že certifikát je stále v rámci svojej platnosti alebo že k nemu kľúč patrí.

Čo vám chyba parsera môže a nemôže povedať

Zlyhanie rozboru lokalizuje problém na jeden vstup a jednu fázu. Nehovorí, ktorý z dvoch tvarov úložiska klient použil, ani nehovorí, či by bol objekt prijatý. To sú samostatné otázky so samostatnými dôkazmi.

Keď rozbor uspeje, ďalšie zlyhanie patrí neskoršej fáze. Odmietnutie dôvery, nezrovnalosť účelu alebo nezrovnalosť kľúča hlási protistrana alebo vrstva TLS, nie zavádzač. Opakované nahradenie toho istého súboru tú chybu neposunie.

Citlivú polovicu držte počas vyšetrovania mimo verejných správ. Zdieľajte názvy direktív, text chyby a štruktúru bloku s odstráneným kľúčovým materiálom a akoukoľvek identifikujúcou dátovou časťou. Príručka openvpn(8) dokumentuje oba tvary súborových direktív a správanie pracovného adresára, ktoré za nimi stojí.