openssl ca: index.txt-ലെ അസാധുവായ കാലഹരണ തീയതി, അത് എങ്ങനെ ശരിയാക്കാം

ഒരു ഇഷ്യൂ റൺ ഇവിടെ നിൽക്കുന്നു: entry 22: invalid expiry date, എന്നാൽ നിങ്ങളുടെ മുന്നിലുള്ള അഭ്യർത്ഥന തികച്ചും ശരിയാണ്. പരാതി CA ഡാറ്റാബേസിന്റെ പാഴ്സറിൽ നിന്നാണ്, CSR-ൽ നിന്നല്ല, സർട്ടിഫിക്കറ്റ് അവസാനം അവതരിപ്പിക്കുന്ന VPN ക്ലൈന്റിൽ നിന്നുമല്ല. ഈ വ്യത്യാസമാണ് ശേഷമുള്ള എല്ലാം നിർണ്ണയിക്കുന്നത്: റെക്കോർഡ് വികലമാണ്, അതിനാൽ പരിഹാരം CA-യുടെ അവസ്ഥയിലാണ്, അഭ്യർത്ഥനയിലോ പിയർ കോൺഫിഗറേഷനിലോ അല്ല. അക്കമിട്ട എൻട്രിയെ index.txt-ലെ ഒരു വരിയായി കാണുക, എന്നാൽ പ്രശ്നം പരിശോധിക്കാവുന്ന ഉത്തരമുള്ള പരിമിതമായ ഒരു ഡാറ്റാ ചോദ്യമായി ചുരുങ്ങുന്നു.

പിശകിനെ ഡാറ്റാബേസിനെക്കുറിച്ചുള്ള പരാതിയായി വായിക്കുക

ഓരോ openssl ca വിളിയും എന്തെങ്കിലും ഒപ്പിടുന്നതിന് മുൻപ് അതിന്റെ ടെക്സ്റ്റ് ഡാറ്റാബേസിലൂടെ കടന്നുപോകുന്നു. ഓരോ വരിയിലും ഒരു സ്റ്റാറ്റസ് അക്ഷരം, കാലഹരണ സമയമുദ്ര, ഐച്ഛികമായ റദ്ദാക്കൽ മുദ്ര, ഹെക്സിലുള്ള ക്രമനമ്പർ, ഫയൽനാമം, വിഷയം എന്നിവ ഉണ്ട്. ഒരു ഫീൽഡ് പാഴ്സ് ചെയ്യാൻ കഴിയാതെ വരുമ്പോൾ, കമാൻഡ് വരി നമ്പർ റിപ്പോർട്ട് ചെയ്ത് ബാക്കി റെക്കോർഡ് ഊഹിക്കുന്നതിനു പകരം നിൽക്കുന്നു.

ആ നിർത്തൽ കർശനതയല്ല, സംരക്ഷണമാണ്. ഉപകരണത്തിന് വായിക്കാൻ കഴിയാത്ത റെക്കോർഡ്, ആവശ്യപ്പെട്ട വിഷയം ഇതിനകം ഉണ്ടോ, ക്രമനമ്പർ നൽകിയിട്ടുണ്ടോ, അല്ലെങ്കിൽ അടുത്ത CRL-ൽ എന്ത് വേണം എന്ന് തീരുമാനിക്കാൻ അതിനെ കഴിവില്ലാതാക്കുന്നു. മോശം വരി മറികടന്നു മുന്നോട്ടു പോയാൽ, മാസങ്ങൾക്കു ശേഷം, സാധാരണയായി ആർക്കും വിശദീകരിക്കാൻ കഴിയാത്ത ഒരു റദ്ദാക്കലിനിടയിൽ പുറത്തുവരുന്ന അതേ നിശബ്ദമായ പൊരുത്തക്കേട് സൃഷ്ടിക്കുമായിരുന്നു. സന്ദേശത്തെ ഡാറ്റയെക്കുറിച്ചുള്ള പരാതിയായി വായിക്കുക, അന്വേഷണം CA ഡയറക്ടറിക്കുള്ളിൽ തന്നെ തുടരും.

എന്തെങ്കിലും തൊടുന്നതിന് മുൻപ് CA-യുടെ അവസ്ഥ പകർത്തുക

ഡാറ്റാബേസ് ഫയൽ മാത്രമല്ല, മുഴുവൻ CA ഡയറക്ടറിയുടെയും സ്നാപ്പ്ഷോട്ട് എടുക്കുക. ഇൻഡക്സ്, അതിന്റെ ആട്രിബ്യൂട്ട് ഫയൽ, ക്രമനമ്പർ, CRL നമ്പർ എന്നിവയുടെ ഫയലുകൾ, സ്വകാര്യ കീ, പുറപ്പെടുവിച്ച സർട്ടിഫിക്കറ്റുകൾ എന്നിവയെല്ലാം പിന്നീടുള്ള പ്രവർത്തനങ്ങളിൽ പങ്കെടുക്കുന്നു, ഒന്ന് പുനഃസ്ഥാപിച്ച് ബാക്കിയുള്ളവ വിട്ടുകളയുന്ന പരിഹാരം രണ്ടാമതൊരു സംഭവം സൃഷ്ടിക്കുന്നു. ഉള്ളിടത്ത് CA-യുടെ സ്വന്തം ബാക്കപ്പ് രീതി ഉപയോഗിക്കുക, ജോലി നടക്കുന്ന സമയത്ത് ഷെഡ്യൂൾ ചെയ്ത ഇഷ്യൂവിംഗ് നിർത്തിവയ്ക്കുക.

പരാജയപ്പെട്ട കമാൻഡ് യഥാർത്ഥത്തിൽ ലോഡ് ചെയ്ത OpenSSL ബിൽഡും കോൺഫിഗറേഷൻ ഫയലും രേഖപ്പെടുത്തുക. ഇൻസ്റ്റാളേഷനുകൾ പലപ്പോഴും ഒന്നിലധികം CA ഡയറക്ടറികൾ സൂക്ഷിക്കുന്നു, പിശകിന് തിരഞ്ഞെടുത്ത കോൺഫിഗറേഷൻ പേരിടുന്ന ഡാറ്റാബേസിനോട് മാത്രമേ അർത്ഥമുള്ളൂ.

എൻട്രി കണ്ടെത്തി അതിന്റെ തീയതി ഫീൽഡ് ഡീകോഡ് ചെയ്യുക

റിപ്പോർട്ട് ചെയ്ത വരി നമ്പർ ആദ്യ റെക്കോർഡിൽ നിന്നാണ് എണ്ണുന്നത്, അതിനാൽ sed -n '22p' index.txt അതിന് മുകളിൽ ശൂന്യമായതോ അഭിപ്രായമോ ആയ വരികളില്ലെന്ന് ഉറപ്പിച്ച ശേഷം പ്രശ്നമുള്ള എൻട്രിയിൽ എത്തുന്നു. ആ വരി കാണാവുന്ന വിഭജന ചിഹ്നങ്ങളോടെ അച്ചടിക്കുക, കാരണം ടാബുകളും അവസാനത്തെ ഇടവും സാധാരണമാണ്, സാധാരണ എഡിറ്റർ ജാലകത്തിൽ അവ കാണില്ല.

കാലഹരണ ഫീൽഡ് വർഷത്തെ ആശ്രയിച്ച് വീതി മാറുന്ന സമയമുദ്രയാണ്. 2049 വരെയുള്ള മൂല്യങ്ങൾ UTCTime-ൽ YYMMDDHHMMSSZ എന്ന രൂപത്തിൽ എഴുതുന്നു, പിന്നീടുള്ള മൂല്യങ്ങൾ നാലക്ക വർഷമുള്ള GeneralizedTime-ലേക്ക് മാറുന്നു. രണ്ട് രൂപങ്ങളും കലർത്തുന്ന, അല്ലെങ്കിൽ പാഴ്സർ ഇപ്പോൾ നാല് പ്രതീക്ഷിക്കുന്നിടത്ത് രണ്ടക്ക വർഷം വഹിക്കുന്ന റെക്കോർഡ് ഈ ഘട്ടത്തിൽ തന്നെ പരാജയപ്പെടുന്നു. തടസ്സപ്പെട്ട എഴുത്തിൽ നിന്ന് അവശേഷിച്ച മുറിഞ്ഞ ഫീൽഡും അങ്ങനെ തന്നെ.

റെക്കോർഡിനെ മറ്റൊരു CA-യുടെ ഫയലുമായല്ല, അത് സൂചിപ്പിക്കുന്ന സർട്ടിഫിക്കറ്റുമായി താരതമ്യം ചെയ്യുക. ഒപ്പിട്ട സർട്ടിഫിക്കറ്റാണ് സാധുത എന്ത് പറയണം എന്നതിന്റെ അധികാരം, അത് ഇതിനകം പാഴ്സ് ചെയ്യാവുന്ന ഒരു വസ്തുവായി നിലനിൽക്കുന്നു.

ഒപ്പിട്ട സർട്ടിഫിക്കറ്റിന് അനുസരിച്ച് റെക്കോർഡ് ശരിയാക്കുക

യഥാർത്ഥ തീയതികൾ ഇതുപയോഗിച്ച് വായിക്കുക: openssl x509 -in issued.pem -noout -dates -serial -subject. notAfter നിങ്ങളുടെ ബിൽഡ് ആ വർഷത്തിന് എഴുതുന്ന മുദ്ര വീതിയിലേക്ക് മാറ്റുക, ഒരു അക്ഷരം പോലും മാറ്റുന്നതിന് മുൻപ് ക്രമനമ്പർ നിങ്ങൾ തിരുത്താൻ പോകുന്ന എൻട്രിയുമായി ഒത്തുപോകുന്നുവെന്ന് ഉറപ്പാക്കുക.

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

വർഷത്തെക്കുറിച്ചുള്ള ഊഹത്തിന് ഒപ്പിക്കാൻ തീയതി മുറിച്ച് ശരിയാക്കരുത്. രണ്ട് അക്ഷരത്തിന്റെ മുറിവ് ബിൽഡുകൾക്കിടയിൽ കൈമാറാൻ കഴിയില്ല, അത് ഡാറ്റാബേസ് ഭാവിയിലെ ഇരട്ട വിഷയ, CRL പരിശോധനകൾക്ക് റിപ്പോർട്ട് ചെയ്യുന്ന സാധുത നിശബ്ദമായി മാറ്റുന്നു. യഥാർത്ഥ മൂല്യം വീണ്ടെടുക്കാൻ കഴിയാത്തപ്പോൾ, പുതിയ ക്രമനമ്പറിൽ വീണ്ടും ഇഷ്യൂ ചെയ്യുക പഴയത് എന്തുകൊണ്ട് ഉപേക്ഷിച്ചുവെന്ന് എഴുതി വയ്ക്കുക. ഓഡിറ്റ് ട്രെയിൽ പരിഹാരത്തിന്റെ ഭാഗമാണ്, അതിനു ചുറ്റുമുള്ള കടലാസുപണിയല്ല.

പുറത്തുപോകുന്നതിന് മുൻപ് ഇഷ്യൂവിംഗും CRL നിർമ്മാണവും പരിശോധിക്കുക

അതേ കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് ഒരു ഇഷ്യൂവിംഗ് നടത്തി, വരി നമ്പർ പരാതിയില്ലാതെ അത് പൂർത്തിയാകുന്നുവെന്ന് ഉറപ്പാക്കുക. തുടർന്ന് openssl ca -gencrl -config openssl.cnf ഉപയോഗിച്ച് ഒരു CRL നിർമ്മിച്ച് അത് പാഴ്സ് ചെയ്യുന്നുവെന്ന് പരിശോധിക്കുക, കാരണം കേടായ റെക്കോർഡ് ഒപ്പിടുന്ന സമയത്തല്ല, മിക്കപ്പോഴും അവിടെയാണ് പുറത്തുവരുന്നത്.

പുതിയ സർട്ടിഫിക്കറ്റ് ഇതുപയോഗിച്ച് പരിശോധിക്കുക: openssl x509 -noout -dates -serial CA ഇപ്പോൾ എഴുതിയ വരിയുമായി താരതമ്യം ചെയ്യുക. സ്റ്റാറ്റസ് അക്ഷരവും കാലഹരണ തീയതിയും സർട്ടിഫിക്കറ്റുമായി ഒത്തുപോകുന്നുവെന്ന്, openssl verify -CAfile ca.pem issued.pem പിശകൊന്നുമില്ലാതെ മടങ്ങുന്നുവെന്ന് ഉറപ്പാക്കുക. തുടർന്ന് ഷെഡ്യൂൾ ചെയ്ത ഇഷ്യൂവിംഗ് പുനഃസ്ഥാപിച്ച് ആദ്യ റൺ നിരീക്ഷിക്കുക, കാരണം രണ്ടാമത്തെ വികലമായ വരി ഉടനെ തന്നെ അറിയിക്കും.