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

Les først samsvarstypen og deretter teksten: et verify-x509-name direktiv kan se riktig ut og likevel godta et sertifikat du ikke mente å stole på. To linjer med samme forventede tekst, men ulike typer er ulike krav. Les typen først, deretter teksten. Behandle direktivet som ett vilkår til på forbindelsen, ikke som hele kontrollen.

Hva valget faktisk hevder

Direktivet navngir en identitet som motpartens sertifikat må bære. Når sammenligningen mislykkes, OpenVPN avbryter håndtrykket, og ingen tunnel kommer opp. Alt annet i profilen gjelder fortsatt: sertifikatet må kjede til en klarert CA, og rollekontrollen må bestå, så dette er et tilleggsvilkår og ikke en erstatning. En profil som oppfyller navneforventningen og feiler rollekontrollen er fortsatt ødelagt, og loggen sier vanligvis det.

Det er også annerledes enn vertsnavnvalideringen en nettleser gjør. En nettleser matcher navn mot subject-alternative navn etter reglene i TLS-stakken sin, mens OpenVPN sammenligner ett sertifikatfelt med typen du valgte. Derfor kan et innlimt nettleservertsnavn i direktivet gi et avvik selv når sertifikatet faktisk dekker tjenesten.

subject: det fullstendige særskilte navnet, tegn for tegn

Med subject, standarden når ingen type er skrevet, må den forventede verdien gjengi sertifikatets fulle subject-DN. Feltrekkefølge, skilletegn, mellomrom og escaping teller alt, fordi sammenligningen kjøres på strengen slik den er kodet. Utelater du typen, har du valgt den strengeste av de tre sammenligningene. Det finnes ikke noe normaliseringstrinn som redder en kosmetisk forskjell. Det er verdt å vite før den første fornyelsen, ikke etter.

Den strengheten er skjør gjennom fornyelser. En CA som omordner attributter, setter inn et ekstra felt eller endrer hvordan den escaper en verdi, lager en ny streng for samme maskin, og et direktiv som virket i årevis begynner å feile ved neste utstedelse. Å beholde den godtatte DN i endringsloggen gjør den neste fornyelsen til en forskjell. Der operatøren publiserer en full DN og garanterer formen, er subject et rimelig valg; andre steder er et smalere felt lettere å holde sant.

name: ett felt, vanligvis det vanlige navnet

Typen name sammenligner ett subject-felt. Med mindre profilen sier noe annet, er feltet det vanlige navnet, og den forventede verdien er nøyaktig det feltet, ikke DN-en rundt det.

Haken er at moderne sertifikater ikke alltid setter tjenestenavnet i CN. Mange bærer det i et subject-alternativt navn og lar CN stå tomt eller generisk, så et sertifikat en nettleser godtar fortsatt kan feile denne sammenligningen. Undersøk sertifikatet du faktisk fikk utstedt før du skriver forventningen, og bekreft hvilket felt profilen velger. En tom CN sammenlignet med et navn er et avvik, ikke et konfigurasjonsuhell.

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

En forventning av typen name-prefix matcher begynnelsen av det valgte feltet. Det er praktisk for et navneskjema og farlig for alt som deles.

Med vpn.example som forventning ville både vpn.example.com og vpn.example.net bestå, forutsatt at resten av kjeden er klarert. Bredden er funksjonen, og det er også delen som må begrunnes skriftlig. Et prefiks er rimelig når CA-en og navneskjemaet er dine, og mye svakere når en offentlig CA utsteder i samme mønster. Hvis skjemaet trenger fleksibilitet, begrens det ved CA-en i stedet for å utvide klientkontrollen.

Velg typen ut fra identifikatoren, og bevis det deretter

Arbeid baklengs fra identiteten operatøren har tenkt. Hvis de publiserer en full DN og holder den stabil, subject uttrykker det. Hvis de navngir tjenesten med det vanlige navnet, bruk name. Hvis de eier et navneskjema og godtar hele rommet, name-prefix sier det eksplisitt.

Fornyelser er der direktivet blir testet. Sammenlign den godkjente identiteten med det nye sertifikatet i stedet for med den gamle filen, fordi en ny endepunktadresse ikke betyr en ny sertifikatidentitet. Ikke slett direktivet bare fordi en kjent adresse svarer: tilgjengelighet og den tiltenkte motparten er forskjellige fakta, og adressen beviser bare at noe svarte. Skriv den nøyaktige feilen og de offentlige navnedetaljene i en renset rapport, fordi et navneavvik kan vises uten noe privat nøkkelmateriale.

Etter en støttet rettelse, koble til på nytt med alle tiltenkte kontroller aktivert, og verifiser ressursen du faktisk trenger. Suksess betyr at den tiltenkte serveren ble godtatt, ikke at et eller annet sertifikat ble presset gjennom. Den offisielle håndboken OpenVPN 2.6 manual dokumenterer de tre typene og tillitsnotatene deres, og det er referansen som siteres når et leverandørgrensesnitt er uenig med profilen.