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

Lês earst it oerienkomtstype en dan de tekst: in verify-x509-name rjochtline kin der goed útsjen en dochs in sertifikaat akseptearje dêr't jo net op fertrouwe woenen. Twa rigels mei deselde ferwachte tekst, mar ferskillende typen binne ferskillende easken. Lês earst it type, dan de tekst. Behannelje de rjochtline as noch ien betingst foar de ferbining, net as de hiele kontrôle.

Wat de opsje eins beweart

De rjochtline neamt in identiteit dy't it sertifikaat fan de oare kant drage moat. As de ferliking mislearret, OpenVPN brekt de hânskudden ôf en der komt gjin tunnel omheech. Al it oare yn it profyl jildt noch: it sertifikaat moat keateningje nei in fertroude CA en de rolkontrôle moat slagje, dus dit is in ekstra betingst en gjin ferfanging. In profyl dat oan de nammeferwachting foldocht en de rolkontrôle mist, is noch hieltyd stikken, en it logboek seit dat ornaris.

It ferskilt ek fan 'e hostnamme-falidaasje fan in browser. In browser ferliket nammen mei alternative nammen fan 'e subject neffens de regels fan syn TLS-stapel, wylst OpenVPN ien sertifikaatfjild ferliket mei it type dat jo keazen hawwe. Dêrom kin in plakt hostnamme yn browserstyl yn 'e rjochtline in ôfwiking jaan, sels as it sertifikaat de tsjinst echt beslacht.

subject: de folsleine ûnderskiedende namme, teken foar teken

Mei subject, de standert as gjin type skreaun is, moat de ferwachte wearde de folsleine subject-DN fan it sertifikaat werjaan. Fjildfolchoarder, skiedingstekens, spaasjes en escaping telle allegear, om't de ferliking op 'e tekenrige rint sa't dy kodearre is. Lit jo it type wei, dan hawwe jo de strangste fan 'e trije ferlikingen keazen. Der is gjin normalisaasjestap dy't in kosmetysk ferskil rêdt. Dat is wittensweardich foar de earste fernijing, net dernei.

Dy strangens is brekber oer fernijingen hinne. In CA dy't attributen oardert, in ekstra fjild ynfoeget of feroaret hoe't er in wearde escaped, produsearret in nije tekenrige foar deselde masine, en in rjochtline dy't jierren wurke hat, begjint by de folgjende útjefte te mislearjen. It akseptearre DN yn it feroaringslog hâlde makket fan 'e folgjende fernijing in ferskil. Wêr't de operator in folsleine DN publisearret en de foarm derfan garandearret, is subject in ridlike kar; earne oars is in smeller fjild makliker wier te hâlden.

name: ien fjild, meastal de gewoane namme

It type name ferliket ien subject-fjild. Utsein it profyl oars seit, is dat fjild de gewoane namme, en de ferwachte wearde is krekt dat fjild, net de DN deromhinne.

De fâle is dat moderne sertifikaten de tsjinstnamme net altyd yn 'e CN sette. In protte drage it yn in alternative namme fan 'e subject en litte de CN leech of algemien, dat in sertifikaat dat in browser akseptearret kin dochs foar dizze ferliking mislearje. Besjoch it sertifikaat dat jo echt útjûn is foardat jo de ferwachting skriuwe, en befêstigje hokker fjild it profyl kiest. In lege CN ferlike mei in namme is in ôfwiking, gjin konfiguraasje-ûngemak.

name-prefix: breed by ûntwerp, dus behein it berik

In ferwachting fan it type name-prefix komt oerien mei it begjin fan it keazen fjild. Dat is handich foar in nammejouwingsskema en gefaarlik foar alles dat dield wurdt.

Mei vpn.example as ferwachting soe sawol vpn.example.com as vpn.example.net trochkomme, mits de rest fan 'e keatling fertroud is. De breedte is de funksje, en it is ek it diel dat skriftlik ferantwurde wurde moat. In foarheaksel is ridlik as de CA en it nammejouwingsskema fan jo binne, en folle swakker as in iepenbiere CA yn itselde patroan útjout. As it skema fleksibiliteit nedich hat, behein it dan by de CA ynstee fan 'e kliïntkontrôle te ferbreedzjen.

Kies it type út 'e identifikator, bewiis it dan

Wurkje efterstfoar út 'e identiteit dy't de operator bedoelt. As hy in folsleine DN publisearret en dy stabyl hâldt, subject drukt dat út. As hy de tsjinst by gewoane namme neamt, brûk name. As hy in nammejouwingsskema hat en de hiele romte derfan akseptearret, name-prefix seit dat eksplisyt.

Fernijingen binne wêr't de rjochtline test wurdt. Ferlykje de goedkarde identiteit mei it nije sertifikaat ynstee fan mei it âlde bestân, om't in nij einpuntadres gjin nije sertifikaatidentiteit betsjut. Ferwiderje de rjochtline net allinnich om't in fertroud adres antwurdet: berikberens en de bedoelde oare kant binne ferskillende feiten, en it adres bewiist allinnich dat der wat antwurde. Skriuw de krekte fout en de iepenbiere nammebylden yn in skjinne rapport, om't in namme-ôfwiking sjen litten wurde kin sûnder hokker priveekaaistof dan ek.

Nei in stipete ferbettering ferbine jo opnij mei alle bedoelde kontrôles oan en ferifiearje it helpboarn dy't jo echt nedich hawwe. Sukses betsjut dat de bedoelde server akseptearre waard, net dat der in sertifikaat trochkrongen is. It offisjele hânboek OpenVPN 2.6 manual dokumintearret de trije typen en har fertrouwensnotysjes, en it is de referinsje om oan te heljen as in leveransier-ynterface it net iens is mei it profyl.