Sådan afgør OpenVPN certifikat og nøgle: inline PEM eller filsti

Beskeden siger, at OpenVPN ikke kan indlæse et inline-certifikat, og filnavnet, du har i hovedet, siger noget andet. Det, parseren modtog, betyder mere end det, filsystemet indeholder, fordi cert-direktivet accepterer to helt forskellige slags værdier. Den ene er en sti, den åbner; den anden er PEM-tekst, der ankom inde i konfigurationen. Indtil du ved, hvilken form den kørende klient fik, er hver rettelse et gæt.

To opbevaringsformer, ét direktiv

cert-, key- og ca-direktiverne accepterer hver en sti eller en inline-blok. Når værdien er en sti, åbner OpenVPN filen og læser objektet fra disken. Når konfigurationen indeholder en blok afgrænset af cert-tags, bruger det samme direktiv i stedet indholdet mellem disse tags, og der er ingen separat fil involveret.

Begge former giver til sidst samme slags objekt, og derfor kan en fungerende udrulning skifte mellem dem uden nogen anden ændring. En profil, der bærer et indlejret klientcertifikat og en privat nøgle, er selvbærende, og det virker at kopiere den til en anden maskine uden også at kopiere en certifikatmappe.

Det omvendte gælder ikke. At lægge client.crt ved siden af en profil, der indlejrer sine egne data, ændrer intet, fordi intet i konfigurationen henviser til den fil. Det er den allerhyppigste grund til, at en fil, der tydeligt findes, ser ud til at blive ignoreret.

Sådan bliver en inline-blok til et objekt

Indholdet i en inline-blok trækkes ud af konfigurationen og gives til PEM-parseren som tekst. Den parser forventer de sædvanlige grænser: en BEGIN-linje, en base64-nyttelast og en matchende END-linje. Hvis blokken blev klippet af en mislykket kopiering, pakket ind i HTML af en downloadside eller åbnet i en editor, der normaliserede bindestregerne, fejler parseren på indhold, der ser ud til at være til stede.

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

Det er også derfor fejlformuleringen er misvisende. Ordet inline beskriver, hvor indlæseren kiggede, ikke hvad den fandt der. En fil, der er nævnt i en konfiguration, og et objekt, der er indlejret i den, kan give samme klage, når de underliggende bytes er ubrugelige.

Kontrollér, hvilken form den indlæste profil faktisk bruger, i stedet for hvilken fil din editor tilfældigvis åbnede:

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

Sådan opløses en stireference

En stiværdi åbnes relativt til klientens arbejdsmappe, ikke til mappen, der indeholder konfigurationen. Under systemd er den arbejdsmappe, hvad unit'en sætter, og en interaktiv kørsel fra din shell arver noget helt andet. Derfor kan den samme konfigurationsfil virke, når du tester den manuelt, og fejle som tjeneste.

Relative stier arver den samme tvetydighed. Når du ser et bart filnavn, så spørg, hvad processens aktuelle mappe er i produktion, i stedet for at antage, at den svarer til din terminal.

For et certifikat, der opbevares separat, bekræfter en offline parsing objektet, før du fejlretter noget over det:

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

De kommandoer beviser, at filerne er læsbare og strukturelt gyldige. De beviser ikke, at modparten stoler på udstederen, at certifikatet stadig er inden for sin gyldighedsperiode, eller at nøglen hører til det.

Hvad parserfejlen kan og ikke kan fortælle dig

En parsefejl lokaliserer problemet til ét input og ét trin. Den fortæller dig ikke, hvilken af de to opbevaringsformer klienten brugte, og den fortæller dig ikke, om objektet ville være blevet accepteret. Det er separate spørgsmål med separate beviser.

Når parsingen lykkes, hører den næste fejl til et senere trin. En tillidsafvisning, et formålsafvigelse eller en nøgleafvigelse rapporteres af modparten eller af TLS-laget, ikke af indlæseren. At udskifte den samme fil gentagne gange flytter ikke den fejl.

Hold den følsomme halvdel ude af offentlige rapporter, mens du undersøger. Del direktivnavnene, fejlteksten og blokkens struktur, med nøglematerialet og enhver identificerende nyttelast fjernet. openvpn(8)-manualen dokumenterer begge former for fildirektiverne og arbejdsmappeadfærden bag dem.