Hoe OpenVPN sertifikate en sleutels oplos: inlyn-PEM of lêerpad

Die boodskap sê OpenVPN kan nie 'n inlyn-sertifikaat laai nie, en die lêernaam wat in jou kop vasgevang is, sê die teendeel. Wat die ontleder ontvang het, maak meer saak as wat die lêerstelsel bevat, want die cert-opdrag aanvaar twee heeltemal verskillende soorte waardes. Een is 'n pad wat dit oopmaak; die ander is PEM-teks wat binne die konfigurasie aangekom het. Tot jy weet watter vorm die lopende kliënt gekry het, is elke regstelling 'n raaiskoot.

Twee stoorvorme, een opdrag

Die cert-, key- en ca-opdragte aanvaar elkeen 'n pad of 'n inlyn-blok. Wanneer die waarde 'n pad is, maak OpenVPN daardie lêer oop en lees die voorwerp van die skyf. Wanneer die konfigurasie 'n blok bevat wat deur cert-etikette begrens word, verbruik dieselfde opdrag eerder die inhoud tussen daardie etikette, en geen aparte lêer is betrokke nie.

Albei vorme lewer op die ou end dieselfde soort voorwerp, en daarom kan 'n werkende ontplooiing sonder enige ander verandering tussen hulle wissel. 'n Profiel wat 'n ingebedde kliëntsertifikaat en privaatsleutel dra, is selfstandig, en om dit na 'n ander masjien te kopieer werk sonder om ook 'n sertifikaatgids te kopieer.

Die omgekeerde is nie waar nie. Om client.crt langs 'n profiel te laat val wat sy eie data inbed, verander niks, want niks in die konfigurasie verwys na daardie lêer nie. Dit is die heel algemeenste rede waarom 'n lêer wat duidelik bestaan, geïgnoreer blyk te word.

Hoe 'n inlyn-blok 'n voorwerp word

Inlyn-inhoud word uit die konfigurasie onttrek en as teks aan die PEM-ontleder oorhandig. Daardie ontleder verwag die gewone grense: 'n BEGIN-reël, base64-lading en 'n ooreenstemmende END-reël. As die blok deur 'n mislukte kopie afgekap is, deur 'n aflaai-bladsy in HTML toegedraai is, of in 'n redigeerder oopgemaak is wat die strepies genormaliseer het, faal die ontleder op inhoud wat teenwoordig lyk.

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

Dit is ook waarom die foutbewoording misleidend is. Die woord inlyn beskryf waar die laaier gekyk het, nie wat hy daar gevind het nie. 'n Lêer wat in 'n konfigurasie genoem word en 'n voorwerp wat daarin ingebed is, kan dieselfde klag lewer wanneer die onderliggende grepe onbruikbaar is.

Kontroleer watter vorm die gelaaide profiel werklik gebruik, eerder as watter lêer jou redigeerder toevallig oopgemaak het:

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

Hoe 'n padverwysing opgelos word

'n Padwaarde word relatief tot die kliënt se werkverrigtingsgids oopgemaak, nie tot die gids wat die konfigurasie bevat nie. Onder systemd is daardie werkverrigtingsgids wat die eenheid stel, en 'n interaktiewe loop uit jou skulp erf iets heeltemal anders. Dit is waarom dieselfde konfigurasielêer kan werk wanneer jy dit met die hand toets en as diens misluk.

Relatiewe paaie erf dieselfde onduidelikheid. Wanneer jy 'n kaal lêernaam sien, vra wat die proses se huidige gids in produksie is, eerder as om te aanvaar dat dit met jou terminaal ooreenstem.

Vir 'n sertifikaat wat afsonderlik gestoor word, bevestig 'n aflyn-ontleding die voorwerp voordat jy enigiets hoër op ontfout:

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

Daardie opdragte bewys dat die lêers leesbaar en struktureel geldig is. Hulle bewys nie dat die eweknie die uitreiker vertrou nie, dat die sertifikaat nog binne sy geldigheidsvenster is nie, of dat die sleutel daarby hoort nie.

Wat die ontlederfout jou kan en nie kan sê nie

'n Ontledingsfout lokaliseer die probleem na een inset en een stadium. Dit sê nie vir jou watter van die twee stoorvorme die kliënt gebruik het nie, en dit sê nie of die voorwerp aanvaar sou gewees het nie. Dit is aparte vrae met aparte bewyse.

Sodra die ontleding slaag, behoort die volgende fout aan 'n latere stadium. 'n Vertrouensverwerping, 'n doelwitverskil of 'n sleutelverskil word deur die eweknie of deur die TLS-laag gerapporteer, nie deur die laaier nie. Om dieselfde lêer herhaaldelik te vervang sal daardie fout nie verskuif nie.

Hou die sensitiewe helfte uit openbare verslae terwyl jy ondersoek instel. Deel die opdragname, die foutteks en die struktuur van die blok, met die sleutelmateriaal en enige identifiseerbare lading verwyder. Die openvpn(8)-handleiding dokumenteer albei vorme van die lêeropdragte en die werkverrigtingsgids-gedrag daaragter.