Prompt ng susi ng OpenVPN pagkatapos ng OpenSSL 3: suriin ang provider

Walang gumalaw sa profile, ngunit ang parehong kliyente ay humihingi na ngayon ng passphrase para sa pribadong susi sa bawat pagsisimula. Kapag nangyari ang pagbabagong iyon sa loob ng ilang araw pagkatapos ng upgrade ng distribution, ang upgrade ang malamang na dahilan: inayos muli ng OpenSSL 3 ang suporta nito sa algorithm, at ang susi na dating binabasa nang maayos ng lumang library ay maaaring maging hindi mabasa nang walang binagong kahit isang byte. Gawin ang mga pagsusuri nang sunud-sunod, dahil ang dalawa sa mga ito ay magkapareho kung titingnan lamang ang prompt.

Ang unang tanong ay kung naka-encrypt ang susi, at ang pangalawa ay kung kayang i-decrypt ito ng build na ito. May saysay lamang ang mga pagbabago sa configuration kapag alam na ang dalawang sagot.

Suriin kung naka-encrypt ang susi

Basahin ang unang linya ng file at pagkatapos ay hayaang i-parse ito ng library, dahil walang pinatutunayan ang pangalan ng file. Ang PEM block na may label na ENCRYPTED PRIVATE KEY ay naka-encrypt na PKCS#8, at ang mas lumang RSA PRIVATE KEY block na may Proc-Type: 4,ENCRYPTED ay ang tradisyonal na anyo, at pareho silang umaasa ng passphrase. Ang PRIVATE KEY block na hindi naka-encrypt ay hindi dapat humingi nito kahit minsan. Patakbuhin ang pag-parse gamit ang account na may-ari ng file, dahil ang problema sa permiso ay nagbibigay ng ibang at mas kaunting kawili-wiling error.

Kung talagang hindi naka-encrypt ang susi at nagtatanong pa rin ang kliyente, itigil ang pagtingin sa cryptography at suriin kung may binabanggit na askpass file ang profile na nababasa pa ng serbisyo.

Suriin kung kayang i-decrypt ito ng build na ito

Hinati ng OpenSSL 3 ang suporta nito sa algorithm sa mga provider, at ang isang set ng mas lumang cipher ay nasa legacy provider na ngayon kaysa sa default. Nananatiling wasto ang susi na naka-encrypt gamit ang isa sa mga cipher na iyon, ngunit ang library na na-load nang walang legacy provider ay hindi ito ma-decode. Sa ilang kliyente ito ay lumilitaw bilang paulit-ulit na prompt, sa iba bilang matigas na pagpalya kaagad pagkatapos ng passphrase.

I-parse ang parehong susi nang dalawang beses gamit ang parehong binary: una gamit lamang ang default provider, pagkatapos ay hilingin ang legacy at default sa command line. Kung magtagumpay ang ikalawang pagtatangka kung saan nabigo ang una, ang diagnosis ay nakabatay sa ebidensya at hindi sa oras ng upgrade. Kung parehong nabigo sa parehong paraan, mali ang passphrase o sira ang file, at walang setting ng provider ang makakaayos sa alinman.

Suriin ang pinakamakitid na available na pagbabago

Mas piliin ang pagbabagong nakapaloob sa kliyente kaysa sa buong sistema. Ang ilang build 2.6 ay tumatanggap ng opsyon sa profile na naglo-load ng dalawang provider para sa proseso ng daemon na iyon, kaya tiyakin ang direktiba sa manwal para sa inyong eksaktong bersyon bago umasa dito; ang pag-edit ng openssl.cnf ng system sa halip ay nakakaapekto sa bawat programang OpenSSL sa host. Ang mas makitid na setting ay mas madaling ibalik kapag na-re-encode na ang susi.

Huwag tanggalin ang passphrase para mawala ang prompt. Ginagawa nitong plaintext file ang isang protektadong kredensyal at tahimik na binabago ang panganib ng bawat backup, kopya at support bundle kung saan ito lumilitaw. Ang mahalagang pagkakaiba ay sa pagitan ng susi na kailangan ang passphrase nito at susi na hindi kayang i-decode ng library na ito.

Suriin ang konteksto ng serbisyo, pagkatapos ay i-re-encode

Kapag na-unlock na ang susi, i-encrypt itong muli gamit ang kasalukuyang algorithm upang mawala ang dependency. Isulat ang bagong file gamit ang modernong cipher, tiyakin na nagpa-parse ito, i-update ang profile, at itago ang lumang kopya hanggang sa magtagumpay ang isang koneksyon. Huwag kailanman ilagay ang passphrase sa command line, kung saan mababasa ito ng sinumang lokal na user mula sa listahan ng proseso. Alisin ang lumang file pagkatapos lamang na kumonekta ang bago mula sa service account, hindi lamang mula sa inyong shell.

Pagkatapos ay suriin ang unit na aktwal na nagpapatakbo ng kliyente. Ang susi na nababasa sa inyong shell ay maaaring hindi mabasa ng serbisyong tumatakbo sa ilalim ng ibang account o may pinalakas na setting ng home directory.

Itala ang setting ng provider sa tabi ng profile at itago ang dalawang-command na pagsubok kasama nito. Kapag tinanggal ng susunod na upgrade ang legacy provider, patakbuhin muli ang pagsubok na iyon upang makita kung kailangan pa ito ng susi o kung maaaring alisin ang profile mula sa pansamantalang solusyon.

Ang prompt ay isang sintomas na may hindi bababa sa tatlong dahilan, at isa lamang sa mga ito ang nawawalang passphrase.