strongSwan: കീ തരം, ലോഡർ, തെറ്റായ backend

ഫയൽ എക്സ്റ്റൻഷനുകൾ കീ അൽഗോരിതങ്ങൾ തിരിച്ചറിയുന്നില്ല, കൂടാതെ .pem ആവരണത്തിൽ RSA അല്ലെങ്കിൽ ECDSA വസ്തു ഉണ്ടാകാം. PEM ബൈറ്റുകൾ എങ്ങനെ പൊതിയുന്നു എന്ന് വിവരിക്കുന്നു, അതേസമയം RSAയും ECDSAയും വ്യത്യസ്ത അൽഗോരിതങ്ങളുടെ പേരുകളാണ്, PKCS12 ഫയൽ വീണ്ടും മറ്റൊരു കാര്യമാണ്. strongSwan പ്ലഗിനുകളും കോൺഫിഗറേഷൻ backendഉം വഴി ക്രെഡൻഷ്യലുകൾ ലോഡ് ചെയ്യുന്നു, അതിനാൽ സർട്ടിഫിക്കറ്റ് ഒരു പട്ടികയിൽ പ്രത്യക്ഷപ്പെടാം, പക്ഷേ സ്വകാര്യ കീ ഒരിക്കലും ഉപയോഗയോഗ്യമാകണമെന്നില്ല. ഏതെങ്കിലും രഹസ്യം എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് ഈ പാളികൾ വേർതിരിക്കുക.

എൻകോഡിംഗ്, അൽഗോരിതം, പാക്കേജിംഗ് എന്നിവ മൂന്ന് പാളികളാണ്

ഒരു കീ ഫയലിന് എൻകോഡിംഗ്, അൽഗോരിതം, പലപ്പോഴും ഒരു കണ്ടെയ്നർ എന്നിവയുണ്ട്. PEM പരിചിതമായ base64 ആവരണമാണ്; DER അതിന്റെ ബൈനറി സമാനമാണ്; PKCS12 ഒരു സർട്ടിഫിക്കറ്റ് അതിന്റെ കീയും ശൃംഖലയും സഹിതം ഒന്നിപ്പിക്കുന്നു. സർട്ടിഫിക്കറ്റ്-ശൃംഖല ഫയൽ മറ്റൊരു കണ്ടെയ്നർ ആണ്, സാധാരണയായി അതിൽ സ്വകാര്യ കീ ഒട്ടും ഉണ്ടാകില്ല. ഈ ലേബലുകളിൽ ഒന്നും ഉള്ളിലെ വസ്തു RSA ആണോ ECDSA ആണോ എന്ന് പറയുന്നില്ല.

അൽഗോരിതം ഒബ്ജക്റ്റിൽ നിന്നു തന്നെ വായിക്കുക. ഒരു ദാതാവിന്റെ മാർക്കറ്റിംഗ് പേരോ ഫയൽ എക്സ്റ്റൻഷനോ തെളിവല്ല, കാരണം ഒരേ ഇഷ്യൂവർ വ്യത്യസ്ത കീ തരങ്ങൾ നൽകാം.

ലോഡറെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് പൊതു കീകൾ താരതമ്യം ചെയ്യുക

ലോഡ് ചെയ്യുന്ന സർട്ടിഫിക്കറ്റ് സർട്ടിഫിക്കറ്റ് പാഴ്സ് ചെയ്തു എന്ന് തെളിയിക്കുന്നു, അതിന്റെ സ്വകാര്യ കീ ഉണ്ടെന്നോ ഉപയോഗയോഗ്യമാണെന്നോ അല്ല. സർട്ടിഫിക്കറ്റിൽ നിന്നും നിർദ്ദേശിച്ച സ്വകാര്യ കീയിൽ നിന്നും പൊതു കീ കണ്ടെത്തി, തുടർന്ന് രണ്ട് ഡൈജസ്റ്റുകൾ താരതമ്യം ചെയ്യുക. ഏതെങ്കിലും എക്സ്ട്രാക്ഷൻ പരാജയപ്പെട്ടാൽ അവിടെ നിർത്തുക, കാരണം ശൂന്യമായ ഔട്ട്പുട്ടിന്റെ ഡൈജസ്റ്റ് ഒന്നും തെളിയിക്കുന്നില്ല. ഒത്തുപോകുന്ന ഡൈജസ്റ്റുകൾ ജോഡി ഒരുമിച്ചാണെന്ന് തെളിയിക്കുന്നു, സർട്ടിഫിക്കറ്റ് ജോലിക്ക് അനുയോജ്യമാണോ എന്നതിനെക്കുറിച്ച് അതിൽ കൂടുതലൊന്നുമല്ല.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

രണ്ടാമത്തെ കമാൻഡ് നിങ്ങളുടെ മെഷീനിലെ സ്വകാര്യ വസ്തുവിനെ സ്പർശിക്കുന്നു, പക്ഷേ പൊതു പകുതി മാത്രം പുറപ്പെടുവിക്കുന്നു. അതേപടി സൂക്ഷിക്കുക, ഒരിക്കലും ഒരു ടിക്കറ്റിൽ സ്വകാര്യ കീ പേസ്റ്റ് ചെയ്യരുത്. കീ എൻക്രിപ്റ്റ് ചെയ്തതാണെങ്കിൽ, പ്രോസസ് പട്ടിക വെളിപ്പെടുത്താൻ കഴിയുന്ന കമാൻഡ് ലൈനിൽ ഇടുന്നതിനുപകരം പിന്തുണയുള്ള ടൂൾ പാസ്ഫ്രേസ് ചോദിക്കാൻ അനുവദിക്കുക.

പഴയ ipsec.secrets അല്ലെങ്കിൽ swanctl ക്രെഡൻഷ്യലുകൾ

strongSwan-ന് സാധാരണ ഉപയോഗിക്കുന്ന രണ്ട് ക്രെഡൻഷ്യൽ പാതകളുണ്ട്. പഴയ starter സ്റ്റാക്ക് തരം-നിർദ്ദിഷ്ട എൻട്രികൾ ഇതിൽ നിന്ന് വായിക്കുന്നു: ipsec.secrets, കൂടാതെ ഓരോ എൻട്രിയും വസ്തുവിന് ശരിയായ തരം പറയണം. swanctl, vici സ്റ്റാക്ക് സ്വന്തം ക്രെഡൻഷ്യൽ ഡയറക്ടറിയിൽ നിന്ന് സ്വന്തം കോൺഫിഗറേഷൻ വഴി കീകൾ ലോഡ് ചെയ്യുന്നു. പ്രവർത്തിക്കുന്ന backend വായിക്കാത്ത ഫയൽ എഡിറ്റ് ചെയ്യുന്നത് ഒന്നും മാറ്റുന്നില്ല.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

യഥാർത്ഥത്തിൽ ഏത് backend പ്രവർത്തിക്കുന്നു എന്ന് കണ്ടെത്തി, ആ backend നോക്കുന്നിടത്ത് കീ ഇടുക. strongSwan 5.9 പഴയ മാനുവൽ തരം-നിർദ്ദിഷ്ട രഹസ്യ എൻട്രികൾ നിർവചിക്കുന്നു, ഇത് swanctl ഡോക്യുമെന്റേഷൻ അല്ല. രണ്ടും കലർത്തിയാൽ അഡ്മിനിസ്ട്രേറ്റർ ആധികാരികമായി കരുതുന്ന ഫയൽ അവഗണിക്കുന്ന ഒരു ഡീമൺ ഉണ്ടാകും. പിശക് റിപ്പോർട്ട് ചെയ്യാത്ത റീലോഡ് എന്നാൽ കോൺഫിഗറേഷൻ പാഴ്സ് ചെയ്തു എന്ന് മാത്രം.

ലോഡ് ഇവന്റും ഓതന്റിക്കേഷൻ ഫലവും വായിക്കുക

നിയന്ത്രിത റീലോഡിന് ശേഷം, നിർദ്ദിഷ്ട കീയ്ക്കായി ഡീമോണിന്റെ സ്വന്തം ലോഡിംഗ് ഔട്ട്പുട്ട് വായിക്കുക. സ്റ്റാറ്റസ് ഡംപിൽ പട്ടികപ്പെടുത്തിയ സർട്ടിഫിക്കറ്റ് സ്വകാര്യ കീ അതുമായി പൊരുത്തപ്പെട്ടു എന്ന് കാണിക്കുന്നില്ല.

ക്ലയന്റ് ഇപ്പോഴും പരാജയപ്പെടുകയാണെങ്കിൽ, സെർവർ ഇവന്റും ക്ലയന്റ് പിശകും വേർതിരിച്ച് സൂക്ഷിക്കുക. ശൃംഖല സാധുത, ഐഡന്റിറ്റി പൊരുത്തം, കൂടാതെ രീതികളുടെ അനുയോജ്യത അവരുടേതായ തെളിവുകളുള്ള പിന്നീടുള്ള ചോദ്യങ്ങളാണ്. ഫലം കൃത്യമായ കീ പാതയും നിങ്ങൾ താരതമ്യം ചെയ്ത ഡൈജസ്റ്റും സഹിതം എഴുതി വയ്ക്കുക, അല്ലാത്തപക്ഷം അടുത്ത ഷിഫ്റ്റ് അതേ റീലോഡ് ആവർത്തിക്കും. ലോഡർ പൊരുത്തക്കേടിന് CA മാറ്റിസ്ഥാപിക്കുന്നത് ആദ്യ പ്രതികരണമല്ല.