remote-cert-tls server: vad den kontrollerar i en OpenVPN-profil

Tre olika frågor besvaras av tre olika delar av en OpenVPN-profil, och det är genom att slå ihop dem som folk till slut stänger av en kontroll som fungerade. Är motpartens certifikat signerat av den myndighet jag litar på? Deklarerar certifikatet TLS-serverrollen? Är det just den servern jag ville nå? remote-cert-tls server besvarar bara den mellersta frågan, och det gör den genom att läsa utökningar inne i certifikatet.

Tre kontroller som är lätta att slå ihop i huvudet

Förtroendeankaret finns i direktivet ca. Rollkontrollen hör till remote-cert-tls. Identitetskontrollen hör till verify-x509-name, när en profil använder den, eller till vilken namnkontroll som helst som utrullningen lägger till.

De täcker olika fel:

En profil kan ha alla tre och ändå vara svag om CA:n delas för brett, vilket är en fråga om nyckelhantering och inte om direktiv.

Vad rollkontrollen läser

Direktivet är ett makro. Det expanderar till ett krav på nyckelanvändning och ett krav på utökad nyckelanvändning som namnger TLS-webbserverrollen, så motpartens certifikat måste faktiskt deklarera detta syfte. Ett certifikat som utfärdats för klientautentisering uppfyller det inte, även när samma myndighet signerade båda.

Det spelar roll eftersom en delad CA är vanlig i små utrullningar. En myndighet signerar varje klient och servern, och utan en rollkontroll skulle vilket som helst av dessa certifikat kunna slutföra serversidan av handskakningen. Kontrollen gör inte det scenariot omöjligt, men den tar bort den triviala versionen av det.

Direktivet är asymmetriskt av design: klienter bär remote-cert-tls server, och servrar bär remote-cert-tls client. Byt dem, och varje anslutning misslyckas med ett rollfel som ser ut som ett trasigt certifikat.

Äldre profiler använder ibland ns-cert-type för samma syfte. Aktuella manualsidor behandlar det alternativet som ersatt, så en profil som fortfarande förlitar sig på det är värd att migrera i stället för att felsöka.

Varför det känns som en lösning att stänga av det

När rollkontrollen misslyckas stoppar anslutningen med ett verifieringsfel, och det uppenbara draget är att radera raden. Anslutningen kommer då upp, vilket känns som framsteg och faktiskt är det felläge som direktivet finns för att förhindra. Du accepterar nu en motpart vars certifikat aldrig var avsett för den rollen.

Läs felet i stället. Det namnger kontrollen som misslyckades, och certifikatet på andra sidan kan undersökas för att se vilka utökningar det verkligen bär. Två minuters läsning avgör om felet ligger i utfärdandet eller i konfigurationen. Gissningar kostar en eftermiddag och slutar oftast med en försvagad profil. Ett förnyat servercertifikat som förlorat sin utökade nyckelanvändning är ett verkligt fel i förnyelsen, inte en anledning att lätta på klienten.

Namnkontrollen är ett separat direktiv

Att uppfylla rollkontrollen säger att motparten är någon server signerad av din myndighet. Det säger ingenting om vilken, vilket spelar roll när samma CA utfärdar certifikat för flera gateways och en av dem är komprometterad eller återanvänd.

verify-x509-name jämför certifikatets subjekt med ett värde du konfigurerar, med matchningslägen för ett exakt subjekt, ett prefix eller ett enda fält. Använd fältet som faktiskt identifierar gatewayen, och räkna med att uppdatera det medvetet när namnet ändras.

Inget av direktiven ersätter god nyckelhantering. Om klientnyckelfilen kopieras runt tillsammans med profilen är motpartens identitet bara så stark som distributionslistan.

Undersök certifikatet innan du redigerar profilen

Läs motpartens certifikat och klientloggen, i den ordningen. Certifikatet berättar vilka roller det deklarerar; loggen berättar vilken kontroll som avvisade det.

De här kommandona skriver ut användningsutökningarna och verifieringsraderna från en detaljerad anslutning:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

Om utökningarna visar serverrollen och loggen fortfarande rapporterar ett rollfel pekar profilen troligen på fel certifikatfil snarare än på ett dåligt certifikat. Om utökningarna bara visar klientautentisering, sluta titta på klienten och rätta utfärdandet. Återställ i vilket fall kontrollen innan du kallar anslutningen frisk, eftersom en lyckad handskakning efter att verifieringen tagits bort bevisar mindre än felet den ersatte.