remote-cert-tls server: kva det kontrollerer i ein OpenVPN-profil

Tre ulike spørsmål blir svara på av tre ulike delar av ein OpenVPN-profil, og det er ved å slå dei saman at folk endar med å slå av ein kontroll som verka. Er sertifikatet til motparten signert av myndigheita eg stolar på? Erklærer sertifikatet TLS-tenarrolla? Er det nettopp den tenaren eg ville nå? remote-cert-tls server svarar berre på det midtre spørsmålet, og det gjer det ved å lese utvidingar inne i sertifikatet.

Tre kontrollar som er lette å slå saman i hovudet

Tillitsankeret bur i direktivet ca. Rollekontrollen høyrer til remote-cert-tls. Identitetskontrollen høyrer til verify-x509-name, når ein profil brukar han, eller til kva som helst namnekontroll som utrullinga legg til.

Dei dekkjer ulike feil:

Ein profil kan ha alle tre og likevel vere svak om CA-en blir delt for breitt, som er eit nøkkeladministrasjonsspørsmål og ikkje eit direktivspørsmål.

Kva rollekontrollen les

Direktivet er ein makro. Det utvidar seg til eit krav om nøkkelbruk og eit krav om utvida nøkkelbruk som namngir TLS-nettserarrolla, så sertifikatet til motparten må faktisk erklære dette føremålet. Eit sertifikat utstedt for klientautentisering oppfyller det ikkje, sjølv når den same myndigheita signerte begge.

Det betyr noko fordi ein delt CA er vanleg i små utrullingar. Éi myndigheit signerer kvar klient og tenaren, og utan ein rollekontroll kunne kva som helst av desse sertifikata fullføre tenarsida av handtrykket. Kontrollen gjer ikkje det scenarioet umogleg, men han fjernar den trivielle versjonen av det.

Direktivet er asymmetrisk av design: klientar ber remote-cert-tls server, og tenarar ber remote-cert-tls client. Bytt dei, og kvar tilkopling feilar med ein rollefeil som ser ut som eit øydelagt sertifikat.

Eldre profilar brukar nokon gonger ns-cert-type til same føremål. Gjeldande manualsider behandlar det alternativet som erstatta, så ein profil som framleis stolar på det, er verdt å migrere i staden for å feilsøke.

Kvifor det kjennest som ei løysing å slå det av

Når rollekontrollen feilar, stoppar tilkoplinga med ein verifiseringsfeil, og det openberre trekket er å slette linja. Tilkoplinga kjem så opp, noko som kjennest som framgang og faktisk er feilmodusen direktivet finst for å hindre. Du godtek no ein motpart kven sitt sertifikat aldri var meint for den rolla.

Les feilen i staden. Han namngir kontrollen som feila, og sertifikatet på den andre sida kan undersøkjast for å sjå kva utvidingar det faktisk ber. To minutt med lesing avgjer om feilen er i utstedinga eller i konfigurasjonen. Gjetting kostar ein ettermiddag og endar vanlegvis med ein svekt profil. Eit fornya tenarsertifikat som mista den utvida nøkkelbruken sin, er ein reell feil i fornyinga, ikkje ein grunn til å lempe på klienten.

Namnekontrollen er eit eige direktiv

Å oppfylle rollekontrollen seier at motparten er ein eller annan tenar signert av myndigheita di. Det seier ingenting om kven, noko som betyr noko når den same CA-en utsteder sertifikat for fleire gatewayar og ein av dei er kompromittert eller gjenbrukt.

verify-x509-name samanliknar subjektet til sertifikatet med ein verdi du konfigurerer, med samsvarsmodi for eit nøyaktig subjekt, eit prefiks eller eitt felt. Bruk feltet som faktisk identifiserer gatewayen, og forvent å oppdatere det med vilje når namnet endrar seg.

Ingen av dei to direktiva erstattar god nøkkelhandsaming. Viss klientnøkkelfila blir kopiert rundt saman med profilen, er identiteten til motparten berre så sterk som distribusjonslista.

Undersøk sertifikatet før du redigerer profilen

Les sertifikatet til motparten og klientloggen, i den rekkjefølgja. Sertifikatet fortel deg kva rollar det erklærer; loggen fortel deg kva kontroll som avviste det.

Desse kommandoane skriv ut bruksutvidingane og verifiseringslinjene frå ei detaljert tilkopling:

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

Viss utvidingane viser tenarrolla og loggen framleis rapporterer ein rollefeil, peikar profilen truleg på feil sertifikatfil snarare enn på eit dårleg sertifikat. Viss utvidingane berre viser klientautentisering, slutt å sjå på klienten og rett utstedinga. Uansett, gjenopprett kontrollen før du kallar tilkoplinga sunn, fordi eit vellukka handtrykk etter at verifisering er fjerna, beviser mindre enn feilen det erstatta.