Výzva na zadanie kľúča OpenVPN po OpenSSL 3: skontrolujte poskytovateľa

Nikto sa profilu nedotkol, a predsa ten istý klient teraz pri každom spustení žiada heslo k súkromnému kľúču. Keď sa táto zmena objaví do niekoľkých dní po aktualizácii distribúcie, pravdepodobnou príčinou je práve aktualizácia: OpenSSL 3 preusporiadal podporu algoritmov a kľúč, ktorý stará knižnica čítala bez problémov, môže byť nečitateľný bez zmeny jediného bajtu. Vykonajte kontroly v poradí, pretože dve z nich vyzerajú rovnako, ak sa pozeráte len na výzvu.

Prvá otázka je, či je kľúč zašifrovaný, a druhá, či ho tento build dokáže dešifrovať. Zmeny konfigurácie majú zmysel až vtedy, keď sú známe obe odpovede.

Skontrolujte, či je kľúč zašifrovaný

Prečítajte prvý riadok súboru a potom nechajte knižnicu, aby ho spracovala, pretože názov súboru nič nedokazuje. Blok PEM s označením ENCRYPTED PRIVATE KEY je zašifrovaný PKCS#8 a starší RSA PRIVATE KEY blok nesúci Proc-Type: 4,ENCRYPTED je tradičná forma, a oba očakávajú heslo. Nezašifrovaný PRIVATE KEY blok by ho nemal žiadať vôbec. Spustite spracovanie pod účtom, ktorý súbor vlastní, pretože problém s oprávneniami dáva inú a oveľa menej zaujímavú chybu.

Ak je kľúč naozaj nezašifrovaný a klient sa stále pýta, prestaňte sa pozerať na kryptografiu a skontrolujte, či profil neuvádza súbor askpass, ktorý služba ešte dokáže prečítať.

Skontrolujte, či ho tento build dokáže dešifrovať

OpenSSL 3 rozdelil podporu algoritmov na poskytovateľov a sada starších šifier teraz sídli v legacy poskytovateľovi, nie v predvolenom. Kľúč zašifrovaný jednou z týchto šifier zostáva platný, no knižnica načítaná bez legacy poskytovateľa ho nedokáže dekódovať. U niektorých klientov sa to prejaví ako výzva, ktorá sa opakuje, u iných ako tvrdé zlyhanie hneď po zadaní hesla.

Spracujte ten istý kľúč dvakrát tým istým binárnym súborom: najprv len s predvoleným poskytovateľom, potom s legacy aj predvoleným požadovanými na príkazovom riadku. Ak druhý pokus uspeje tam, kde prvý zlyhal, diagnóza stojí na dôkazoch, nie na čase aktualizácie. Ak oba zlyhajú rovnako, heslo je nesprávne alebo je súbor poškodený, a žiadne nastavenie poskytovateľa neopraví ani jedno.

Skontrolujte najužšiu dostupnú opravu

Uprednostnite zmenu obmedzenú na klienta pred systémovou. Niektoré buildy 2.6 prijímajú voľbu profilu, ktorá pre proces daného démona načíta oboch poskytovateľov, preto si direktívu pred spoliehaním sa na ňu overte v manuáli pre vašu presnú verziu; úprava systémového openssl.cnf namiesto toho ovplyvní každý program OpenSSL na hostiteľovi. Užšie nastavenie sa tiež oveľa ľahšie vracia späť, keď je kľúč znovu zakódovaný.

Nemažte heslo len preto, aby výzva zmizla. Zmeníte tým chránený údaj na súbor v otvorenom texte a potichu zmeníte riziko každej zálohy, kópie a diagnostického balíka, v ktorom sa objaví. Rozdiel, na ktorom záleží, je medzi kľúčom, ktorý svoje heslo potrebuje, a kľúčom, ktorý táto knižnica nedokáže dekódovať.

Skontrolujte kontext služby a potom znova zakódujte

Keď sa kľúč dá odomknúť, zašifrujte ho znova aktuálnym algoritmom aby závislosť zmizla. Zapíšte nový súbor modernou šifrou, overte, že sa spracuje, aktualizujte profil a starú kópiu držte len do prvého úspešného pripojenia. Nikdy nedávajte heslo na príkazový riadok, kde ho každý lokálny používateľ môže prečítať zo zoznamu procesov. Starý súbor odstráňte až po tom, čo sa nový pripojí z účtu služby, nie len z vášho shellu.

Potom skontrolujte jednotku, ktorá klienta skutočne spúšťa. Kľúč čitateľný vo vašom shelli môže byť nečitateľný pre službu bežiacu pod iným účtom alebo so spevneným nastavením domovského adresára.

Zaznamenajte nastavenie poskytovateľa vedľa profilu a majte pri ňom aj test s dvoma príkazmi. Keď neskoršia aktualizácia odstráni legacy poskytovateľa, spustite ten test znova a zistite, či kľúč ešte potrebuje jeho, alebo či sa profil dá vyradiť z tohto obchádzkového riešenia.

Výzva je príznak s najmenej tromi príčinami a len jedna z nich je chýbajúce heslo.