Kaip OpenVPN išsprendžia sertifikatą ir raktą: įterptasis PEM ar kelias

Pranešimas sako, kad OpenVPN negali įkelti įterptojo sertifikato, o jūsų galvoje įsimintas failo vardas sako priešingai. Tai, ką gavo analizatorius, svarbiau už tai, ką turi failų sistema, nes direktyva cert priima dviejų visiškai skirtingų tipų reikšmes. Viena yra kelias, kurį ji atveria; kita yra PEM tekstas, atėjęs konfigūracijos viduje. Kol nežinote, kokią formą gavo veikiantis klientas, kiekvienas pataisymas yra spėjimas.

Dvi saugojimo formos, viena direktyva

Direktyvos cert, key ir ca priima kelią arba įterptą bloką. Kai reikšmė yra kelias, OpenVPN atveria tą failą ir nuskaito objektą iš disko. Kai konfigūracija turi bloką, apibrėžtą cert žymomis, ta pati direktyva vietoj to naudoja turinį tarp tų žymų, ir joks atskiras failas nedalyvauja.

Abi formos galiausiai sukuria to paties tipo objektą, todėl veikiantis diegimas gali pereiti tarp jų be jokio kito pakeitimo. Profilis, kuris neša įterptą kliento sertifikatą ir privatų raktą, yra savarankiškas, o jo kopijavimas į kitą mašiną veikia ir nenukopijavus sertifikatų katalogo.

Priešingai nėra tiesa. client.crt padėjimas šalia profilio, kuris įterpia savo duomenis, nieko nekeičia, nes niekas konfigūracijoje nenurodo į tą failą. Tai dažniausia priežastis, kodėl aiškiai egzistuojantis failas atrodo ignoruojamas.

Kaip įterptas blokas tampa objektu

Įterptas turinys išimamas iš konfigūracijos ir perduodamas PEM analizatoriui kaip tekstas. Tas analizatorius tikisi įprastų ribų: BEGIN eilutės, base64 turinio ir atitinkamos END eilutės. Jei blokas buvo nukirptas nepavykusio kopijavimo, apgaubtas HTML atsisiuntimo puslapio ar atidarytas redaktoriuje, kuris normalizavo brūkšnelius, analizatorius nepavyksta ties turiniu, kuris atrodo esantis.

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

Štai kodėl klaidos formuluotė klaidina. Žodis įterptas apibūdina, kur žiūrėjo kroviklis, o ne ką ten rado. Faile įvardytas konfigūracijoje ir į ją įterptas objektas gali sukelti tą patį skundą, kai pagrindiniai baitai netinkami naudoti.

Patikrinkite, kurią formą įkeltas profilis iš tikrųjų naudoja, o ne kurį failą atsitiktinai atidarė jūsų redaktorius:

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

Kaip sprendžiama kelio nuoroda

Kelio reikšmė atveriama kliento darbo katalogo atžvilgiu, o ne katalogo, kuriame yra konfigūracija. Sistemoje systemd tas darbo katalogas yra tai, ką nustato unit, o interaktyvus paleidimas iš jūsų apvalkalo paveldi visai ką kita. Todėl tas pats konfigūracijos failas gali veikti tikrinant rankiniu būdu ir nepavykti kaip tarnyba.

Santykiniai keliai paveldi tą patį neapibrėžtumą. Pamatę pliką failo vardą, paklauskite, koks yra proceso dabartinis katalogas produkcijoje, o ne manykite, kad jis atitinka jūsų terminalą.

Atskirai saugomam sertifikatui neprisijungus atlikta analizė patvirtina objektą prieš pradedant derinti ką nors aukščiau:

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

Tos komandos įrodo, kad failai yra skaitomi ir struktūriškai tinkami. Jos neįrodo, kad partneris pasitiki išdavėju, kad sertifikatas vis dar galiojimo laikotarpyje ar kad raktas jam priklauso.

Ką analizatoriaus klaida gali pasakyti, o ko ne

Analizės klaida lokalizuoja problemą į vieną įvestį ir vieną etapą. Ji nepasako, kurią iš dviejų saugojimo formų naudojo klientas, ir nepasako, ar objektas būtų priimtas. Tai atskiri klausimai su atskirais įrodymais.

Kai analizė pavyksta, kita klaida priklauso vėlesniam etapui. Pasitikėjimo atmetimą, paskirties neatitikimą ar rakto neatitikimą praneša partneris arba TLS sluoksnis, o ne kroviklis. To paties failo keitimas pakartotinai tos klaidos nepajudins.

Tyrimo metu jautriąją pusę laikykite už viešų ataskaitų. Dalykitės direktyvų pavadinimais, klaidos tekstu ir bloko struktūra, pašalinę rakto medžiagą ir bet kokį identifikuojantį turinį. openvpn(8) vadove aprašomos abi failo direktyvų formos ir darbo katalogo elgsena, kuri jų laikosi.