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

Les først samsvarstypen og deretter teksten: eit verify-x509-name direktiv kan sjå riktig ut og likevel godta eit sertifikat du ikkje meinte å stole på. To linjer med same forventa tekst, men ulike typar er ulike krav. Les typen først, deretter teksten. Handsame direktivet som eit vilkår til på sambandet, ikkje som heile kontrollen.

Kva valet faktisk hevdar

Direktivet namngir ein identitet som sertifikatet til motparten må bera. Når samanlikninga mislukkast, OpenVPN bryt handtrykket av, og ingen tunnel kjem opp. Alt anna i profilen gjeld framleis: sertifikatet må kjedast til ein klarert CA, og rollekontrollen må gå gjennom, så dette er eit tilleggsvilkår og ikkje ei erstatning. Ein profil som oppfyller namneforventinga og feilar rollekontrollen er framleis øydelagd, og loggen seier vanlegvis det.

Det er òg annleis enn vertsnamnvalideringa ein nettlesar gjer. Ein nettlesar matchar namn mot subject-alternative namn etter reglane i TLS-stakken sin, medan OpenVPN samanliknar eitt sertifikatfelt med typen du valde. Difor kan eit innlimt nettlesarvertsnamn i direktivet gje eit avvik sjølv når sertifikatet faktisk dekkjer tenesta.

subject: det fullstendige særskilde namnet, teikn for teikn

Med subject, standarden når ingen type er skriven, må den forventa verdien attgje den fulle subject-DN-en til sertifikatet. Feltrekkjefølgje, skiljeteikn, mellomrom og escaping tel alt, fordi samanlikninga går på strengen slik han er koda. Utelèt du typen, har du valt den strengaste av dei tre samanlikningane. Det finst ingen normaliseringstrinn som reddar ein kosmetisk skilnad. Det er verdt å vite før den første fornyinga, ikkje etter.

Den strengskapen er skjør gjennom fornyingar. Ein CA som omordnar attributt, set inn eit ekstra felt eller endrar korleis han escapar ein verdi, lagar ein ny streng for same maskin, og eit direktiv som verka i årevis byrjar å feile ved neste utferding. Å halde den godtekne DN-en i endringsloggen gjer den neste fornyinga til ein skilnad. Der operatøren publiserer ein full DN og garanterer forma, er subject eit rimeleg val; andre stader er eit smalare felt lettare å halde sant.

name: eitt felt, vanlegvis det vanlege namnet

Typen name samanliknar eitt subject-felt. Med mindre profilen seier noko anna, er feltet det vanlege namnet, og den forventa verdien er nøyaktig det feltet, ikkje DN-en rundt det.

Haken er at moderne sertifikat ikkje alltid set tenestenamnet i CN. Mange ber det i eit subject-alternativt namn og lèt CN stå tomt eller generisk, så eit sertifikat ein nettlesar godtek framleis kan feile denne samanlikninga. Undersøk sertifikatet du faktisk fekk utferda før du skriv forventinga, og stadfest kva felt profilen vel. Ein tom CN samanlikna med eit namn er eit avvik, ikkje eit konfigurasjonsuhell.

name-prefix: breitt av design, så avgrens det

Ei forventing av typen name-prefix matchar byrjinga av det valde feltet. Det er praktisk for eit namneskjema og farleg for alt som vert delt.

Med vpn.example som forventing ville både vpn.example.com og vpn.example.net gå gjennom, føresett at resten av kjeda er klarert. Breidda er funksjonen, og det er òg delen som må grunngjevast skriftleg. Eit prefiks er rimeleg når CA-en og namneskjemaet er dine, og mykje svakare når ein offentleg CA utferdar i same mønster. Viss skjemaet treng fleksibilitet, avgrens det ved CA-en i staden for å utvide klientkontrollen.

Vel typen ut frå identifikatoren, og prov det deretter

Arbeid baklengs frå identiteten operatøren har tenkt. Viss dei publiserer ein full DN og held han stabil, subject uttrykkjer det. Viss dei namngir tenesta med det vanlege namnet, bruk name. Viss dei eig eit namneskjema og godtek heile rommet, name-prefix seier det eksplisitt.

Fornyingar er der direktivet vert testa. Samanlikn den godkjende identiteten med det nye sertifikatet i staden for med den gamle fila, fordi ei ny endepunktadresse ikkje tyder ein ny sertifikatidentitet. Ikkje slett direktivet berre fordi ei kjend adresse svarar: tilgjenge og den tiltenkte motparten er ulike faktum, og adressa beviser berre at noko svara. Skriv den nøyaktige feilen og dei offentlege namnedetaljane i ein reinsa rapport, fordi eit namneavvik kan visast utan noko privat nøkkelmateriale.

Etter ei støtta retting, kople til på nytt med alle tiltenkte kontrollar aktiverte, og verifiser ressursen du faktisk treng. Suksess tyder at den tiltenkte serveren vart godteken, ikkje at eit eller anna sertifikat vart pressa gjennom. Den offisielle handboka OpenVPN 2.6 manual dokumenterer dei tre typane og tillitsnotata deira, og det er referansen som vert sitert når eit leverandørgrensesnitt er usamd med profilen.