Access Server-ലെ വെബ് സർട്ടിഫിക്കറ്റ് പിശക്: ശൂന്യമായ CA ബണ്ടിൽ

ശൂന്യമായ ca_bundle മൂല്യമോ കേടായ PEM-ഓ അഡ്മിൻ ഇന്റർഫേസ് നിർത്തുന്നു. പുനരാരംഭിക്കുന്നതിന് മുൻപ് സർട്ടിഫിക്കറ്റ്, കീ, ചെയിൻ എന്നിവ ഒരു സെറ്റായി പരിശോധിക്കുക, VPN PKI തൊടരുത്.

DNS ശരിയായി പരിഹരിക്കുമ്പോൾ ലോഡ് ചെയ്യാത്ത വെബ് ലോഗിൻ പേജ് സാധാരണയായി DNS പ്രശ്നമല്ല. സേവന ലോഗ് ശൂന്യമായ സർട്ടിഫിക്കറ്റ് ബണ്ടിൽ പാത്ത് അല്ലെങ്കിൽ വെബ് സർട്ടിഫിക്കറ്റിനും സ്വകാര്യ കീയ്ക്കും PEM പാഴ്സിംഗ് പരാജയം സൂചിപ്പിച്ചാൽ, HTTPS ലിസണറിന് ഉപയോഗയോഗ്യമായ വസ്തു ഇല്ല, പേര് പരിഹരണം സഹായിക്കില്ല. പരിഹാരം മൂന്ന് കോൺഫിഗറേഷൻ കീകളിലാണ്, ഒരു VPN ക്ലൈന്റ് സർട്ടിഫിക്കറ്റും വീണ്ടും നൽകേണ്ടതില്ല.

മൂന്ന് കീകൾ യഥാർത്ഥത്തിൽ എന്തിനെ സൂചിപ്പിക്കുന്നു

ഇഷ്ടാനുസൃത വെബ് സർട്ടിഫിക്കറ്റ് സെറ്റ് cs.cert, cs.priv_key, cs.ca_bundle വിവരിക്കുന്നു. ഓരോന്നും ഫയൽ പാത്ത് സൂക്ഷിക്കുന്നു, വെബ് സേവനം മൂന്നും ഒരുമിച്ച് ഉപയോഗിക്കുന്നു. തെറ്റായ കീയുള്ള സർട്ടിഫിക്കറ്റോ യഥാർത്ഥത്തിൽ ലീഫ് സർട്ടിഫിക്കറ്റായ ചെയിൻ ഫയലോ ശൂന്യമായ മൂല്യം പോലെ പരാജയപ്പെടുന്നു.

ഈ കീകൾ Admin, Client വെബ് ഇന്റർഫേസിന്റേതാണ്. VPN ക്ലൈന്റുകൾക്ക് സർട്ടിഫിക്കറ്റ് നൽകുന്ന PKI-യിൽ നിന്ന് വേറിട്ടതാണ്, അതിനാൽ മാറ്റാൻ പ്രൊഫൈലുകളോ സർവർ കീയോ സർട്ടിഫിക്കറ്റ് അതോറിറ്റിയോ തൊടേണ്ടതില്ല. മുഴുവൻ PKI പുനർനിർമ്മിക്കുന്നത് ഇവിടെ ഏറ്റവും ചെലവേറിയ തെറ്റാണ്.

ഒരു വ്യത്യാസം സമയം ലാഭിക്കുന്നു: വ്യക്തമായി ശൂന്യമായ ഇഷ്ടാനുസൃത മൂല്യം ഒരു ഓവർറൈഡും ഇല്ലാത്ത അവസ്ഥയല്ല. ആദ്യത്തേത് പാഴ്സറിന് ശൂന്യമായ പാത്ത് നൽകുന്നു, ലോഗ് വരി അതാണ് പറയുന്നത്. രണ്ടാമത്തേത് Access Server-നെ സ്വന്തം വസ്തുവിൽ വിടുന്നു.

നിലവിലുള്ള ഫയൽ എന്തുകൊണ്ട് പാഴ്സ് ചെയ്യുന്നില്ല

പാഴ്സർ ഫയലിന്റെ പേരല്ല, ഫയലിനുള്ളിലെ ലേബൽ ബ്ലോക്കുകൾ വായിക്കുന്നു. സ്വകാര്യ കീയുള്ള .crt, ഒരു ബ്ലോക്കായി എഴുതിയ ചെയിൻ, അവസാന വരി മുറിച്ച ഫയൽ എന്നിവ നിരസിക്കപ്പെടുന്നു. RFC 7468 ആ ലേബലുകൾ നിർവചിക്കുന്നത് അടുത്ത വസ്തുവിന്റെ തരം അറിയിക്കുന്ന ഏക മാർഗമായതിനാലാണ്.

വസ്തുക്കൾ പരിശോധിക്കുക, എക്സ്റ്റൻഷനുകളല്ല. Linux-ൽ openssl x509 -noout -subject -issuer -in server.pem, openssl pkey -noout -check -in key.pem രണ്ട് പ്രധാന ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, മോഡുലസോ പൊതു കീയോ താരതമ്യം ചെയ്യുന്നത് അവ ഒരുമിച്ചാണെന്ന് തെളിയിക്കുന്നു. സ്വകാര്യ കീയുടെ ഔട്ട്പുട്ട് ടിക്കറ്റുകളിൽ നിന്നും ചാറ്റ് ലോഗുകളിൽ നിന്നും അകറ്റി നിർത്തുക.

ശൂന്യമായ പാത്ത് കേടായ ഫയലിനോളം സംശയാർഹമാണ്, രണ്ടും അവ്യക്തമായ തുടർ പിശകുകൾ നൽകുന്നു. ലോഗ് ബണ്ടിൽ പാത്ത് ശൂന്യമെന്ന് പറഞ്ഞാൽ, ഫയൽ ഡീബഗ് ചെയ്യുന്നതിന് മുൻപ് സൂക്ഷിച്ച മൂല്യം വായിക്കുക.

ഉദ്ദേശ്യപൂർവ്വം ഫോൾബാക്കിലേക്ക് മടങ്ങുക

Access Server-ന്റെ CLI-യിൽ മൂന്ന് പാത്തുകൾ ആർഗ്യുമെന്റായി സ്വീകരിക്കുന്ന പരിശോധനയുണ്ട്, സെറ്റ് ഉപയോഗയോഗ്യമാണോ എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. താഴെയുള്ള പാത്തുകൾ ഉദാഹരണമാണ്; ഹോസ്റ്റിലെ സംരക്ഷിത സ്ഥലങ്ങൾ കൊണ്ട് മാറ്റുക.

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

പ്രവർത്തിക്കുന്ന സേവനം തൊടുന്നതിന് മുൻപ് ഫലം വായിക്കുക, എന്നിട്ട് മൂല്യങ്ങൾ ഇറക്കുമതി ചെയ്ത് ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പിനുള്ള രേഖപ്പെടുത്തിയ പ്രവർത്തനത്തിലൂടെ പ്രയോഗിക്കുക. ഔദ്യോഗിക CLI ട്യൂട്ടോറിയൽ പരിശോധന, ഇറക്കുമതി, പ്രയോഗ ഘട്ടം എന്നിവ ഉൾക്കൊള്ളുന്നു, അതിന്റെ പതിപ്പ് ഏത് സംഗ്രഹത്തെക്കാളും പ്രധാനമാണ്.

ഉപയോക്താക്കൾ യഥാർത്ഥത്തിൽ ടൈപ്പ് ചെയ്യുന്ന പേര് പരിശോധിക്കുക

ഇഷ്ടാനുസൃത വസ്തു കേടായി സാധുവായ ബിൽറ്റ്-ഇൻ ഫോൾബാക്ക് ഇപ്പോഴും ഉണ്ടെങ്കിൽ, രേഖപ്പെടുത്തിയ വീണ്ടെടുക്കൽ മൂന്ന് ഓവർറൈഡുകൾ നീക്കി Access Server-നെ ആ ഫോൾബാക്ക് ഉപയോഗിക്കാൻ അനുവദിക്കുന്നതാണ്. ആദ്യം കൺസോൾ പ്രവേശനവും നിലവിലെ കോൺഫിഗറേഷന്റെ പകർപ്പും ഉറപ്പാക്കുക.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

മുഴുവൻ കോൺഫിഗറേഷൻ ഡാറ്റാബേസും മായ്ക്കുന്നത് സർട്ടിഫിക്കറ്റ് അറ്റകുറ്റപ്പണിയല്ല. ആ മൂന്ന് കീകൾ ലക്ഷ്യമിടുക, പ്രയോഗിക്കുക, വെബ് ഇന്റർഫേസ് പ്രതികരിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. web-ssl ഡയറക്ടറിയിലെ സ്വയം-ഒപ്പിട്ട ഫയലുകൾ ഫോൾബാക്ക് വിഭവമാണ്, ജോലിസ്ഥലമല്ല.

ഫോൾബാക്ക് പ്രാബല്യത്തിൽ വന്നാൽ ബ്രൗസർ മറ്റൊരു സർട്ടിഫിക്കറ്റ് കാണിക്കും. അതാണ് ശരിയായ ഫലം; വിശ്വസനീയമായ അഡ്മിനിസ്ട്രേറ്റീവ് പ്രക്രിയയിലൂടെ അത് പരിശോധിക്കുക.

വിജയകരമായ സൈൻ-ഇന് ശേഷം മാത്രം വീണ്ടെടുക്കൽ പൂർത്തിയാകുന്നു

TCP ലിസണർ പ്രത്യക്ഷപ്പെട്ടാൽ വീണ്ടെടുക്കൽ പൂർത്തിയാകുന്നില്ല. DNS പേര്, സർട്ടിഫിക്കറ്റ് ഐഡന്റിറ്റി, ആ പേരിന്റെ ചെയിൻ എന്നിവ പരിശോധിക്കുക, ശേഷം Admin, Client ഇന്റർഫേസുകൾ ലോഡ് ചെയ്ത് സൈൻ-ഇൻ പൂർത്തിയാക്കുക. പോർട്ട് പരിശോധന അതൊന്നും തെളിയിക്കുന്നില്ല.

Access Server 3.1-ഉം അതിനുശേഷമുള്ളതും ഓരോ SNI ഹോസ്റ്റ് പേരിനും വ്യത്യസ്ത വെബ് സർട്ടിഫിക്കറ്റുകൾ നൽകാം. അത് കോൺഫിഗർ ചെയ്താൽ, സ്ഥിര കീകളും പേരിന് സവിശേഷമായ എൻട്രികളും വേറിട്ട സെറ്റുകളാണ്, IP വിലാസത്തിൽ പരിശോധിക്കുമ്പോൾ ഉപയോക്താക്കൾക്ക് ലഭിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്ത സർട്ടിഫിക്കറ്റ് കാണാം. പരാജയപ്പെട്ട പേരിന്റെ സെറ്റ് ശരിയാക്കി പരിശോധിക്കുക, സംഭവം അടയ്ക്കുന്നതിന് മുൻപ് സൈൻ-ഇൻ പരിശോധന ആവർത്തിക്കുക.

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