Hur OpenVPN löser certifikatet och nyckeln: inbäddad PEM eller sökväg

Meddelandet säger att OpenVPN inte kan läsa in ett inbäddat certifikat, och filnamnet du har i huvudet säger något annat. Det parsern tog emot betyder mer än det filsystemet innehåller, eftersom direktivet cert tar emot två helt olika slags värden. Den ena är en sökväg som den öppnar; den andra är PEM-text som kom in i konfigurationen. Tills du vet vilken form den körande klienten fick är varje rättelse en gissning.

Två lagringsformer, ett direktiv

Direktiven cert, key och ca tar var och en emot en sökväg eller ett inbäddat block. När värdet är en sökväg öppnar OpenVPN filen och läser objektet från disken. När konfigurationen innehåller ett block som avgränsas av cert-taggar förbrukar samma direktiv i stället innehållet mellan dessa taggar, och ingen separat fil är inblandad.

Båda formerna ger till slut samma sorts objekt, därför kan en fungerande installation växla mellan dem utan någon annan ändring. En profil som bär ett inbäddat klientcertifikat och en privat nyckel är självständig, och att kopiera den till en annan maskin fungerar utan att också kopiera en certifikatmapp.

Det omvända gäller inte. Att lägga client.crt bredvid en profil som bäddar in sina egna data ändrar ingenting, eftersom ingenting i konfigurationen hänvisar till den filen. Det är den vanligaste orsaken till att en fil som uppenbart finns verkar ignoreras.

Hur ett inbäddat block blir ett objekt

Inbäddat innehåll extraheras från konfigurationen och lämnas till PEM-parsern som text. Den parsern förväntar sig de vanliga gränserna: en BEGIN-rad, en base64-last och en matchande END-rad. Om blocket kapades av en misslyckad kopiering, lindades in i HTML av en nedladdningssida eller öppnades i en redigerare som normaliserade bindestrecken, misslyckas parsern på innehåll som ser ut att finnas.

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

Det är också därför felformuleringen är missvisande. Ordet inbäddad beskriver var laddaren tittade, inte vad den hittade där. En fil som nämns i en konfiguration och ett objekt som bäddats in i den kan ge samma klagomål när de underliggande byten är oanvändbara.

Kontrollera vilken form den inlästa profilen faktiskt använder, inte vilken fil din redigerare råkade öppna:

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

Hur en sökvägsreferens löses

Ett sökvägsvärde öppnas relativt klientens arbetskatalog, inte katalogen som innehåller konfigurationen. Under systemd är den arbetskatalogen det som enheten ställer in, och en interaktiv körning från ditt skal ärver något helt annat. Därför kan samma konfigurationsfil fungera när du testar den för hand och misslyckas som tjänst.

Relativa sökvägar ärver samma tvetydighet. När du ser ett bart filnamn, fråga vad processens aktuella katalog är i produktion i stället för att anta att den matchar din terminal.

För ett certifikat som lagras separat bekräftar en offlinetolkning objektet innan du felsöker något ovanför det:

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

De kommandona bevisar att filerna är läsbara och strukturellt giltiga. De bevisar inte att motparten litar på utfärdaren, att certifikatet fortfarande ligger inom sin giltighetstid eller att nyckeln hör till det.

Vad parserfelet kan och inte kan berätta

Ett tolkfel lokaliserar problemet till en indata och ett steg. Det berättar inte vilken av de två lagringsformerna klienten använde, och det berättar inte om objektet skulle ha accepterats. Det är separata frågor med separata bevis.

När tolkningen lyckas hör nästa fel till ett senare steg. En avvisad tillit, en avvikelse i syfte eller en avvikelse i nyckel rapporteras av motparten eller av TLS-lagret, inte av laddaren. Att byta ut samma fil upprepade gånger flyttar inte det felet.

Håll den känsliga hälften utanför offentliga rapporter medan du undersöker. Dela direktivnamnen, feltexten och blockets struktur, med nyckelmaterialet och all identifierande last borttagen. openvpn(8)-handboken dokumenterar båda formerna av fildirektiven och arbetskatalogbeteendet bakom dem.