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 ദാതാവിനെ നീക്കിയാൽ, ആ പരിശോധന വീണ്ടും പ്രവർത്തിപ്പിച്ച് കീയ്ക്ക് ഇപ്പോഴും അത് വേണോ അല്ലെങ്കിൽ ഈ താൽക്കാലിക പരിഹാരത്തിൽ നിന്ന് പ്രൊഫൈൽ ഒഴിവാക്കാമോ എന്ന് നോക്കുക.
പ്രോംപ്റ്റ് കുറഞ്ഞത് മൂന്ന് കാരണങ്ങളുള്ള ഒരു ലക്ഷണമാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് കാണാതായ പാസ്ഫ്രെയ്സ്.