remote-cert-tls server: hva den kontrollerer i en OpenVPN-profil

Tre forskjellige spørsmål besvares av tre forskjellige deler av en OpenVPN-profil, og det er ved å slå dem sammen at folk ender med å slå av en kontroll som virket. Er motpartens sertifikat signert av myndigheten jeg stoler på? Erklærer sertifikatet TLS-serverrollen? Er det nettopp den serveren jeg ville nå? remote-cert-tls server besvarer bare det midterste spørsmålet, og det gjør det ved å lese utvidelser inne i sertifikatet.

Tre kontroller som er lette å slå sammen i hodet

Tillitsankeret bor i direktivet ca. Rollekontrollen tilhører remote-cert-tls. Identitetskontrollen tilhører verify-x509-name, når en profil bruker den, eller til hvilken som helst navnekontroll som utrullingen legger til.

De dekker forskjellige feil:

En profil kan ha alle tre og likevel være svak hvis CA-en deles for bredt, som er et nøkkeladministrasjonsspørsmål og ikke et direktivspørsmål.

Hva rollekontrollen leser

Direktivet er en makro. Det utvider seg til et krav om nøkkelbruk og et krav om utvidet nøkkelbruk som navngir TLS-nettserverrollen, så motpartens sertifikat må faktisk erklære dette formålet. Et sertifikat utstedt for klientautentisering oppfyller det ikke, selv når den samme myndigheten signerte begge.

Det betyr noe fordi en delt CA er vanlig i små utrullinger. Én myndighet signerer hver klient og serveren, og uten en rollekontroll kunne hvilket som helst av disse sertifikatene fullføre serversiden av håndtrykket. Kontrollen gjør ikke det scenarioet umulig, men den fjerner den trivielle versjonen av det.

Direktivet er asymmetrisk av design: klienter bærer remote-cert-tls server, og servere bærer remote-cert-tls client. Bytt dem, og hver tilkobling feiler med en rollefeil som ser ut som et ødelagt sertifikat.

Eldre profiler bruker noen ganger ns-cert-type til samme formål. Gjeldende manualsider behandler det alternativet som erstattet, så en profil som fortsatt stoler på det, er verdt å migrere i stedet for å feilsøke.

Hvorfor det føles som en løsning å slå det av

Når rollekontrollen feiler, stopper tilkoblingen med en verifiseringsfeil, og det åpenbare trekket er å slette linjen. Tilkoblingen kommer så opp, noe som føles som fremgang og faktisk er feilmodusen direktivet finnes for å forhindre. Du godtar nå en motpart hvis sertifikat aldri var ment for den rollen.

Les feilen i stedet. Den navngir kontrollen som feilet, og sertifikatet på den andre siden kan undersøkes for å se hvilke utvidelser det faktisk bærer. To minutter med lesing avgjør om feilen er i utstedelsen eller i konfigurasjonen. Gjetting koster en ettermiddag og ender vanligvis med en svekket profil. Et fornyet serversertifikat som mistet sin utvidede nøkkelbruk, er en reell feil i fornyelsen, ikke en grunn til å lempe på klienten.

Navnekontrollen er et eget direktiv

Å oppfylle rollekontrollen sier at motparten er en eller annen server signert av myndigheten din. Det sier ingenting om hvilken, noe som betyr noe når den samme CA-en utsteder sertifikater for flere gatewayer og en av dem er kompromittert eller gjenbrukt.

verify-x509-name sammenligner sertifikatets subjekt med en verdi du konfigurerer, med samsvarsmodi for et nøyaktig subjekt, et prefiks eller ett felt. Bruk feltet som faktisk identifiserer gatewayen, og forvent å oppdatere det bevisst når navnet endres.

Ingen av de to direktivene erstatter god nøkkelhåndtering. Hvis klientnøkkelfilen kopieres rundt sammen med profilen, er motpartens identitet bare så sterk som distribusjonslisten.

Undersøk sertifikatet før du redigerer profilen

Les motpartens sertifikat og klientloggen, i den rekkefølgen. Sertifikatet forteller deg hvilke roller det erklærer; loggen forteller deg hvilken kontroll som avviste det.

Disse kommandoene skriver ut bruksutvidelsene og verifiseringslinjene fra en detaljert tilkobling:

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 utvidelsene viser serverrollen og loggen fortsatt rapporterer en rollefeil, peker profilen sannsynligvis på feil sertifikatfil snarere enn på et dårlig sertifikat. Hvis utvidelsene bare viser klientautentisering, slutt å se på klienten og rett utstedelsen. Uansett, gjenopprett kontrollen før du kaller tilkoblingen sunn, fordi et vellykket håndtrykk etter at verifisering er fjernet, beviser mindre enn feilen det erstattet.