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

Læs først matchtypen og derefter teksten: en verify-x509-name direktiv kan se korrekt ud og alligevel acceptere et certifikat, du ikke havde til hensigt at stole på. To linjer med samme forventede tekst, men forskellige typer er forskellige krav. Læs typen først, derefter teksten. Behandl direktivet som endnu en betingelse for forbindelsen, ikke som hele kontrollen.

Hvad valget egentlig hævder

Direktivet navngiver en identitet, som modpartens certifikat skal bære. Når sammenligningen mislykkes, OpenVPN afbryder håndtrykket, og der kommer ingen tunnel op. Alt andet i profilen gælder stadig: certifikatet skal kæde til en betroet CA, og rollekontrollen skal bestå, så dette er en ekstra betingelse og ikke en erstatning. En profil, der opfylder navneforventningen og fejler rollekontrollen, er stadig i stykker, og loggen siger det som regel.

Det er også anderledes end den værtsnavnsvalidering, en browser udfører. En browser matcher navne mod subject-alternative navne efter reglerne i sin TLS-stak, mens OpenVPN sammenligner ét certifikatfelt med den valgte type. Derfor kan et indsat browserværtsnavn i direktivet give en uoverensstemmelse, selv når certifikatet reelt dækker tjenesten.

subject: det fulde særlige navn, tegn for tegn

Med subject, standarden når ingen type er skrevet, skal den forventede værdi gengive certifikatets fulde subject-DN. Feltorden, separatorer, mellemrum og escaping tæller alt, fordi sammenligningen kører på strengen som kodet. Udelader du typen, har du valgt den strengeste af de tre sammenligninger. Der er intet normaliseringstrin, der redder en kosmetisk forskel. Det er værd at vide før den første fornyelse, ikke efter.

Den strenghed er skrøbelig gennem fornyelser. En CA, der omarrangerer attributter, indsætter et ekstra felt eller ændrer, hvordan den escaper en værdi, producerer en ny streng for den samme maskine, og et direktiv, der virkede i årevis, begynder at fejle ved næste udstedelse. At gemme den accepterede DN i ændringsloggen gør den næste fornyelse til en forskel. Hvor operatøren offentliggør en fuld DN og garanterer dens form, er subject et rimeligt valg; andre steder er et smallere felt lettere at holde sandt.

name: ét felt, normalt det fælles navn

Typen name sammenligner ét subject-felt. Medmindre profilen siger andet, er feltet det fælles navn, og den forventede værdi er præcis det felt, ikke DN'en omkring det.

Fælden er, at moderne certifikater ikke altid sætter tjenestenavnet i CN. Mange bærer det i et subject-alternativt navn og lader CN være tomt eller generisk, så et certifikat, en browser accepterer, stadig kan fejle denne sammenligning. Undersøg det certifikat, du faktisk fik udstedt, før du skriver forventningen, og bekræft, hvilket felt profilen vælger. Et tomt CN sammenlignet med et navn er en uoverensstemmelse, ikke et konfigurationsuheld.

name-prefix: bredt efter design, så afgræns det

En forventning af typen name-prefix matcher begyndelsen af det valgte felt. Det er bekvemt for et navngivningsskema og farligt for alt, der deles.

Med vpn.example som forventning ville både vpn.example.com og vpn.example.net bestå, forudsat at resten af kæden er betroet. Bredden er funktionen, og det er også den del, der skal begrundes skriftligt. Et præfiks er rimeligt, når CA'en og navngivningsskemaet er dine, og meget svagere, når en offentlig CA udsteder i samme mønster. Hvis skemaet kræver fleksibilitet, begræns det ved CA'en i stedet for at udvide klientkontrollen.

Vælg typen ud fra identifikatoren, og bevis det derefter

Arbejd baglæns fra den identitet, operatøren tilsigter. Hvis de offentliggør en fuld DN og holder den stabil, subject udtrykker det. Hvis de navngiver tjenesten ved det fælles navn, brug name. Hvis de ejer et navngivningsskema og accepterer hele dets rum, name-prefix siger det eksplicit.

Fornyelser er, hvor direktivet bliver testet. Sammenlign den godkendte identitet med det nye certifikat i stedet for med den gamle fil, fordi en ny slutpunktsadresse ikke betyder en ny certifikatidentitet. Slet ikke direktivet, bare fordi en velkendt adresse svarer: tilgængelighed og den tilsigtede modpart er forskellige fakta, og adressen beviser kun, at noget svarede. Skriv den præcise fejl og de offentlige navnedetaljer i en renset rapport, fordi en navnemismatch kan vises uden noget privat nøglemateriale.

Efter en understøttet rettelse, forbind igen med alle tilsigtede kontroller aktiveret, og verificér den ressource, du faktisk har brug for. Succes betyder, at den tilsigtede server blev accepteret, ikke at et eller andet certifikat blev gennemtvunget. Den officielle manual OpenVPN 2.6 manual dokumenterer de tre typer og deres tillidsnoter, og den er referencen at citere, når en leverandørs grænseflade er uenig med profilen.