Poziv za ključ OpenVPN po OpenSSL 3: preverite ponudnika

Nihče se ni dotaknil profila, pa vendar isti odjemalec zdaj ob vsakem zagonu zahteva geselsko frazo za zasebni ključ. Ko se ta sprememba pojavi v nekaj dneh po nadgradnji distribucije, je verjetni vzrok prav nadgradnja: OpenSSL 3 je preuredil podporo za algoritme in ključ, ki ga je stara knjižnica brala brez težav, lahko postane neberljiv, ne da bi se spremenil en sam bajt. Preverjanja opravite po vrsti, ker sta dva od njih videti enaka, če gledate le na poziv.

Prvo vprašanje je, ali je ključ šifriran, drugo pa, ali ga ta build zna dešifrirati. Spremembe konfiguracije imajo smisel šele, ko sta znana oba odgovora.

Preverite, ali je ključ šifriran

Preberite prvo vrstico datoteke in nato pustite knjižnici, da jo razčleni, ker ime datoteke ničesar ne dokazuje. Blok PEM z oznako ENCRYPTED PRIVATE KEY je šifriran PKCS#8, starejši RSA PRIVATE KEY blok z Proc-Type: 4,ENCRYPTED pa je tradicionalna oblika, in oba pričakujeta geselsko frazo. Nešifriran PRIVATE KEY blok je ne bi smel zahtevati sploh. Razčlenjevanje zaženite pod računom, ki je lastnik datoteke, ker težava z dovoljenji daje drugačno in veliko manj zanimivo napako.

Če ključ res ni šifriran in odjemalec še vedno vprašuje, prenehajte gledati v kriptografijo in preverite, ali profil navaja datoteko askpass, ki jo storitev še lahko prebere.

Preverite, ali ga ta build zna dešifrirati

OpenSSL 3 je podporo za algoritme razdelil na ponudnike in nabor starejših šifer zdaj leži v ponudniku legacy namesto v privzetem. Ključ, šifriran z eno od teh šifer, ostane veljaven, a knjižnica, naložena brez ponudnika legacy, ga ne more dekodirati. Pri nekaterih odjemalcih se to pokaže kot poziv, ki se ponavlja, pri drugih kot trda napaka takoj po geselski frazi.

Razčlenite isti ključ dvakrat z isto binarno datoteko: najprej samo s privzetim ponudnikom, nato z legacy in privzetim, zahtevanima skupaj v ukazni vrstici. Če drugi poskus uspe tam, kjer je prvi spodletel, diagnoza sloni na dokazih in ne na času nadgradnje. Če oba spodletita enako, je geselska fraza napačna ali je datoteka poškodovana, in nobena nastavitev ponudnika ne popravi niti enega.

Preverite najožjo razpoložljivo rešitev

Dajte prednost spremembi, omejeni na odjemalca, pred sistemsko. Nekateri buildi 2.6 sprejmejo možnost v profilu, ki naloži oba ponudnika za proces tega demona, zato pred zanašanjem nanjo preverite direktivo v priročniku za vašo natančno različico; urejanje sistemske openssl.cnf namesto tega prizadene vsak program OpenSSL na gostitelju. Ožja nastavitev je tudi veliko lažje razveljaviti, ko je ključ znova kodiran.

Ne izbrišite geselske fraze, da bi poziv izginil. S tem zaščiteno poverilnico spremenite v datoteko z golim besedilom in tiho spremenite tveganje vsake varnostne kopije, kopije in paketa za podporo, v katerem se pojavi. Pomembna razlika je med ključem, ki potrebuje svojo geselsko frazo, in ključem, ki ga ta knjižnica ne more dekodirati.

Preverite kontekst storitve in nato znova kodirajte

Ko je ključ mogoče odkleniti, ga znova šifrirajte s sodobnim algoritmom da odvisnost izgine. Novo datoteko zapišite s sodobno šifro, preverite, da se razčleni, posodobite profil in staro kopijo hranite le do uspešne povezave. Geselske fraze nikoli ne postavljajte v ukazno vrstico, kjer jo lahko vsak lokalni uporabnik prebere s seznama procesov. Staro datoteko odstranite šele potem, ko se nova poveže iz storitvenega računa, ne le iz vaše lupine.

Nato preverite enoto, ki odjemalca dejansko poganja. Ključ, berljiv v vaši lupini, je lahko neberljiv za storitev, ki teče pod drugim računom ali s utrjeno nastavitvijo domače mape.

Nastavitev ponudnika zapišite ob profil in pri njej hranite preizkus z dvema ukazoma. Ko poznejša nadgradnja odstrani ponudnika legacy, ta preizkus zaženite znova in poglejte, ali ključ še potrebuje njega ali je profil mogoče umakniti iz te začasne rešitve.

Poziv je simptom z vsaj tremi vzroki in le eden od njih je manjkajoča geselska fraza.