സ്വകാര്യ IP-യിലേക്ക് HTTPS: സർട്ടിഫിക്കറ്റ് ഐഡന്റിറ്റിയോ ഹോസ്റ്റ്നാമോ?

https://10.60.0.25-ലുള്ള നിങ്ങളുടെ സേവനത്തിന് DNS നാമമില്ലാതെയും പ്രാമാണീകരിച്ച TLS ഉണ്ടാകാം। വിലാസമാണ് ക്ലയന്റ് പരിശോധിക്കേണ്ട ഐഡന്റിറ്റി, സർട്ടിഫിക്കറ്റ് അത് കൃത്യമായി വിവരിക്കണം। വിലാസം ഐഡന്റിറ്റിയാകാൻ മതിയായ സ്ഥിരതയുള്ളതാണോ, അല്ലെങ്കിൽ ഹോസ്റ്റ്നാം പരിപാലിക്കാൻ എളുപ്പമാകുമോ എന്നതാണ് തീരുമാനം। VPN ലഭ്യതയ്ക്ക് ഉത്തരം നൽകുന്നു; ഇതിന് ഉത്തരം നൽകുന്നില്ല।

ഐഡന്റിറ്റിയും വിശ്വാസവും ശരിയാക്കിയാൽ, IP അടിസ്ഥാനമാക്കിയ URL സാധുവായ രൂപകൽപ്പനയാണ്।

ക്ലയന്റ് യഥാർത്ഥത്തിൽ എന്താണ് പരിശോധിക്കുന്നത്

URL-ലെ റഫറൻസ് ഐഡന്റിറ്റിയെ സർട്ടിഫിക്കറ്റിന്റെ ബദൽ വിഷയ നാമങ്ങളുമായി ക്ലയന്റ് താരതമ്യം ചെയ്യുന്നു। IP വിലാസത്തിന് അത് വിലാസത്തിന് തുല്യമായ iPAddress എൻട്രി എന്നാണ് അർത്ഥം। സൗഹൃദപരമായ പൊതുനാമം അതിന് പകരമല്ല।

RFC 9525 IP വിലാസ ഐഡന്റിറ്റികളെ DNS നാമങ്ങളിൽ നിന്ന് വേർതിരിക്കുകയും പൊരുത്ത നിയമം നിർവചിക്കുകയും ചെയ്യുന്നു। വിലാസം വിഷയ ലേബലിൽ മാത്രമോ DNS തരം എൻട്രിയായോ വെച്ചാൽ പൊരുത്തം ഉണ്ടാകില്ല। അതിനാൽ മുന്നറിയിപ്പ് പ്രത്യക്ഷപ്പെടുമ്പോൾ പരിശോധിക്കേണ്ട ഫീൽഡ് SAN ആണ്।

വിശ്വാസം രണ്ടാമത്തെ, സ്വതന്ത്ര പരിശോധനയാണ്। നാമപ്പൊരുത്തം വിശ്വാസയോഗ്യമല്ലാത്ത ശൃംഖലയോ കാലഹരണപ്പെട്ട സർട്ടിഫിക്കറ്റോ മറ്റൊരു ഉദ്ദേശ്യത്തിന് നൽകിയ സർട്ടിഫിക്കറ്റോ ശരിയാക്കുന്നില്ല।

ആദ്യ തീരുമാനം: വിലാസം ഐഡന്റിറ്റിയാകാൻ മതിയായ സ്ഥിരതയുള്ളതാണോ

വിന്യാസത്തിന്റെ മുഴുവൻ കാലയളവിലും വിലാസം സ്ഥിരമാണെങ്കിൽ, IP SAN സർട്ടിഫിക്കറ്റ് ലളിതവും സത്യസന്ധവുമാണ്। സേവനത്തിന് നീങ്ങാനാകുമെങ്കിൽ, ഓരോ നീക്കവും സർട്ടിഫിക്കറ്റ് മാറ്റലും ഏകോപിത ക്ലയന്റ് അപ്ഡേറ്റുമായി മാറുന്നു।

സ്ഥിരമായ ഹോസ്റ്റ്നാം ആ ബന്ധം കുറയ്ക്കുന്നു। ക്ലയന്റുകൾ നാമം ഉപയോഗിക്കുന്നു, അംഗീകൃത DNS അതിനെ നിലവിലെ വിലാസത്തിലേക്ക് മാപ്പ് ചെയ്യുന്നു, വിലാസ മാറ്റം ഇനി ഐഡന്റിറ്റി മാറ്റമല്ല। സർട്ടിഫിക്കറ്റിന് ഇപ്പോഴും പുതുക്കൽ വേണം, പക്ഷേ URL മാറുന്നില്ല।

നിയന്ത്രിത hosts ഫയൽ എൻട്രിക്ക് ചെറിയ പരിസരത്ത് മാപ്പിംഗ് നൽകാം। അത് വിതരണ ഉത്തരവാദിത്തം കൂട്ടുന്നു; TLS പരിശോധനയ്ക്ക് പകരമാകുന്നില്ല।

രണ്ടാം തീരുമാനം: ക്ലയന്റ് ഇഷ്യൂവറെ എങ്ങനെ വിശ്വസിക്കും

സ്വകാര്യ CA-യ്ക്ക്, അംഗീകൃത സംവിധാനത്തിലൂടെ വിശ്വാസ ആങ്കർ ഉദ്ദേശിച്ച ഉപകരണങ്ങളിലേക്ക് വിതരണം ചെയ്യുക। മുന്നറിയിപ്പുകൾ മറികടക്കാനോ സൈൻ-ഇൻ പേജ് നൽകുന്ന സർട്ടിഫിക്കറ്റ് ഇൻസ്റ്റാൾ ചെയ്യാനോ ഉപയോക്താക്കളെ പരിശീലിപ്പിക്കരുത്। പൊതുവായി വിശ്വസനീയമായ സർട്ടിഫിക്കറ്റ് വേണമെങ്കിൽ, ആസൂത്രണം ചെയ്യുന്നതിന് മുമ്പ് സ്വകാര്യ വിലാസങ്ങൾക്കുള്ള ഇഷ്യൂവറുടെ നിലവിലെ നിയമങ്ങൾ പരിശോധിക്കുക। മിക്ക പൊതു ഇഷ്യൂവർമാരും സ്വകാര്യ IP-യെ പൊതു ഐഡന്റിറ്റിയായി പരിശോധിക്കില്ല।

യഥാർത്ഥ ബ്രൗസറോ ആപ്ലിക്കേഷനോ പരിശോധിക്കുക। അതിന്റെ ട്രസ്റ്റ് സ്റ്റോറും പരിശോധനാ സ്വഭാവവും ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ പൊതു സർട്ടിഫിക്കറ്റ് ഡോക്യുമെന്റേഷനേക്കാൾ പ്രധാനമാണ്। കൺസോളിൽ മാത്രമല്ല, യഥാർത്ഥ ഉപകരണത്തിൽ അത് പരിശോധിക്കുക।

വെബ് ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുന്ന യന്ത്രം VPN ഗേറ്റ്വേ ആയില്ലെന്ന് വരാം, അതിനാൽ ടണലിന്റെ സർട്ടിഫിക്കറ്റിന് ഇതുമായി എന്തെങ്കിലും ബന്ധമുണ്ടെന്ന് കരുതരുത്।

വിലാസ മാറ്റം സംഭവിക്കുന്നതിന് മുമ്പ് ആസൂത്രണം ചെയ്യുക

10.60.0.25 10.60.0.40 ആയാൽ, പഴയ സർട്ടിഫിക്കറ്റ് ഇനി URL വിവരിക്കുന്നില്ല। മാറ്റവും ക്ലയന്റ് അപ്ഡേറ്റും ഒരുമിച്ച് ആസൂത്രണം ചെയ്യുക, കൈമാറ്റത്തിനിടയിൽ പരിശോധന ഒരിക്കലും ഓഫാക്കരുത്।

ഉപയോക്താക്കൾ ടൈപ്പ് ചെയ്യുന്നതോ ആപ്ലിക്കേഷനുകൾ കോൺഫിഗർ ചെയ്യുന്നതോ ആയ ഐഡന്റിറ്റി തിരഞ്ഞെടുത്ത്, അതിന് ചുറ്റും ഇഷ്യൂയിംഗ്, വിശ്വാസം, വിന്യാസം, പുതുക്കൽ എന്നിവ വിന്യസിക്കുക। തള്ളിയ മുന്നറിയിപ്പോടെ എത്താവുന്ന പേജ്, ക്ലയന്റ് ഐഡന്റിറ്റി പരിശോധിക്കുന്ന സേവനത്തിന് തുല്യമായ ഫലമല്ല।