OpenSSL 3 પછી OpenVPN કી પ્રોમ્પ્ટ: પ્રદાતા ચકાસો

કોઈએ પ્રોફાઇલને અડ્યું નથી, તોપણ એ જ ક્લાયન્ટ હવે દર વખતે શરૂ થાય ત્યારે ખાનગી કી માટે પાસફ્રેઝ માંગે છે. જ્યારે આ ફેરફાર ડિસ્ટ્રિબ્યુશન અપગ્રેડનાં થોડા દિવસોમાં આવે છે, ત્યારે અપગ્રેડ સંભવિત કારણ છે: OpenSSL 3એ તેનો અલ્ગોરિધમ સપોર્ટ ફરી ગોઠવ્યો, અને જૂની લાઇબ્રેરી સહેલાઈથી વાંચતી કી એક પણ બાઇટ બદલ્યા વિના અવાંચ્ય બની શકે છે. તપાસો ક્રમમાં કરો, કારણ કે ફક્ત પ્રોમ્પ્ટ જોઈને તેમાંથી બે સરખા લાગે છે.

પહેલો પ્રશ્ન છે કે કી એન્ક્રિપ્ટ થયેલી છે કે નહીં, અને બીજો છે કે આ બિલ્ડ તેને ડિક્રિપ્ટ કરી શકે છે કે નહીં. બંને જવાબ જાણ્યા પછી જ કન્ફિગરેશન ફેરફારોનો અર્થ છે.

કી એન્ક્રિપ્ટ થયેલી છે કે નહીં તે ચકાસો

ફાઇલની પહેલી લાઇન વાંચો અને પછી લાઇબ્રેરીને તેને પાર્સ કરવા દો, કારણ કે ફાઇલનું નામ કંઈ પુરવાર કરતું નથી. જે PEM બ્લોક પર ENCRYPTED PRIVATE KEY લેબલ છે તે એન્ક્રિપ્ટેડ PKCS#8 છે, અને જૂનો RSA PRIVATE KEY બ્લોક જેમાં Proc-Type: 4,ENCRYPTED છે તે પરંપરાગત સ્વરૂપ છે, અને બંને પાસફ્રેઝની અપેક્ષા રાખે છે. એન્ક્રિપ્ટ ન કરેલો PRIVATE KEY બ્લોક તો બિલકુલ માંગવો જ ન જોઈએ. પાર્સિંગ એ એકાઉન્ટ તરીકે ચલાવો જે ફાઇલનો માલિક છે, કારણ કે પરમિશનની સમસ્યા અલગ અને ઘણી ઓછી રસપ્રદ ભૂલ આપે છે.

જો કી ખરેખર એન્ક્રિપ્ટ ન કરેલી હોય અને ક્લાયન્ટ તોપણ પૂછે, તો ક્રિપ્ટોગ્રાફી તરફ જોવાનું બંધ કરો અને ચકાસો કે પ્રોફાઇલ એવી askpass ફાઇલનું નામ આપે છે કે જે સેવા હજી વાંચી શકે.

આ બિલ્ડ તેને ડિક્રિપ્ટ કરી શકે છે કે નહીં તે ચકાસો

OpenSSL 3એ તેનો અલ્ગોરિધમ સપોર્ટ પ્રદાતાઓમાં વિભાજિત કર્યો, અને જૂની સાઇફરોનો સમૂહ હવે ડિફોલ્ટ પ્રદાતાને બદલે legacy પ્રદાતામાં બેસે છે. તેમાંની એક સાઇફરથી એન્ક્રિપ્ટ થયેલી કી માન્ય રહે છે, પણ legacy પ્રદાતા વિના લોડ થયેલી લાઇબ્રેરી તેને ડિકોડ કરી શકતી નથી. કેટલાક ક્લાયન્ટમાં તે પુનરાવર્તિત પ્રોમ્પ્ટ તરીકે દેખાય છે, અન્યમાં પાસફ્રેઝની તરત પછી કઠોર નિષ્ફળતા તરીકે.

એ જ કીને એ જ બાઇનરીથી બે વાર પાર્સ કરો: પહેલા ફક્ત ડિફોલ્ટ પ્રદાતા સાથે, પછી કમાન્ડ લાઇન પર legacy અને ડિફોલ્ટ બંને માંગીને. જો બીજો પ્રયાસ ત્યાં સફળ થાય જ્યાં પહેલો નિષ્ફળ ગયો, તો નિદાન પુરાવા પર આધાર રાખે છે, અપગ્રેડના સમય પર નહીં. જો બંને એકસરખા રીતે નિષ્ફળ જાય, તો પાસફ્રેઝ ખોટો છે અથવા ફાઇલ બગડેલી છે, અને કોઈ પ્રદાતા સેટિંગ બેમાંથી એકેય સુધારતું નથી.

ઉપલબ્ધ સૌથી સાંકડો ઉપાય ચકાસો

સિસ્ટમ-વ્યાપી બદલાવ કરતાં ક્લાયન્ટ સુધી મર્યાદિત બદલાવને પ્રાધાન્ય આપો. કેટલાક 2.6 બિલ્ડ એવો પ્રોફાઇલ વિકલ્પ સ્વીકારે છે જે તે ડેમન પ્રોસેસ માટે બંને પ્રદાતા લોડ કરે છે, તેથી તેના પર આધાર રાખતાં પહેલાં તમારી ચોક્કસ આવૃત્તિના મેન્યુઅલમાં તે સૂચના ચકાસો; તેના બદલે સિસ્ટમની openssl.cnf સંપાદિત કરવાથી હોસ્ટ પરના દરેક OpenSSL પ્રોગ્રામ પર અસર થાય છે. સાંકડું સેટિંગ કી ફરી એન્કોડ થયા પછી પાછું વાળવા માટે પણ ઘણું સહેલું છે.

પ્રોમ્પ્ટ દૂર કરવા માટે પાસફ્રેઝ કાઢી ન નાખો. તે સુરક્ષિત ઓળખપત્રને સાદા ટેક્સ્ટની ફાઇલમાં ફેરવે છે અને જેમાં તે દેખાય તે દરેક બેકઅપ, નકલ અને સપોર્ટ બંડલનું જોખમ ચૂપચાપ બદલે છે. મહત્વનો ભેદ એ છે કે એક કીને તેના પાસફ્રેઝની જરૂર છે અને બીજી કીને આ લાઇબ્રેરી ડિકોડ કરી શકતી નથી.

સેવાનો સંદર્ભ ચકાસો, પછી ફરી એન્કોડ કરો

એક વાર કી ખોલી શકાય, તો તેને આધુનિક અલ્ગોરિધમથી ફરી એન્ક્રિપ્ટ કરો જેથી નિર્ભરતા અદૃશ્ય થાય. નવી ફાઇલ આધુનિક સાઇફરથી લખો, તે પાર્સ થાય છે તે ચકાસો, પ્રોફાઇલ અપડેટ કરો, અને જૂની નકલ ફક્ત ત્યાં સુધી રાખો જ્યાં સુધી કનેક્શન સફળ ન થાય. પાસફ્રેઝ ક્યારેય કમાન્ડ લાઇન પર ન મૂકો, જ્યાં કોઈ પણ સ્થાનિક વપરાશકર્તા પ્રોસેસ સૂચિમાંથી તેને વાંચી શકે. જૂની ફાઇલ ફક્ત ત્યારે જ દૂર કરો જ્યારે નવી સેવા એકાઉન્ટમાંથી જોડાઈ ગઈ હોય, ફક્ત તમારા શેલમાંથી નહીં.

પછી જે યુનિટ ખરેખર ક્લાયન્ટ ચલાવે છે તે ચકાસો. તમારા શેલમાં વાંચી શકાય તેવી કી બીજા એકાઉન્ટ હેઠળ અથવા કડક હોમ ડિરેક્ટરી સેટિંગ સાથે ચાલતી સેવા માટે અવાંચ્ય હોઈ શકે છે.

પ્રોફાઇલની બાજુમાં પ્રદાતા સેટિંગ નોંધો અને બે-કમાન્ડની કસોટી સાથે રાખો. જ્યારે પછીનું અપગ્રેડ legacy પ્રદાતા દૂર કરે, ત્યારે તે કસોટી ફરી ચલાવો જેથી દેખાય કે કીને હજી તેની જરૂર છે કે પ્રોફાઇલને આ કામચલાઉ ઉપાયમાંથી બહાર કાઢી શકાય.

પ્રોમ્પ્ટ એ ઓછામાં ઓછા ત્રણ કારણો ધરાવતું લક્ષણ છે, અને તેમાંથી ફક્ત એક જ ખૂટતો પાસફ્રેઝ છે.