Az üzenet szerint a OpenVPN nem tud betölteni egy beágyazott tanúsítványt, pedig a fejében őrzött fájlnév mást mond. Az számít inkább, amit a parser kapott, nem az, amit a fájlrendszer tartalmaz, mert a cert utasítás két teljesen különböző értéktípust fogad el. Az egyik egy útvonal, amelyet megnyit; a másik a konfiguráción belül érkező PEM-szöveg. Amíg nem tudja, milyen formát kapott a futó kliens, minden javítás csak találgatás.

Két tárolási forma, egy utasítás

A cert, key és ca utasítások mindegyike egy útvonalat vagy egy beágyazott blokkot fogad el. Ha az érték útvonal, az OpenVPN megnyitja azt a fájlt, és beolvassa az objektumot a lemezről. Ha a konfiguráció cert-címkékkel határolt blokkot tartalmaz, ugyanaz az utasítás inkább a címkék közötti tartalmat használja fel, és külön fájl nem vesz részt benne.

Mindkét forma végül ugyanolyan típusú objektumot állít elő, ezért egy működő telepítés minden más változtatás nélkül válthat közöttük. Az a profil, amely beágyazott kliens-tanúsítványt és privát kulcsot hordoz, önálló, és más gépre másolása a tanúsítványkönyvtár másolása nélkül is működik.

A fordítottja nem igaz. Ha client.crt fájlt teszünk egy olyan profil mellé, amely a saját adatait ágyazza be, semmi sem változik, mert a konfigurációban semmi sem hivatkozik arra a fájlra. Ez a leggyakoribb oka annak, hogy egy nyilvánvalóan létező fájl figyelmen kívül hagyottnak tűnik.

Hogyan lesz a beágyazott blokkból objektum

A beágyazott tartalmat a konfigurációból kinyerik, és szövegként átadják a PEM-parsernek. Az a parser a szokásos határokat várja: egy BEGIN sort, base64 hasznos terhet és egy megfelelő END sort. Ha a blokkot egy sikertelen másolás levágta, egy letöltőoldal HTML-be csomagolta, vagy olyan szerkesztőben nyitották meg, amely normalizálta a kötőjeleket, a parser olyan tartalmon bukik el, amely jelenlévőnek látszik.

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

Ezért is félrevezető a hiba megfogalmazása. A beágyazott szó azt írja le, hova nézett a betöltő, nem azt, hogy mit talált ott. Egy konfigurációban megnevezett fájl és a bele ágyazott objektum ugyanazt a panaszt válthatja ki, ha a mögöttes bájtok használhatatlanok.

Ellenőrizze, melyik formát használja valójában a betöltött profil, ne azt, hogy a szerkesztője véletlenül melyik fájlt nyitotta meg:

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

Hogyan oldódik fel egy útvonalhivatkozás

Az útvonalérték a kliens munkakönyvtárához viszonyítva nyílik meg, nem a konfigurációt tartalmazó könyvtárhoz viszonyítva. systemd alatt ez a munkakönyvtár az, amit az egység beállít, a héjból indított interaktív futás pedig valami egészen mást örököl. Ezért ugyanaz a konfigurációs fájl működhet kézi teszteléskor, és bukhat el szolgáltatásként.

A relatív útvonalak ugyanezt a kétértelműséget öröklik. Ha csupasz fájlnevet lát, kérdezze meg, mi a folyamat aktuális könyvtára az éles környezetben, ahelyett hogy feltételezné, hogy megegyezik a termináljával.

Egy külön tárolt tanúsítvány esetében az offline elemzés megerősíti az objektumot, mielőtt bármit is hibakeresne fölötte:

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

Ezek a parancsok bizonyítják, hogy a fájlok olvashatók és szerkezetileg érvényesek. Azt nem bizonyítják, hogy a partner megbízik a kiállítóban, hogy a tanúsítvány még az érvényességi ablakán belül van, vagy hogy a kulcs hozzá tartozik.

Mit mondhat el a parserhiba és mit nem

Egy elemzési hiba egyetlen bemenetre és egyetlen szakaszra szűkíti a problémát. Nem mondja meg, melyik tárolási formát használta a kliens, és azt sem, hogy az objektumot elfogadták volna-e. Ezek külön kérdések, külön bizonyítékokkal.

Ha az elemzés sikerül, a következő hiba egy későbbi szakaszhoz tartozik. A bizalmi elutasítást, a cél eltérését vagy a kulcs eltérését a partner vagy a TLS-réteg jelenti, nem a betöltő. Ugyanazon fájl ismételt cseréje nem mozdítja el ezt a hibát.

Tartsa a bizalmas felét a nyilvános jelentéseken kívül a vizsgálat alatt. Ossza meg az utasítások nevét, a hiba szövegét és a blokk szerkezetét, a kulcsanyag és minden azonosító hasznos teher eltávolításával. Az openvpn(8) kézikönyv dokumentálja a fájlutasítások mindkét formáját és a mögöttük álló munkakönyvtár-viselkedést.

Kapcsolódó cikkek