RSA വിശദീകരണത്തിലെ അക്ഷരങ്ങൾ ഒരു വസ്തുവിനുള്ളിലെ ഫീൽഡുകളെയാണ് പേരിടുന്നത്, PKI ഉപകരണം നൽകുന്ന ഫയലുകളെയല്ല. സ്വകാര്യ കീ ഫയലിൽ ഒരു ഘടനയുണ്ട്; അതിന്റെ ആദ്യ ഫീൽഡുകൾ പൊതുവായതും പിന്നീടുള്ളവ ടണൽ അവസാനിപ്പിക്കുന്ന യന്ത്രത്തിൽ നിന്ന് ഒരിക്കലും പുറത്തുപോകരുതാത്തതുമാണ്. ഈ രണ്ട് വസ്തുതകൾക്കിടയിലാണ് ഏത് ഫയൽ ഏത് ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു എന്നതിനെക്കുറിച്ചുള്ള മിക്ക പ്രായോഗിക ചോദ്യങ്ങളും. ഈ കൈപ്പുസ്തകം ആദ്യം ഘടന വായിക്കുന്നു, പിന്നീട് അത് ചൊരിയാതെ പരിശോധിക്കുന്ന കമാൻഡുകൾ.

അഭാജ്യ സംഖ്യകൾ തിരയുന്നതിന് മുമ്പ് കീ RSA ആണെന്ന് ഉറപ്പാക്കുക

ഏതോ ഒരു കീ നിലനിൽക്കുന്നു എന്നും അതിൽ ഒപ്പിട്ടിട്ടുണ്ട് എന്നും സർട്ടിഫിക്കറ്റ് തെളിയിക്കുന്നു; കീ RSA ആണെന്ന് അത് തെളിയിക്കുന്നില്ല. സിസ്റ്റങ്ങൾ ദീർഘവൃത്ത വക്രങ്ങളിലോ Ed25519-ലോ നിർമ്മിക്കാം, അതേ ഡയറക്ടറി ക്രമീകരണം എല്ലാത്തിനും സേവിക്കുന്നു. ഒരിക്കലും ഇല്ലാതിരുന്ന അഭാജ്യ ഘടകങ്ങൾ തിരയാൻ തുടങ്ങുന്നതിന് മുമ്പ് അൽഗോരിതം പരിശോധിക്കുക.

ഈ മൂന്ന് വായന-മാത്ര കമാൻഡുകൾ ചോദ്യത്തിന് ഉത്തരം നൽകി ഉപകരണത്തിന്റെ പതിപ്പ് രേഖപ്പെടുത്തുന്നു.

openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -text

പതിപ്പ് പ്രധാനമാണ്, കാരണം ഓപ്ഷൻ പേരുകൾ പ്രധാന പതിപ്പുകൾക്കിടയിൽ നീങ്ങിയിട്ടുണ്ട്. സർട്ടിഫിക്കറ്റ് ഔട്ട്പുട്ടിൽ പൊതു കീ അൽഗോരിതം വരിയും കീ വലുപ്പവും കണ്ടെത്തുക; കീ ഔട്ട്പുട്ടിൽ RSA കീ ഒരു മോഡുലസും പൊതു ഘാതവും അച്ചടിക്കുന്നു. ദീർഘവൃത്ത വക്രത്തിന്റെ കീ പകരം ഒരു പേരുള്ള വക്രം അച്ചടിക്കുന്നു, എത്ര തിരഞ്ഞാലും അതിൽ നിന്ന് n അല്ലെങ്കിൽ q ലഭിക്കില്ല.

base64 അല്ല, ഘടന വായിക്കുക

PEM എന്നത് ഹെഡർ വരികളിൽ പൊതിഞ്ഞ base64 ആണ്, അത് ഡീകോഡ് ചെയ്താൽ DER ലഭിക്കും, അതായത് വലിയ പൂർണ്ണസംഖ്യയല്ല, ക്രമീകരിച്ച ഘടന. RSA സ്വകാര്യ കീകൾ PKCS#1, PKCS#8 എന്ന രണ്ട് സാധാരണ കണ്ടെയ്നറുകളിൽ യാത്ര ചെയ്യുന്നു, രണ്ടും ഒരേ സംഖ്യാ കൂട്ടത്തിലേക്ക് എത്തുന്നു.

രണ്ട് അഭാജ്യ സംഖ്യകളുള്ളപ്പോൾ സ്വകാര്യ ഘടന ഒമ്പത് ഫീൽഡുകൾ വഹിക്കുന്നു: പതിപ്പ്, മോഡുലസ് n, പൊതു ഘാതം e, സ്വകാര്യ ഘാതം d, അഭാജ്യ സംഖ്യകൾ p, q, രണ്ട് CRT ഘാതങ്ങൾ, ഒരു CRT ഗുണകം. RFC 8017 വിഭാഗം A.1 ആ ഘടകങ്ങളും ASN.1 ക്രമീകരണവും നിർവചിക്കുന്നു, രണ്ടിൽ കൂടുതൽ അഭാജ്യ സംഖ്യകളും അനുവദിക്കുന്നു, അതിനാൽ ഒരു പൊതു പാഴ്സർ അധിക അഭാജ്യ എൻട്രികൾ അച്ചടിക്കാം. ക്രമത്തിൽ ശ്രദ്ധിക്കുക, കാരണം അത് സാധാരണ തെറ്റ് വിശദീകരിക്കുന്നു: പൊതു പകുതി സ്വകാര്യ ഫയലിനുള്ളിൽ സൂക്ഷിക്കുന്നു, അതിനാൽ പൊതു ഫീൽഡ് ഉണ്ടെന്നത് ആ ഫയൽ പങ്കിടാൻ സുരക്ഷിതമാക്കുന്നില്ല. അതിനുശേഷം ഉള്ളതെല്ലാം ഹോസ്റ്റിൽ തങ്ങേണ്ട വസ്തുവാണ്.

എൻകോഡിംഗ് ഉള്ളടക്കവുമായി കൂട്ടിക്കലർത്താൻ എളുപ്പമുള്ള ഒരു പാളി ചേർക്കുന്നു. openssl asn1parse ഘടനയെ ഒരു വൃക്ഷമായി വരയ്ക്കുന്നു, അങ്ങനെ ഫീൽഡുകളുടെ ക്രമം കാണാം, അത് ഒന്നും ഡീക്രിപ്റ്റ് ചെയ്യുന്നില്ല, കീ ഉപയോഗയോഗ്യമാണോ എന്നും പറയുന്നില്ല.

കീ അച്ചടിക്കാതെ സർട്ടിഫിക്കറ്റിനെ കീയുമായി ചേർക്കുക

അടുത്ത ചോദ്യം സാധാരണയായി സർട്ടിഫിക്കറ്റും കീയും ഒരുമിച്ചാണോ എന്നതാണ്. മോഡുലസുകൾ താരതമ്യം ചെയ്യുന്നത് അതിന് ഉത്തരം നൽകുന്നു, പക്ഷേ സ്വകാര്യത്തിന് അടുത്തുള്ള വസ്തു ടെർമിനൽ രേഖയിലേക്കും പകർത്തുന്നു, അത് ടിക്കറ്റിൽ എത്തിയേക്കാം. പൊതു പകുതികൾ താരതമ്യം ചെയ്യുന്നത് അതേ ചോദ്യത്തിന് സ്ക്രീനിൽ സംവേദനക്ഷമമായ ഒന്നും വെക്കാതെ ഉത്തരം നൽകുന്നു.

openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCH

ഒരേപോലുള്ള ഫയലുകൾ എന്നാൽ സർട്ടിഫിക്കറ്റ് ആ കീയുടെ പൊതു പകുതി വഹിക്കുന്നു എന്നാണ്, വ്യത്യാസം എന്നാൽ നിങ്ങൾ തെറ്റായ ജോഡി പിടിച്ചിരിക്കുന്നു എന്നാണ്. ആ പൊരുത്തക്കേടാണ് സന്തോഷത്തോടെ ചർച്ച ചെയ്ത് പിന്നീട് പ്രാമാണീകരണം നിരസിക്കുന്ന ടണലിന്റെ ഏറ്റവും സാധാരണ കാരണം. പിന്നീട് രണ്ട് താൽക്കാലിക ഫയലുകൾ നീക്കം ചെയ്യുക; അവയിൽ രഹസ്യമൊന്നുമില്ല, പക്ഷേ സംഭവത്തിന്റെ നടുവിൽ വൃത്തിയുള്ള പ്രവർത്തന ഡയറക്ടറിയെക്കുറിച്ച് ചിന്തിക്കാൻ എളുപ്പമാണ്.

അയൽ ഫയലുകൾ എന്തല്ലെന്ന് അറിയുക

സർട്ടിഫിക്കറ്റ് എന്നത് എതിർകക്ഷി CA സർട്ടിഫിക്കറ്റ് ഉപയോഗിച്ച് തുറക്കുന്ന എൻക്രിപ്റ്റ് ചെയ്ത പൊതു കീയല്ല; അത് പൊതു കീയും ഐഡന്റിറ്റി ഡാറ്റയും തമ്മിലുള്ള ഒപ്പിട്ട ബന്ധമാണ്. CA യുടെ സ്വകാര്യ ഒപ്പിടൽ കീ അതിന്റെ സ്വന്തം സർട്ടിഫിക്കറ്റിൽ നിന്നും ഓരോ ക്ലയന്റ് കീയിൽ നിന്നും വേർതിരിഞ്ഞിരിക്കുന്നു. അഭ്യർത്ഥനയും സർട്ടിഫിക്കറ്റല്ല: അത് ആവശ്യപ്പെട്ട വിവരവും പൊതു കീയും അഭ്യർത്ഥനയുടെ മേലുള്ള ഒപ്പോടെ വഹിക്കുന്നു, അത് അതിനെ രജിസ്ട്രേഷൻ ഇൻപുട്ടാക്കുന്നു, അവകാശത്തിന്റെ തെളിവല്ല.

FileAnswersDoes not prove
vpn-client.keyPossession of the private keyThat the identity is enrolled
vpn-client.crtA signed binding of public key to identityThat the client holds the matching key
vpn-client.csrThe requested binding and public keyThat access was granted
dh2048.pemGroup parameters for key exchangeAny RSA component
crl.pemRevocation status for certificatesAnything about a private key

ആ എൻട്രികളിൽ രണ്ടെണ്ണം RSA പാരാമീറ്ററുകളുമായി ആവശ്യത്തിലധികം കൂട്ടിക്കലരുന്നതിനാൽ രണ്ടുതവണ പേരിടേണ്ടി വരുന്നു. Diffie-Hellman പാരാമീറ്റർ ഫയൽ കീ സ്ഥാപനത്തിനുള്ള ഗ്രൂപ്പ് പാരാമീറ്ററുകൾ വഹിക്കുന്നു, ഒരു RSA അഭാജ്യ സംഖ്യയുമില്ല, വലിയ അഭാജ്യ സംഖ്യയായി അച്ചടിക്കുന്നുണ്ടെങ്കിലും. റദ്ദാക്കൽ പട്ടിക സർട്ടിഫിക്കറ്റുകളുടെ നില പ്രസിദ്ധീകരിക്കുന്നു, സ്വകാര്യ ഘാതത്തിന് ഒളിക്കാനാകുന്ന സ്ഥലമല്ല.

അതിനാൽ ഓരോ ഇൻവെന്ററി വരിയും നാല് കാര്യങ്ങൾ രേഖപ്പെടുത്തണം: വസ്തുവിന്റെ തരം, ഉടമ, ഉദ്ദേശ്യം, സ്വകാര്യ വസ്തു ഉൾപ്പെട്ടിട്ടുണ്ടോ എന്നത്. അവസാന കോളം ഫയൽ എവിടേക്ക് പകർത്താമെന്ന് തീരുമാനിക്കുന്നു, ആളുകൾ ഒഴിവാക്കുന്നത് അതാണ്.

ജോടി രേഖപ്പെടുത്തി, പിന്നീട് ഹാൻഡ്ഷേക്ക് പരിശോധിക്കുക

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് പരിശോധനയുടെ ഔട്ട്പുട്ട് തീയതിയും OpenSSL പതിപ്പും സഹിതം സൂക്ഷിക്കുക. അപ്പോൾ പിന്നീടുള്ള ഭ്രമണം ഓർമ്മയുമായല്ല, തെളിവുകളുമായി താരതമ്യം ചെയ്യാം.

openssl verify -CAfile ca.crt vpn-client.crt
openssl x509 -in vpn-client.crt -noout -subject -issuer -dates

പൊതു കീ താരതമ്യത്തിന് ശേഷം ജോടിയെ ഉപഭോഗിക്കുന്ന പാത പരീക്ഷിക്കുക: ടണൽ ഉയർത്തുക, സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കപ്പെടുന്നുവെന്നും സ്വീകരിക്കുന്നുവെന്നും ഉറപ്പാക്കുക, ഗേറ്റ്വേ ഏത് ഐഡന്റിറ്റി രേഖപ്പെടുത്തി എന്ന് പരിശോധിക്കുക. കീയും സർട്ടിഫിക്കറ്റും ഒത്തുപോകുന്നുണ്ടെങ്കിലും പ്രാമാണീകരണം പരാജയപ്പെടുന്നുവെങ്കിൽ, തകരാർ ജോടിയിലല്ല, വിശ്വാസത്തിലും ഐഡന്റിറ്റി മാപ്പിംഗിലും പ്രവേശന നയത്തിലുമാണ്.

മടക്കത്തിനായി മുമ്പത്തെ കീയും സർട്ടിഫിക്കറ്റും തീയതിയുള്ള ഡയറക്ടറിയിൽ സൂക്ഷിച്ച് രണ്ടും ഒരുമിച്ച് പുനഃസ്ഥാപിക്കുക, ഒരിക്കലും ഒന്നിനെ മാത്രമല്ല. സർട്ടിഫിക്കറ്റില്ലാത്ത കീയും കീയില്ലാത്ത സർട്ടിഫിക്കറ്റും പുറത്തുനിന്ന് ഒരേപോലെ പരാജയപ്പെടുന്നു, അത് പകുതി പുനഃസ്ഥാപിച്ച ജോഡികളെ രാത്രി രണ്ട് മണിക്ക് അഴിക്കാൻ ചെലവേറിയതാക്കുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ