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

Läs först matchningstypen och sedan texten: en verify-x509-name direktiv kan se korrekt ut och ändå acceptera ett certifikat som du inte tänkte lita på. Två rader med samma förväntade text men olika typer är olika krav. Läs typen först och sedan texten. Behandla direktivet som ytterligare ett villkor för anslutningen, inte som hela kontrollen.

Vad alternativet faktiskt hävdar

Direktivet namnger en identitet som motpartens certifikat måste bära. När jämförelsen misslyckas, OpenVPN avbryter handskakningen och ingen tunnel kommer upp. Allt annat i profilen gäller fortfarande: certifikatet måste kedja till en betrodd CA och rollkontrollen måste gå igenom, så detta är ett tilläggsvillkor och inte en ersättning. En profil som uppfyller namnförväntan och misslyckas med rollkontrollen är fortfarande trasig, och loggen säger oftast det.

Det skiljer sig också från den värdnamnsvalidering en webbläsare gör. En webbläsare matchar namn mot subject-alternativa namn enligt reglerna i sin TLS-stack, medan OpenVPN jämför ett enskilt certifikatfält med den typ du valde. Därför kan ett inklistrat värdnamn i webbläsarstil i direktivet ge en avvikelse även när certifikatet faktiskt täcker tjänsten.

subject: hela det särskiljande namnet, tecken för tecken

Med subject, standarden när ingen typ skrivs, måste det förväntade värdet återge certifikatets fulla subject-DN. Fältordning, avgränsare, mellanslag och escaping räknas alla, eftersom jämförelsen körs på strängen så som den är kodad. Utelämnar du typen har du valt den strängaste av de tre jämförelserna. Det finns inget normaliseringssteg som räddar en kosmetisk skillnad. Det är värt att veta före den första förnyelsen, inte efter.

Den strängheten är bräcklig mellan förnyelser. En CA som ordnar om attribut, infogar ett extra fält eller ändrar hur den escapar ett värde skapar en ny sträng för samma maskin, och ett direktiv som fungerade i åratal börjar misslyckas vid nästa utfärdande. Att behålla den accepterade DN:n i ändringsloggen gör nästa förnyelse till en skillnad. Där operatören publicerar en full DN och garanterar dess form är subject ett rimligt val; på andra håll är ett smalare fält lättare att hålla sant.

name: ett fält, oftast det vanliga namnet

Typen name jämför ett enskilt subject-fält. Om profilen inte säger annat är det fältet det vanliga namnet, och det förväntade värdet är exakt det fältet, inte DN:n runt det.

Haken är att moderna certifikat inte alltid sätter tjänstenamnet i CN. Många bär det i ett subject-alternativt namn och lämnar CN tomt eller generiskt, så ett certifikat som en webbläsare accepterar kan ändå misslyckas med den här jämförelsen. Granska certifikatet du faktiskt fick utfärdat innan du skriver förväntan, och bekräfta vilket fält profilen väljer. Ett tomt CN jämfört med ett namn är en avvikelse, inte en konfigurationsolycka.

name-prefix: brett avsiktligt, så begränsa omfånget

En förväntan av typen name-prefix matchar början av det valda fältet. Det är bekvämt för ett namnschema och farligt för allt som delas.

Med vpn.example som förväntan skulle både vpn.example.com och vpn.example.net passera, förutsatt att resten av kedjan är betrodd. Bredden är funktionen, och det är också den del som måste motiveras skriftligt. Ett prefix är rimligt när CA:n och namnschemat är dina, och mycket svagare när en offentlig CA utfärdar i samma mönster. Om schemat behöver flexibilitet, begränsa det vid CA:n i stället för att vidga klientkontrollen.

Välj typen utifrån identiteten och bevisa den sedan

Arbeta baklänges från identiteten som operatören avser. Om de publicerar en full DN och håller den stabil, subject uttrycker det. Om de namnger tjänsten med det vanliga namnet, använd name. Om de äger ett namnschema och accepterar hela dess rymd, name-prefix säger det uttryckligen.

Förnyelser är där direktivet testas. Jämför den godkända identiteten med det nya certifikatet i stället för med den gamla filen, eftersom en ny slutpunktsadress inte innebär en ny certifikatidentitet. Ta inte bort direktivet bara för att en bekant adress svarar: nåbarhet och den avsedda motparten är olika fakta, och adressen bevisar bara att något svarade. Anteckna det exakta felet och de offentliga namndetaljerna i en renad rapport, eftersom en namnawikelse kan visas utan något privat nyckelmaterial.

Efter en stödd rättelse, anslut igen med alla avsedda kontroller aktiverade och verifiera resursen du faktiskt behöver. Framgång betyder att den avsedda servern accepterades, inte att något certifikat pressades igenom. Den officiella handboken OpenVPN 2.6 manual dokumenterar de tre typerna och deras förtroendenoteringar, och det är referensen som citeras när ett leverantörsgränssnitt inte är överens med profilen.