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

Lees eerst het matchtype en dan de tekst: een verify-x509-name richtlijn kan er correct uitzien en toch een certificaat accepteren dat u niet wilde vertrouwen. Twee regels met dezelfde verwachte tekst maar verschillende typen zijn verschillende eisen. Lees eerst het type en dan de tekst. Behandel de richtlijn als nog een voorwaarde voor de verbinding, niet als de hele controle.

Wat de optie werkelijk beweert

De richtlijn noemt een identiteit die het certificaat van de andere partij moet dragen. Als de vergelijking mislukt, OpenVPN breekt de handshake af en er komt geen tunnel op. Al het overige in het profiel geldt nog steeds: het certificaat moet aan een vertrouwde CA koppelen en de rolcontrole moet slagen, dus dit is een extra voorwaarde en geen vervanging. Een profiel dat aan de naamverwachting voldoet en de rolcontrole niet haalt, is nog steeds stuk, en het log zegt dat meestal.

Het verschilt ook van de hostnaamvalidatie die een browser doet. Een browser vergelijkt namen met de alternatieve namen van het subject volgens de regels van zijn TLS-stack, terwijl OpenVPN één certificaatveld vergelijkt met het type dat u koos. Daarom kan een geplakte hostnaam in browserstijl in de richtlijn een afwijking opleveren, zelfs als het certificaat de dienst echt dekt.

subject: de volledige distinguished name, teken voor teken

Met subject, de standaard wanneer geen type is geschreven, moet de verwachte waarde de volledige subject-DN van het certificaat weergeven. Veldvolgorde, scheidingstekens, spaties en escaping tellen allemaal, omdat de vergelijking op de tekenreeks draait zoals die is gecodeerd. Laat u het type weg, dan hebt u de strengste van de drie vergelijkingen gekozen. Er is geen normalisatiestap die een cosmetisch verschil redt. Dat is voor de eerste verlenging de moeite van het weten waard, niet erna.

Die strengheid is broos tussen verlengingen. Een CA die attributen herordent, een extra veld invoegt of verandert hoe zij een waarde escapet, levert een nieuwe tekenreeks voor dezelfde machine, en een richtlijn die jaren werkte begint bij de volgende uitgifte te falen. De geaccepteerde DN in het wijzigingslog bewaren maakt van de volgende verlenging een verschil. Waar de operator een volledige DN publiceert en de vorm ervan garandeert, is subject een redelijke keuze; elders is een smaller veld gemakkelijker waar te houden.

name: één veld, meestal de common name

Het type name vergelijkt één subjectveld. Tenzij het profiel anders zegt, is dat veld de common name, en de verwachte waarde is precies dat veld, niet de DN eromheen.

De valkuil is dat moderne certificaten de dienstnaam niet altijd in de CN zetten. Veel ervan dragen die in een alternatieve subjectnaam en laten de CN leeg of generiek, zodat een certificaat dat een browser accepteert deze vergelijking alsnog kan falen. Bekijk het certificaat dat u werkelijk is uitgegeven voordat u de verwachting schrijft, en bevestig welk veld het profiel kiest. Een lege CN vergeleken met een naam is een afwijking, geen configuratie-ongeluk.

name-prefix: bewust breed, dus begrens de reikwijdte

Een verwachting van het type name-prefix komt overeen met het begin van het gekozen veld. Dat is handig voor een naamgevingsschema en gevaarlijk voor alles wat gedeeld wordt.

Met vpn.example als verwachting zouden zowel vpn.example.com als vpn.example.net slagen, mits de rest van de keten vertrouwd is. De breedte is de functie, en tegelijk het deel dat schriftelijk gerechtvaardigd moet worden. Een prefix is redelijk wanneer de CA en het naamgevingsschema van u zijn, en veel zwakker wanneer een publieke CA in hetzelfde patroon uitgeeft. Als het schema flexibiliteit nodig heeft, begrens het bij de CA in plaats van de clientcontrole te verruimen.

Kies het type op basis van de identiteit en bewijs het dan

Werk terug vanaf de identiteit die de operator bedoelt. Als hij een volledige DN publiceert en die stabiel houdt, subject drukt dat uit. Als hij de dienst met de common name aanduidt, gebruik name. Als hij een naamgevingsschema bezit en de hele ruimte ervan accepteert, name-prefix zegt dat expliciet.

Verlengingen zijn waar de richtlijn wordt getest. Vergelijk de goedgekeurde identiteit met het nieuwe certificaat in plaats van met het oude bestand, want een nieuw eindpuntadres betekent geen nieuwe certificaatidentiteit. Verwijder de richtlijn niet alleen omdat een vertrouwd adres antwoordt: bereikbaarheid en de beoogde andere partij zijn verschillende feiten, en het adres bewijst alleen dat er iets antwoordde. Leg de exacte fout en de openbare naamgegevens vast in een opgeschoond rapport, want een naamafwijking is te tonen zonder enig privésleutelmateriaal.

Na een ondersteunde correctie verbindt u opnieuw met alle bedoelde controles actief en verifieert u de bron die u werkelijk nodig hebt. Succes betekent dat de bedoelde server is geaccepteerd, niet dat er een certificaat doorheen is geduwd. De officiële handleiding OpenVPN 2.6 manual documenteert de drie typen en hun vertrouwensnotities, en het is de referentie die wordt geciteerd wanneer een leveranciersinterface het oneens is met het profiel.