Solicitarea cheii OpenVPN după OpenSSL 3: verificați furnizorul

Nimeni nu a atins profilul, totuși același client cere acum o frază de acces pentru cheia privată la fiecare pornire. Când această schimbare apare la câteva zile după un upgrade al distribuției, upgrade-ul este cauza probabilă: OpenSSL 3 și-a reorganizat suportul pentru algoritmi, iar o cheie pe care biblioteca veche o citea fără probleme poate deveni ilizibilă fără ca măcar un byte să se schimbe. Faceți verificările în ordine, pentru că două dintre ele arată identic dacă priviți doar solicitarea.

Prima întrebare este dacă cheia este criptată, iar a doua este dacă această compilare o poate decripta. Modificările de configurație au sens doar după ce ambele răspunsuri sunt cunoscute.

Verificați dacă cheia este criptată

Citiți prima linie a fișierului și apoi lăsați biblioteca să o analizeze, pentru că un nume de fișier nu dovedește nimic. Un bloc PEM cu eticheta ENCRYPTED PRIVATE KEY este PKCS#8 criptat, iar un bloc RSA PRIVATE KEY mai vechi care poartă Proc-Type: 4,ENCRYPTED este forma tradițională, și ambele așteaptă o frază de acces. Un bloc PRIVATE KEY necriptat nu ar trebui să ceară una deloc. Rulați analiza cu contul care deține fișierul, pentru că o problemă de permisiuni produce o eroare diferită și mult mai puțin interesantă.

Dacă cheia chiar nu este criptată, iar clientul întreabă în continuare, opriți-vă din privit criptografia și verificați dacă profilul numește un fișier askpass pe care serviciul îl mai poate citi.

Verificați dacă această compilare o poate decripta

OpenSSL 3 a împărțit suportul pentru algoritmi în furnizori, iar un set de cifruri mai vechi se află acum în furnizorul legacy, nu în cel implicit. O cheie criptată cu unul dintre acele cifruri rămâne validă, însă o bibliotecă încărcată fără furnizorul legacy nu o poate decodifica. La unii clienți acest lucru apare ca o solicitare care se repetă, la alții ca o eșuare dură imediat după fraza de acces.

Analizați aceeași cheie de două ori cu același binar: mai întâi doar cu furnizorul implicit, apoi cu legacy și implicit cerute amândouă pe linia de comandă. Dacă a doua încercare reușește acolo unde prima a eșuat, diagnosticul se bazează pe dovezi, nu pe momentul upgrade-ului. Dacă amândouă eșuează identic, fraza de acces este greșită sau fișierul este deteriorat, iar nicio setare de furnizor nu le repară pe niciuna.

Verificați cea mai îngustă soluție disponibilă

Preferați o modificare limitată la client în locul uneia la nivel de sistem. Unele compilări 2.6 acceptă o opțiune de profil care încarcă ambii furnizori pentru procesul acelui daemon, așa că verificați directiva în manualul pentru versiunea dumneavoastră exactă înainte de a vă baza pe ea; editarea openssl.cnf de sistem afectează în schimb fiecare program OpenSSL de pe gazdă. Setarea mai îngustă este și mult mai ușor de anulat după ce cheia este recodificată.

Nu ștergeți fraza de acces ca să dispară solicitarea. Asta transformă o acreditare protejată într-un fișier text simplu și schimbă în tăcere riscul fiecărei copii de rezervă, copii și pachet de suport în care apare. Distincția care contează este între o cheie care are nevoie de fraza ei de acces și o cheie pe care această bibliotecă nu o poate decodifica.

Verificați contextul serviciului, apoi recodificați

Odată ce cheia poate fi deblocată, criptați-o din nou cu un algoritm actual astfel încât dependența să dispară. Scrieți fișierul nou cu un cifru modern, verificați că se analizează, actualizați profilul și păstrați copia veche doar până când o conexiune reușește. Nu puneți niciodată fraza de acces pe o linie de comandă, unde orice utilizator local o poate citi din lista de procese. Ștergeți fișierul vechi doar după ce cel nou s-a conectat din contul de serviciu, nu doar din shell-ul dumneavoastră.

Apoi verificați unitatea care rulează efectiv clientul. O cheie lizibilă în shell-ul dumneavoastră poate fi ilizibilă pentru un serviciu care rulează sub alt cont sau cu o setare întărită a directorului home.

Notați setarea furnizorului lângă profil și păstrați testul cu două comenzi împreună cu el. Când un upgrade ulterior elimină furnizorul legacy, rulați din nou acel test pentru a vedea dacă cheia mai are nevoie de el sau dacă profilul poate fi scos din soluția ocolitoare.

O solicitare este un simptom cu cel puțin trei cauze, iar doar una dintre ele este o frază de acces lipsă.