OpenVPN verify-x509-name: onderwerp, naam en voorvoegsel

Lees eers die tipe vergelyking en dan die teks: 'n verify-x509-name richtlijn kan korrek lyk en tog 'n sertifikaat aanvaar wat jy nie bedoel het om te vertrou nie. Twee reëls met dieselfde verwagte teks maar verskillende tipes is verskillende vereistes. Lees eers die tipe en dan die teks. Behandel die richtlijn as nog een voorwaarde vir die verbinding, nie as die hele kontrole nie.

Wat die opsie werklik vasstel

Die richtlijn noem 'n identiteit wat die eweknie-sertifikaat moet dra. Wanneer die vergelyking misluk, OpenVPN staak die handskud en geen tonnel kom op nie. Alles anders in die profiel geld steeds: die sertifikaat moet aan 'n vertroude CA koppel, en die roliekontrole moet slaag, so dit is 'n bykomende voorwaarde en nie 'n plaasvervanger nie. 'n Profiel wat die naamverwagting bevredig en die roliekontrole faal, is steeds stukkend, en die logboek sê dit gewoonlik.

Dit verskil ook van die gasheernaamvalidering wat 'n blaaier doen. 'n Blaaier pas name teen vakalternatiewe name toe volgens die reëls van sy TLS-stapel, terwyl OpenVPN een sertifikaatveld vergelyk met die tipe wat jy gekies het. Dit is waarom die plak van 'n blaaierstyl gasheernaam in die richtlijn 'n wanpassing kan lewer selfs wanneer die sertifikaat werklik die diens dek.

subject: die volle onderskeidende naam, karakter vir karakter

Met subject, die standaard wanneer geen tipe geskryf word nie, moet die verwagte waarde die sertifikaat se hele subjek-DN reproduseer. Veldorde, skeiers, spasiëring en ontsnapping tel alles, want die vergelyking loop op die string soos geënkodeer. Laat die tipe weg en jy het die strengste van die drie vergelykings gekies. Daar is geen normaliseringstap om 'n kosmetiese verskil te red nie. Dit is die moeite werd om voor die eerste hernuwing te weet, nie daarna nie.

Daardie strengheid is broos oor hernuwings heen. 'n CA wat attribure herrangskik, 'n ekstra veld invoeg of verander hoe dit 'n waarde ontsnap, produseer 'n nuwe string vir dieselfde masjien, en 'n richtlijn wat jare lank gewerk het, begin by die volgende uitreiking faal. Om die aanvaarde DN in die veranderingsrekord te hou, maak die volgende hernuwing 'n verskil. Waar die operateur 'n volle DN publiseer en die vorm daarvan waarborg, is subject 'n redelike keuse; elders is 'n smaller veld makliker om waar te hou.

name: een veld, gewoonlik die algemene naam

Die name tipe vergelyk 'n enkele subjekveld. Tensy die profiel anders sê, is daardie veld die algemene naam, en die verwagte waarde is presies daardie veld, nie die DN daaromheen nie.

Die vangnet is dat moderne sertifikate nie altyd die diensnaam in die CN sit nie. Baie dra dit in 'n vakalternatiewe naam en laat die CN leeg of generies, so 'n sertifikaat wat 'n blaaier aanvaar, kan steeds hierdie vergelyking faal. Inspekteer die sertifikaat wat jy werklik uitgereik is voordat jy die verwagting skryf, en bevestig watter veld die profiel kies. 'n Leë CN teen 'n naam vergelyk is 'n wanpassing, nie 'n konfigurasie-ongeluk nie.

name-prefix: breed van ontwerp, so beperk die omvang

'n Verwagting van die tipe name-prefix pas by die begin van die gekose veld. Dit is gerieflik vir 'n naamskema en gevaarlik vir enigiets wat gedeel word.

Met vpn.example as die verwagting, sou beide vpn.example.com en vpn.example.net slaag, mits die res van die ketting vertrou word. Die breedte is die kenmerk, en dit is ook die deel wat skriftelik geregverdig moet word. 'n Voorvoegsel is redelik wanneer die CA en die naamskema joune is, en baie swakker wanneer 'n openbare CA in dieselfde patroon uitreik. As die skema buigsaamheid nodig het, beperk dit by die CA eerder as om die kliëntkontrole te verbreed.

Kies die tipe uit die identiteit en bewys dit dan

Werk terug vanaf die identiteit wat die operateur bedoel. As hulle 'n volle DN publiseer en dit stabiel hou, subject druk dit uit. As hulle die diens by algemene naam noem, gebruik name. As hulle 'n naamskema besit en die hele ruimte daarvan aanvaar, name-prefix sê dit uitdruklik.

Hernuwings is waar die richtlijn getoets word. Vergelyk die goedgekeurde identiteit teen die nuwe sertifikaat eerder as teen die ou lêer, want 'n nuwe eindpuntadres beteken nie 'n nuwe sertifikaatidentiteit nie. Moenie die richtlijn skrap net omdat 'n bekende adres antwoord nie: bereikbaarheid en die beoogde eweknie is verskillende feite, en die adres bewys net dat iets geantwoord het. Teken die presiese fout en die openbare naam-besonderhede in 'n gesaneerde verslag op, want 'n naamwanpassing kan gewys word sonder enige private-sleutelmateriaal.

Na 'n ondersteunde regstelling, verbind weer met elke beoogde kontrole geaktiveer en verifieer die hulpbron wat jy werklik nodig het. Sukses beteken die beoogde bediener is aanvaar, nie dat een of ander sertifikaat deurgedruk is nie. Die amptelike handleiding OpenVPN 2.6 manual dokumenteer die drie tipes en hulle vertrouensnotas, en dit is die verwysing om aan te haal wanneer 'n verskaffer se koppelvlak met die profiel verskil.