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

Unue legu la kongruan tipon, poste la tekston: verify-x509-name direktivo povas ŝajni ĝusta kaj tamen akcepti atestilon, kiun vi ne intencis fidi. Du linioj kun identa atendata teksto sed malsamaj tipoj estas malsamaj postuloj. Unue legu la tipon, poste la tekston. Traktu la direktivon kiel plian kondiĉon de la konekto, ne kiel la tutan kontrolon.

Kion la opcio fakte asertas

La direktivo nomas identecon, kiun la atestilo de la alia flanko devas porti. Kiam la komparo malsukcesas, OpenVPN ĉesigas la manpremon kaj neniu tunelo ekestas. Ĉio alia en la profilo restas valida: la atestilo devas ĉeni al fidinda CA, kaj la rola kontrolo devas sukcesi, do tio estas plia kondiĉo, ne anstataŭaĵo. Profilo, kiu plenumas la nomatendon kaj malsukcesas la rolan kontrolon, restas difektita, kaj la protokolo kutime diras tion.

Ĝi ankaŭ malsamas de la gastigantnoma validigo, kiun faras retumilo. Retumilo kongruigas nomojn kun alternativaj nomoj de la subject laŭ la reguloj de sia TLS-stako, dum OpenVPN komparas unu atestilan kampon per la tipo, kiun vi elektis. Tial enmeti retumilan gastigantnomon en la direktivon povas produkti malkongruon eĉ kiam la atestilo vere kovras la servon.

subject: la tuta distinga nomo, litero post litero

Kun subject, la defaŭlto kiam neniu tipo estas skribita, la atendata valoro devas reprodukti la tutan subject-DN de la atestilo. Kampordo, apartigiloj, interspacoj kaj eskapado ĉiuj gravas, ĉar la komparo rulas sur la ĉeno tiel, kiel ĝi estas kodita. Se vi forlasas la tipon, vi elektis la plej striktan el la tri komparoj. Ne ekzistas normaliga paŝo, kiu savus kosmetikan diferencon. Tion indas scii antaŭ la unua renovigo, ne poste.

Tiu strikteco estas rompiĝema tra renovigoj. CA, kiu reordigas atributojn, enmetas kroman kampon aŭ ŝanĝas la eskapadon de valoro, produktas novan ĉenon por la sama maŝino, kaj direktivo, kiu funkciis jarojn, komencas malsukcesi ĉe la sekva eldono. Konservi la akceptitan DN en la ŝanĝprotokolo turnas la sekvan renovigon en diferencon. Kie la administranto publikigas tutan DN kaj garantias ĝian formon, subject estas prudenta elekto; aliloke pli mallarĝa kampo estas pli facile tenebla vera.

name: unu kampo, kutime la komuna nomo

La tipo name komparas unu subject-kampon. Se la profilo ne diras alie, tiu kampo estas la komuna nomo, kaj la atendata valoro estas ĝuste tiu kampo, ne la DN ĉirkaŭ ĝi.

La kaptilo estas, ke modernaj atestiloj ne ĉiam metas la servan nomon en la CN. Multaj portas ĝin en alternativa nomo de la subject kaj lasas la CN malplena aŭ ĝenerala, do atestilo, kiun retumilo akceptas, povas tamen malsukcesi ĉi tiun komparon. Ekzamenu la atestilon, kiu estis fakte eldonita al vi, antaŭ ol skribi la atendo, kaj konfirmu, kiun kampon la profilo elektas. Malplena CN komparata kun nomo estas malkongruo, ne agorda akcidento.

name-prefix: larĝa laŭ intenco, do limigu la amplekson

Atendo de tipo name-prefix kongruas kun la komenco de la elektita kampo. Tio estas oportuna por nomiga skemo kaj danĝera por io ajn dividita.

Kun vpn.example kiel atendo, pasus kaj vpn.example.com kaj vpn.example.net kondiĉe ke la resto de la ĉeno estas fidinda. La larĝeco estas la trajto, kaj same la parto, kiun oni devus pravigi skribe. Prefikso estas prudenta, kiam la CA kaj la nomiga skemo estas viaj, kaj multe pli malforta, kiam publika CA eldonas en la sama ŝablono. Se la skemo bezonas fleksecon, limigu ĝin ĉe la CA anstataŭ larĝigi la klientan kontrolon.

Elektu la tipon el la identigilo, poste pruvu ĝin

Laboru malantaŭen de la identeco, kiun la administranto intencas. Se li publikigas tutan DN kaj tenas ĝin stabila, subject esprimas tion. Se li nomas la servon per la komuna nomo, uzu name. Se li posedas nomigan skemon kaj akceptas ĝian tutan spacon, name-prefix diras tion eksplicite.

Renovigoj estas kie la direktivo estas testata. Komparu la aprobitan identecon kun la nova atestilo, ne kun la malnova dosiero, ĉar nova finpunkta adreso ne implicas novan atestilan identecon. Ne forigu la direktivon nur ĉar konata adreso respondas: atingebleco kaj la intencita partnero estas malsamaj faktoj, kaj la adreso pruvas nur, ke io respondis. Notu la precizan eraron kaj la publikajn detalojn de la nomo en purigita raporto, ĉar nommalkongruo povas esti montrata sen ajna privata ŝlosilmaterialo.

Post subtenata korekto, rekonektu kun ĉiuj intencitaj kontroloj ŝaltitaj kaj kontrolu la rimedon, kiun vi vere bezonas. Sukceso signifas, ke la intencita servilo estis akceptita, ne ke iu atestilo estis puŝita tra. La oficiala manlibro OpenVPN 2.6 manual dokumentas la tri tipojn kaj iliajn fido-notojn, kaj ĝi estas la referenco citenda, kiam vendista interfaco malakordas kun la profilo.