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

Basahin muna ang uri ng pagtutugma, pagkatapos ang teksto: isang verify-x509-name direktiba ay maaaring magmukhang tama at tanggapin pa rin ang sertipiko na hindi mo sinadyang pagkatiwalaan. Dalawang linya na may parehong inaasahang teksto ngunit magkaibang uri ay dalawang magkaibang pangangailangan. Basahin muna ang uri, pagkatapos ang teksto. Ituring ang direktiba na isa pang kundisyon sa koneksyon, hindi ang buong pagsusuri.

Ano ang talagang pinapahayag ng opsyong ito

Pinangalanan ng direktiba ang pagkakakilanlang dapat taglayin ng sertipiko ng kabilang panig. Kapag nabigo ang paghahambing, OpenVPN hinihinto ng OpenVPN ang pakikipagkamay at walang lagusan na tumatayo. Lahat ng iba pa sa profile ay nalalapat pa rin: kailangang magkadena ang sertipiko sa pinagkakatiwalaang CA at kailangang pumasa ang pagsusuri ng tungkulin, kaya ito ay karagdagang kundisyon at hindi kapalit. Ang profile na tumutugon sa inaasahan ng pangalan ngunit nabigo sa pagsusuri ng tungkulin ay sira pa rin, at karaniwang sinasabi ito ng log.

Iba rin ito sa pagpapatunay ng pangalan ng host na ginagawa ng browser. Itinatugma ng browser ang mga pangalan sa mga alternatibong pangalan ng subject ayon sa mga tuntunin ng TLS stack nito, samantalang inihahambing ng OpenVPN ang isang field ng sertipiko sa uring pinili mo. Kaya ang pag-paste ng pangalan ng host na parang browser sa direktiba ay maaaring magdulot ng hindi pagkakatugma kahit tunay na sinasaklaw ng sertipiko ang serbisyo.

subject: ang buong natatanging pangalan, titik sa titik

Kapag walang nakasulat na uri, ang default ay subject, at ang inaasahang halaga ay dapat muling likhain ang buong subject DN ng sertipiko. Lahat ng pagkakasunod-sunod ng field, mga separator, puwang at escaping ay binibilang, dahil ang paghahambing ay tumatakbo sa string ayon sa pagkaka-encode. Kung aalisin mo ang uri, pinili mo ang pinakamahigpit sa tatlong paghahambing. Walang hakbang ng normalisasyon na makakapagligtas ng kosmetikong pagkakaiba. Sulit itong malaman bago ang unang pag-renew, hindi pagkatapos.

Ang higpit na iyon ay marupok sa pagitan ng mga pag-renew. Ang CA na muling nagsasaayos ng mga attribute, naglalagay ng karagdagang field o nagbabago kung paano nag-e-escape ng halaga ay gumagawa ng bagong string para sa parehong makina, at ang direktibang gumana nang maraming taon ay nagsisimulang mabigo sa susunod na paglabas. Ang pagtago ng tinanggap na DN sa talaan ng mga pagbabago ay ginagawang pagkakaiba ang susunod na pag-renew. Kung saan inilalathala ng operator ang buong DN at ginagarantiyahan ang hugis nito, ang subject ay makatwirang pagpipilian; sa ibang lugar, ang mas makitid na field ay mas madaling panatilihing totoo.

name: isang field, karaniwang ang karaniwang pangalan

Inihahambing ng uri name ang isang field ng subject. Maliban kung sinasabi ng profile ang kabaligtaran, ang field na iyon ay ang karaniwang pangalan, at ang inaasahang halaga ay eksaktong ang field na iyon, hindi ang DN sa paligid nito.

Ang bitag ay hindi laging inilalagay ng mga modernong sertipiko ang pangalan ng serbisyo sa CN. Marami ang nagdadala nito sa alternatibong pangalan ng subject at iniiwan ang CN na blangko o pangkalahatan, kaya ang sertipikong tinatanggap ng browser ay maaari pa ring mabigo sa paghahambing na ito. Suriin ang sertipikong tunay na ibinigay sa iyo bago isulat ang inaasahan, at tiyakin kung aling field ang pinipili ng profile. Ang blangkong CN na inihambing sa isang pangalan ay hindi pagkakatugma, hindi aksidente sa pagsasaayos.

name-prefix: malawak ayon sa disenyo, kaya limitahan ang saklaw

Ang inaasahang uri name-prefix ay tumutugma sa simula ng piniling field. Iyon ay maginhawa para sa isang iskema ng pagpapangalan at mapanganib para sa anumang ibinabahagi.

Kung ang inaasahan ay vpn.example , ang parehong vpn.example.com at vpn.example.net ay papasa, sa kondisyon na ang natitirang bahagi ng kadena ay pinagkakatiwalaan. Ang lapad ang tampok, at ito rin ang bahaging kailangang bigyang-katwiran sa sulat. Ang unlapi ay makatwiran kapag ang CA at ang iskema ng pagpapangalan ay sa iyo, at mas mahina kapag ang pampublikong CA ay naglalabas sa parehong huwaran. Kung kailangan ng iskema ng kakayahang umangkop, limitahan ito sa CA sa halip na palawakin ang pagsusuri ng kliyente.

Piliin ang uri mula sa identifier, pagkatapos patunayan ito

Magtrabaho nang paatras mula sa pagkakakilanlang nilalayon ng operator. Kung inilalathala niya ang buong DN at pinapanatili itong matatag, subject iyon ang ipinapahayag. Kung pinangalanan niya ang serbisyo sa karaniwang pangalan, gamitin name . Kung nagmamay-ari siya ng iskema ng pagpapangalan at tinatanggap ang buong espasyo nito, name-prefix sinasabi ito nang malinaw.

Ang mga pag-renew ang lugar kung saan sinusubok ang direktiba. Ihambing ang aprubadong pagkakakilanlan sa bagong sertipiko sa halip na sa lumang file, dahil ang bagong address ng endpoint ay hindi nangangahulugang bagong pagkakakilanlan ng sertipiko. Huwag burahin ang direktiba dahil lamang may tumutugon sa pamilyar na address: ang maabot at ang nilalayong kabilang panig ay magkaibang katotohanan , at ang address ay nagpapatunay lamang na may tumugon. Itala ang eksaktong error at ang pampublikong detalye ng pangalan sa isang nilinis na ulat, dahil ang hindi pagkakatugma ng pangalan ay maipapakita nang walang anumang materyal na pribadong key.

Pagkatapos ng suportadong pagwawasto, kumonekta muli nang naka-enable ang lahat ng nilalayong pagsusuri at i-verify ang resource na talagang kailangan mo. Ang tagumpay ay nangangahulugang tinanggap ang nilalayong server, hindi na pinilit na makalusot ang ilang sertipiko. Ang opisyal na manwal OpenVPN 2.6 manual ay nagdodokumento ng tatlong uri at ng mga tala nito sa pagtitiwala, at ito ang sangguniang sinisipi kapag ang interface ng vendor ay hindi sumasang-ayon sa profile.