OpenVPN verify-x509-name: subject, name, name-prefix

ആദ്യം പൊരുത്തത്തിന്റെ തരം വായിക്കുക, പിന്നെ വാചകം: verify-x509-name നിർദ്ദേശം ശരിയായി തോന്നിയേക്കാം, എന്നിട്ടും നിങ്ങൾ വിശ്വസിക്കാൻ ഉദ്ദേശിക്കാത്ത ഒരു സർട്ടിഫിക്കറ്റ് സ്വീകരിച്ചേക്കാം. ഒരേ പ്രതീക്ഷിത വാചകമെങ്കിലും വ്യത്യസ്ത തരങ്ങളുള്ള രണ്ട് വരികൾ രണ്ട് വ്യത്യസ്ത ആവശ്യകതകളാണ്. ആദ്യം തരം വായിക്കുക, പിന്നെ വാചകം. നിർദ്ദേശത്തെ ബന്ധത്തിലെ ഒരു അധിക വ്യവസ്ഥയായി കാണുക, മുഴുവൻ പരിശോധനയായി അല്ല.

ഓപ്ഷൻ യഥാർത്ഥത്തിൽ എന്താണ് ഉറപ്പിക്കുന്നത്

മറുവശത്തെ സർട്ടിഫിക്കറ്റ് വഹിക്കേണ്ട ഐഡന്റിറ്റിയെ നിർദ്ദേശം പേരിടുന്നു. താരതമ്യം പരാജയപ്പെടുമ്പോൾ, OpenVPN ഹാൻഡ്ഷേക്ക് നിർത്തുന്നു, ടണൽ ഉയരുന്നില്ല. പ്രൊഫൈലിലെ മറ്റെല്ലാം ഇപ്പോഴും ബാധകമാണ്: സർട്ടിഫിക്കറ്റ് വിശ്വസ്ത CA-യിലേക്ക് ചങ്ങലയാകണം, റോൾ പരിശോധനയും കടക്കണം, അതിനാൽ ഇത് ഒരു അധിക വ്യവസ്ഥയാണ്, പകരമല്ല. പേരിന്റെ പ്രതീക്ഷ നിറവേറ്റിയിട്ടും റോൾ പരിശോധനയിൽ പരാജയപ്പെടുന്ന പ്രൊഫൈൽ ഇപ്പോഴും തകർന്നതാണ്, ലോഗ് സാധാരണയായി അത് പറയുന്നു.

ബ്രൗസർ നടത്തുന്ന ഹോസ്റ്റ്നേം സാധൂകരണത്തിൽ നിന്നും ഇത് വ്യത്യസ്തമാണ്. ബ്രൗസർ സ്വന്തം TLS സ്റ്റാക്കിന്റെ നിയമങ്ങൾ പ്രകാരം പേരുകളെ subject-ന്റെ ഇതര പേരുകളുമായി ഒത്തുനോക്കുന്നു, അതേസമയം OpenVPN നിങ്ങൾ തിരഞ്ഞെടുത്ത തരം ഉപയോഗിച്ച് സർട്ടിഫിക്കറ്റിന്റെ ഒരു ഫീൽഡ് താരതമ്യം ചെയ്യുന്നു. അതുകൊണ്ട് ബ്രൗസർ ശൈലിയിലുള്ള ഹോസ്റ്റ്നേം നിർദ്ദേശത്തിൽ ഒട്ടിച്ചാൽ സർട്ടിഫിക്കറ്റ് സേവനത്തെ യഥാർത്ഥത്തിൽ ഉൾക്കൊള്ളുന്നുണ്ടെങ്കിലും പൊരുത്തക്കേട് ഉണ്ടാകാം.

subject: മുഴുവൻ വ്യതിരിക്ത നാമം, അക്ഷരം അക്ഷരം

തരം എഴുതിയിട്ടില്ലെങ്കിൽ സ്ഥിരസ്ഥിതി subject ആണ്, കൂടാതെ പ്രതീക്ഷിത മൂല്യം സർട്ടിഫിക്കറ്റിന്റെ മുഴുവൻ subject DN-ഉം പുനരുൽപാദിപ്പിക്കണം. ഫീൽഡ് ക്രമം, വേർതിരിക്കികൾ, ഇടവേളകൾ, escaping എന്നിവയെല്ലാം കണക്കാക്കപ്പെടുന്നു, കാരണം താരതമ്യം എൻകോഡ് ചെയ്ത സ്ട്രിംഗിൽ തന്നെ നടക്കുന്നു. തരം ഒഴിവാക്കിയാൽ മൂന്നിൽ ഏറ്റവും കർശനമായ താരതമ്യം നിങ്ങൾ തിരഞ്ഞെടുത്തു. ദൃശ്യഭേദം രക്ഷിക്കുന്ന ഒരു സാധാരണീകരണ ഘട്ടവുമില്ല. ഇത് ആദ്യ നവീകരണത്തിന് മുമ്പ് അറിയേണ്ടതാണ്, അതിന് ശേഷമല്ല.

ആ കർശനത നവീകരണങ്ങൾക്കിടയിൽ ദുർബലമാണ്. ആട്രിബ്യൂട്ടുകൾ പുനഃക്രമീകരിക്കുന്ന, അധിക ഫീൽഡ് ചേർക്കുന്ന, അല്ലെങ്കിൽ ഒരു മൂല്യത്തിന്റെ escaping മാറ്റുന്ന CA ഒരേ യന്ത്രത്തിന് പുതിയ സ്ട്രിംഗ് സൃഷ്ടിക്കുന്നു, വർഷങ്ങളായി പ്രവർത്തിച്ച നിർദ്ദേശം അടുത്ത പ്രകാശനത്തിൽ പരാജയപ്പെടാൻ തുടങ്ങുന്നു. സ്വീകരിച്ച DN മാറ്റരേഖയിൽ സൂക്ഷിക്കുന്നത് അടുത്ത നവീകരണത്തെ ഒരു വ്യത്യാസമാക്കുന്നു. ഓപ്പറേറ്റർ പൂർണ്ണ DN പ്രസിദ്ധീകരിച്ച് അതിന്റെ രൂപത്തിന് ഉറപ്പ് നൽകുന്നിടത്ത് subject ന്യായമായ തിരഞ്ഞെടുപ്പാണ്; മറ്റിടങ്ങളിൽ ഇടുങ്ങിയ ഫീൽഡ് സത്യമായി നിലനിർത്താൻ എളുപ്പമാണ്.

name: ഒരു ഫീൽഡ്, സാധാരണയായി പൊതുനാമം

തരം name subject-ന്റെ ഒരു ഫീൽഡ് താരതമ്യം ചെയ്യുന്നു. പ്രൊഫൈൽ മറ്റൊന്ന് പറയുന്നില്ലെങ്കിൽ ആ ഫീൽഡ് പൊതുനാമമാണ്, പ്രതീക്ഷിത മൂല്യം കൃത്യമായി ആ ഫീൽഡാണ്, അതിന് ചുറ്റുമുള്ള DN അല്ല.

കെണി എന്തെന്നാൽ ആധുനിക സർട്ടിഫിക്കറ്റുകൾ സേവനനാമം എപ്പോഴും CN-ൽ ഇടുന്നില്ല. പലതും അത് subject-ന്റെ ഇതര പേരിൽ വഹിച്ച് CN കാലിയായോ പൊതുവായോ വിടുന്നു, അതിനാൽ ബ്രൗസർ സ്വീകരിക്കുന്ന സർട്ടിഫിക്കറ്റും ഈ താരതമ്യത്തിൽ പരാജയപ്പെടാം. പ്രതീക്ഷ എഴുതുന്നതിന് മുമ്പ് നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ നൽകിയ സർട്ടിഫിക്കറ്റ് പരിശോധിച്ച് പ്രൊഫൈൽ ഏത് ഫീൽഡ് തിരഞ്ഞെടുക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. കാലിയായ CN-നെ ഒരു പേരുമായി താരതമ്യം ചെയ്യുന്നത് പൊരുത്തക്കേടാണ്, കോൺഫിഗറേഷൻ അപകടമല്ല.

name-prefix: രൂപകൽപ്പനയിൽ വിശാലം, അതിനാൽ പരിധി നിർണ്ണയിക്കുക

ഒരു name-prefix തരത്തിലുള്ള പ്രതീക്ഷ തിരഞ്ഞെടുത്ത ഫീൽഡിന്റെ തുടക്കവുമായി പൊരുത്തപ്പെടുന്നു. ഇത് നാമകരണ സ്കീമിന് സൗകര്യപ്രദവും പങ്കിട്ട ഏതിനും അപകടകരവുമാണ്.

പ്രതീക്ഷ vpn.example ആണെങ്കിൽ, രണ്ടും vpn.example.com ഉം vpn.example.net ഉം കടക്കും, ബാക്കിയുള്ള ചങ്ങല വിശ്വസ്തമാണെങ്കിൽ. വിശാലതയാണ് സവിശേഷത, അതേസമയം രേഖാമൂലം ന്യായീകരിക്കേണ്ട ഭാഗവുമാണത്. CA-യും നാമകരണ സ്കീമും നിങ്ങളുടേതാണെങ്കിൽ പ്രിഫിക്സ് ന്യായമാണ്, പൊതു CA അതേ മാതൃകയിൽ പുറപ്പെടുവിക്കുമ്പോൾ വളരെ ദുർബലമാണ്. സ്കീമിന് വഴക്കം വേണമെങ്കിൽ ക്ലയന്റ് പരിശോധന വിശാലമാക്കുന്നതിന് പകരം CA-യിൽ പരിമിതപ്പെടുത്തുക.

ഐഡന്റിഫയറിൽ നിന്ന് തരം തിരഞ്ഞെടുക്കുക, പിന്നെ തെളിയിക്കുക

ഓപ്പറേറ്റർ ഉദ്ദേശിക്കുന്ന ഐഡന്റിറ്റിയിൽ നിന്ന് പിന്നോട്ട് പ്രവർത്തിക്കുക. പൂർണ്ണ DN പ്രസിദ്ധീകരിച്ച് അത് സ്ഥിരമായി നിർത്തുന്നുവെങ്കിൽ, subject അത് വ്യക്തമാക്കുന്നു. സേവനത്തെ പൊതുനാമത്തിൽ വിളിക്കുന്നുവെങ്കിൽ, ഉപയോഗിക്കുക name. നാമകരണ സ്കീം സ്വന്തമായുണ്ടെങ്കിൽ, അതിന്റെ മുഴുവൻ ഇടവും സ്വീകരിക്കുന്നുവെങ്കിൽ, name-prefix അത് വ്യക്തമായി പറയുന്നു.

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

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