Hoe OpenVPN het certificaat en de sleutel oplost: inline PEM of pad

Het bericht zegt dat OpenVPN een inline certificaat niet kan laden, en de bestandsnaam in uw hoofd zegt iets anders. Wat de parser ontving is belangrijker dan wat het bestandssysteem bevat, omdat de richtlijn cert twee volledig verschillende soorten waarde accepteert. De ene is een pad dat hij opent; de andere is PEM-tekst die binnen de configuratie is aangekomen. Tot u weet welke vorm de draaiende client heeft gekregen, is elke correctie een gok.

Twee opslagvormen, één richtlijn

De richtlijnen cert, key en ca accepteren elk een pad of een inline blok. Als de waarde een pad is, opent OpenVPN dat bestand en leest het object van de schijf. Als de configuratie een blok bevat dat door cert-tags wordt begrensd, verbruikt dezelfde richtlijn in plaats daarvan de inhoud tussen die tags, en er is geen apart bestand bij betrokken.

Beide vormen leveren uiteindelijk hetzelfde soort object op, daarom kan een werkende uitrol zonder enige andere wijziging tussen beide wisselen. Een profiel dat een ingebed clientcertificaat en een persoonlijke sleutel draagt, is zelfstandig, en het naar een andere machine kopiëren werkt zonder ook een certificaatmap te kopiëren.

Het omgekeerde geldt niet. client.crt naast een profiel leggen dat zijn eigen gegevens inbedt verandert niets, omdat niets in de configuratie naar dat bestand verwijst. Dit is de meest voorkomende reden waarom een bestand dat duidelijk bestaat genegeerd lijkt te worden.

Hoe een inline blok een object wordt

Inline-inhoud wordt uit de configuratie gehaald en als tekst aan de PEM-parser gegeven. Die parser verwacht de gebruikelijke grenzen: een BEGIN-regel, een base64-lading en een bijpassende END-regel. Als het blok door een mislukte kopie is afgekapt, door een downloadpagina in HTML is gewikkeld of is geopend in een editor die de streepjes heeft genormaliseerd, faalt de parser op inhoud die aanwezig lijkt.

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

Daarom is ook de foutformulering misleidend. Het woord inline beschrijft waar de lader keek, niet wat hij daar aantrof. Een bestand dat in een configuratie wordt genoemd en een object dat daarin is ingebed, kunnen dezelfde klacht opleveren wanneer de onderliggende bytes onbruikbaar zijn.

Controleer welke vorm het geladen profiel werkelijk gebruikt, niet welk bestand uw editor toevallig heeft geopend:

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

Hoe een padverwijzing wordt opgelost

Een padwaarde wordt geopend ten opzichte van de werkmap van de client, niet ten opzichte van de map die de configuratie bevat. Onder systemd is die werkmap wat de unit instelt, en een interactieve run vanuit uw shell erft iets heel anders. Daarom kan hetzelfde configuratiebestand werken wanneer u het met de hand test en als dienst falen.

Relatieve paden erven dezelfde dubbelzinnigheid. Wanneer u een kale bestandsnaam ziet, vraag dan wat de huidige map van het proces in productie is in plaats van aan te nemen dat die met uw terminal overeenkomt.

Voor een certificaat dat apart is opgeslagen, bevestigt een offline-analyse het object voordat u iets erboven debugt:

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

Die opdrachten bewijzen dat de bestanden leesbaar en structureel geldig zijn. Ze bewijzen niet dat de tegenpartij de uitgever vertrouwt, dat het certificaat nog binnen zijn geldigheidsvenster valt of dat de sleutel erbij hoort.

Wat de parserfout u wel en niet kan vertellen

Een parsefout lokaliseert het probleem naar één invoer en één fase. Hij vertelt u niet welke van de twee opslagvormen de client gebruikte, en hij vertelt u niet of het object zou zijn geaccepteerd. Dat zijn afzonderlijke vragen met afzonderlijk bewijs.

Zodra het parsen slaagt, hoort de volgende fout bij een latere fase. Een vertrouwensafwijzing, een doelafwijking of een sleutelafwijking wordt gemeld door de tegenpartij of door de TLS-laag, niet door de lader. Hetzelfde bestand telkens vervangen verplaatst die fout niet.

Houd de gevoelige helft tijdens het onderzoek buiten openbare rapporten. Deel de richtlijnnamen, de fouttekst en de structuur van het blok, met het sleutelmateriaal en alle identificerende lading verwijderd. De openvpn(8)-handleiding documenteert beide vormen van de bestandsrichtlijnen en het werkmapgedrag erachter.