remote-cert-tls server: hvad direktivet kontrollerer i en OpenVPN-profil

Tre forskellige spørgsmål besvares af tre forskellige dele af en OpenVPN-profil, og det er ved at smelte dem sammen, at folk ender med at slå en kontrol fra, som virkede. Er modpartens certifikat signeret af den myndighed, jeg stoler på? Erklærer certifikatet TLS-serverrollen? Er det netop den server, jeg ville nå? remote-cert-tls server besvarer kun det midterste spørgsmål, og det gør det ved at læse udvidelser inde i certifikatet.

Tre kontroller, der er nemme at smelte sammen i hovedet

Tillidsankeret ligger i ca-direktivet. Rollekontrollen hører til remote-cert-tls. Identitetskontrollen hører til verify-x509-name, når en profil bruger den, eller til den navnekontrol, som udrulningen tilføjer.

De dækker forskellige fejl:

En profil kan have alle tre og stadig være svag, hvis CA'en deles for bredt, hvilket er et nøglehåndteringsspørgsmål og ikke et direktivspørgsmål.

Hvad rollekontrollen læser

Direktivet er en makro. Det udvider sig til et krav om nøglebrug og et krav om udvidet nøglebrug, der navngiver TLS-webserverrollen, så modpartens certifikat skal faktisk erklære dette formål. Et certifikat udstedt til klientgodkendelse opfylder det ikke, selv når den samme myndighed har signeret begge.

Det betyder noget, fordi en delt CA er almindelig i små udrulninger. Én myndighed signerer hver klient og serveren, og uden en rollekontrol kunne ethvert af disse certifikater fuldføre serversiden af håndtrykket. Kontrollen gør ikke det scenarie umuligt, men den fjerner den trivielle version af det.

Direktivet er asymmetrisk af design: klienter bærer remote-cert-tls server, og servere bærer remote-cert-tls client. Byt dem, og hver forbindelse fejler med en rollefejl, der ligner et ødelagt certifikat.

Ældre profiler bruger nogle gange ns-cert-type til samme formål. Aktuelle manualsider betragter den mulighed som erstattet, så en profil, der stadig stoler på den, er værd at migrere i stedet for at fejlfinde.

Hvorfor det føles som en løsning at slå det fra

Når rollekontrollen fejler, stopper forbindelsen med en verifikationsfejl, og det oplagte træk er at slette linjen. Så kommer forbindelsen op, hvilket føles som fremskridt og faktisk er den fejltilstand, som direktivet findes for at forhindre. Du accepterer nu en modpart, hvis certifikat aldrig var beregnet til den rolle.

Læs i stedet fejlen. Den navngiver den kontrol, der fejlede, og certifikatet på den anden side kan undersøges for at se, hvilke udvidelser det virkelig bærer. To minutters læsning afgør, om fejlen er udstedelse eller konfiguration. Gætteri koster en eftermiddag og ender normalt med en svækket profil. Et fornyet servercertifikat, der har mistet sit udvidede nøglebrug, er en reel fejl i fornyelsen, ikke en grund til at slække på klienten.

Navnekontrollen er et separat direktiv

At opfylde rollekontrollen siger, at modparten er en eller anden server signeret af din myndighed. Det siger intet om hvilken, hvilket betyder noget, når den samme CA udsteder certifikater til flere gateways, og en af dem er kompromitteret eller genbrugt.

verify-x509-name sammenligner certifikatets subjekt med en værdi, du konfigurerer, med matchningstilstande for et præcist subjekt, et præfiks eller et enkelt felt. Brug det felt, der faktisk identificerer gatewayen, og forvent at opdatere det bevidst, når navnet ændres.

Ingen af direktiverne erstatter god nøglehåndtering. Hvis klientnøglefilen kopieres rundt sammen med profilen, er modpartens identitet kun så stærk som distributionslisten.

Undersøg certifikatet, før du redigerer profilen

Læs modpartens certifikat og klientloggen i den rækkefølge. Certifikatet fortæller, hvilke roller det erklærer; loggen fortæller, hvilken kontrol der afviste det.

Disse kommandoer udskriver brugsudvidelserne og verifikationslinjerne fra en detaljeret forbindelse:

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

Hvis udvidelserne viser serverrollen, og loggen stadig rapporterer en rollefejl, peger profilen sandsynligvis på den forkerte certifikatfil snarere end på et dårligt certifikat. Hvis udvidelserne kun viser klientgodkendelse, så stop med at kigge på klienten og ret udstedelsen. Under alle omstændigheder skal du gendanne kontrollen, før du kalder forbindelsen sund, fordi et vellykket håndtryk efter fjernelse af verifikation beviser mindre end den fejl, det erstattede.