Hvordan OpenVPN løser opp sertifikatet og nøkkelen: innebygd PEM eller sti

Meldingen sier at OpenVPN ikke kan laste inn et innebygd sertifikat, og filnavnet du har i hodet sier noe annet. Det parseren mottok betyr mer enn det filsystemet inneholder, fordi direktivet cert godtar to helt forskjellige slags verdier. Den ene er en sti den åpner; den andre er PEM-tekst som kom inn i konfigurasjonen. Inntil du vet hvilken form den kjørende klienten fikk, er hver rettelse en gjetning.

To lagringsformer, ett direktiv

Direktivene cert, key og ca godtar hver en sti eller en innebygd blokk. Når verdien er en sti, åpner OpenVPN filen og leser objektet fra disken. Når konfigurasjonen inneholder en blokk avgrenset av cert-tagger, bruker det samme direktivet i stedet innholdet mellom disse taggene, og ingen separat fil er involvert.

Begge formene gir til slutt samme slags objekt, derfor kan en fungerende utrulling bytte mellom dem uten noen annen endring. En profil som bærer et innebygd klientsertifikat og en privat nøkkel, er selvstendig, og det å kopiere den til en annen maskin virker uten også å kopiere en sertifikatmappe.

Det motsatte er ikke sant. Å legge client.crt ved siden av en profil som bygger inn egne data endrer ingenting, fordi ingenting i konfigurasjonen viser til den filen. Dette er den vanligste grunnen til at en fil som tydelig finnes ser ut til å bli ignorert.

Hvordan en innebygd blokk blir et objekt

Innebygd innhold trekkes ut av konfigurasjonen og gis til PEM-parseren som tekst. Den parseren forventer de vanlige grensene: en BEGIN-linje, en base64-nyttelast og en samsvarende END-linje. Hvis blokken ble kuttet av en mislykket kopi, pakket inn i HTML av en nedlastingsside eller åpnet i en editor som normaliserte bindestrekene, feiler parseren på innhold som ser ut til å være til stede.

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

Det er også derfor feilformuleringen er misvisende. Ordet innebygd beskriver hvor innlasteren så, ikke hva den fant der. En fil som er navngitt i en konfigurasjon, og et objekt som er bygget inn i den, kan gi samme klage når de underliggende bytene er ubrukelige.

Kontroller hvilken form den innlastede profilen faktisk bruker, ikke hvilken fil editoren din tilfeldigvis åpnet:

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

Hvordan en stireferanse løses opp

En stiverdi åpnes relativt til klientens arbeidskatalog, ikke til katalogen som inneholder konfigurasjonen. Under systemd er den arbeidskatalogen det enheten setter, og en interaktiv kjøring fra skallet ditt arver noe helt annet. Derfor kan den samme konfigurasjonsfilen virke når du tester den for hånd og feile som tjeneste.

Relative stier arver den samme tvetydigheten. Når du ser et bart filnavn, spør hva prosessens gjeldende katalog er i produksjon i stedet for å anta at den samsvarer med terminalen din.

For et sertifikat som lagres separat, bekrefter en frakoblet parsing objektet før du feilsøker noe over det:

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

Disse kommandoene beviser at filene er lesbare og strukturelt gyldige. De beviser ikke at motparten stoler på utstederen, at sertifikatet fortsatt er innenfor gyldighetsvinduet, eller at nøkkelen hører til det.

Hva parserfeilen kan og ikke kan fortelle deg

En parsefeil lokaliserer problemet til én inndata og ett trinn. Den forteller deg ikke hvilken av de to lagringsformene klienten brukte, og den forteller deg ikke om objektet ville blitt godtatt. Det er separate spørsmål med separate bevis.

Når parsingen lykkes, hører neste feil til et senere trinn. En tillitsavvisning, et formålsavvik eller et nøkkelavvik rapporteres av motparten eller av TLS-laget, ikke av innlasteren. Å bytte ut den samme filen gjentatte ganger flytter ikke den feilen.

Hold den følsomme halvdelen unna offentlige rapporter mens du undersøker. Del direktivnavnene, feilteksten og strukturen i blokken, med nøkkelmaterialet og enhver identifiserende nyttelast fjernet. openvpn(8)-håndboken dokumenterer begge formene for fildirektivene og arbeidskatalogoppførselen bak dem.