Jak OpenVPN rozwiązuje certyfikat i klucz: wbudowany PEM czy ścieżka

Komunikat mówi, że OpenVPN nie może wczytać osadzonego certyfikatu, a nazwa pliku, którą masz w głowie, twierdzi co innego. To, co otrzymał parser, ma większe znaczenie niż to, co zawiera system plików, ponieważ dyrektywa cert przyjmuje dwa zupełnie różne rodzaje wartości. Jeden to ścieżka, którą otwiera; drugi to tekst PEM, który przyszedł wewnątrz konfiguracji. Dopóki nie wiesz, jaką formę otrzymał działający klient, każde poprawienie jest domysłem.

Dwie formy przechowywania, jedna dyrektywa

Dyrektywy cert, key i ca przyjmują ścieżkę lub osadzony blok. Gdy wartością jest ścieżka, OpenVPN otwiera ten plik i czyta obiekt z dysku. Gdy konfiguracja zawiera blok ograniczony znacznikami cert, ta sama dyrektywa zużywa zamiast tego zawartość między tymi znacznikami, a żaden osobny plik nie jest zaangażowany.

Obie formy dają ostatecznie ten sam rodzaj obiektu, dlatego działające wdrożenie może przechodzić między nimi bez żadnej innej zmiany. Profil, który nosi osadzony certyfikat klienta i klucz prywatny, jest samowystarczalny, a skopiowanie go na inną maszynę działa bez kopiowania także katalogu certyfikatów.

Odwrotnie nie jest prawdą. Położenie client.crt obok profilu, który osadza własne dane, niczego nie zmienia, ponieważ nic w konfiguracji nie odwołuje się do tego pliku. To najczęstszy powód, dla którego plik, który wyraźnie istnieje, wydaje się ignorowany.

Jak osadzony blok staje się obiektem

Osadzona zawartość jest wyciągana z konfiguracji i przekazywana parserowi PEM jako tekst. Ten parser oczekuje zwykłych granic: wiersza BEGIN, ładunku base64 i pasującego wiersza END. Jeśli blok został ucięty przez nieudane kopiowanie, owinięty w HTML przez stronę pobierania albo otwarty w edytorze, który znormalizował myślniki, parser zawodzi na treści, która wygląda na obecną.

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

Dlatego też sformułowanie błędu jest mylące. Słowo osadzony opisuje, gdzie zajrzał loader, a nie co tam znalazł. Plik nazwany w konfiguracji i obiekt w niej osadzony mogą wywołać tę samą skargę, gdy podstawowe bajty są bezużyteczne.

Sprawdź, której formy faktycznie używa wczytany profil, a nie którego pliku twój edytor przypadkiem otworzył:

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

Jak rozwiązywana jest referencja ścieżki

Wartość ścieżki jest otwierana względem katalogu roboczego klienta, a nie katalogu zawierającego konfigurację. W systemd tym katalogiem roboczym jest to, co ustawia jednostka, a uruchomienie interaktywne z twojej powłoki dziedziczy coś zupełnie innego. Dlatego ten sam plik konfiguracji może działać przy ręcznym teście i zawieść jako usługa.

Ścieżki względne dziedziczą tę samą niejednoznaczność. Gdy widzisz samą nazwę pliku, zapytaj, jaki jest bieżący katalog procesu w produkcji, zamiast zakładać, że odpowiada twojemu terminalowi.

Dla certyfikatu przechowywanego osobno analiza offline potwierdza obiekt, zanim zaczniesz debugować cokolwiek powyżej:

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

Te polecenia dowodzą, że pliki są czytelne i strukturalnie poprawne. Nie dowodzą, że druga strona ufa wystawcy, że certyfikat wciąż mieści się w okresie ważności ani że klucz do niego należy.

Co błąd parsera może, a czego nie może ci powiedzieć

Niepowodzenie parsowania lokalizuje problem w jednym wejściu i jednym etapie. Nie mówi, której z dwóch form przechowywania użył klient, ani czy obiekt zostałby zaakceptowany. To osobne pytania z osobnymi dowodami.

Gdy parsowanie się powiedzie, następne niepowodzenie należy do późniejszego etapu. Odrzucenie zaufania, niezgodność przeznaczenia lub niezgodność klucza zgłasza druga strona albo warstwa TLS, a nie loader. Wielokrotne podmienianie tego samego pliku nie przesunie tego błędu.

Trzymaj wrażliwą połowę poza publicznymi raportami podczas dochodzenia. Udostępniaj nazwy dyrektyw, tekst błędu i strukturę bloku, z usuniętym materiałem klucza i wszelkim ładunkiem identyfikującym. Podręcznik openvpn(8) dokumentuje obie formy dyrektyw plikowych i zachowanie katalogu roboczego, które za nimi stoi.