remote-cert-tls server: co sprawdza w profilu OpenVPN

Trzy różne pytania otrzymują odpowiedzi od trzech różnych części profilu OpenVPN, i to właśnie ich łączenie sprawia, że ludzie ostatecznie wyłączają sprawdzanie, które działało. Czy certyfikat drugiej strony jest podpisany przez urząd, któremu ufam? Czy ten certyfikat deklaruje rolę serwera TLS? Czy to dokładnie ten serwer, do którego chciałem dotrzeć? remote-cert-tls server odpowiada tylko na środkowe pytanie i robi to, czytając rozszerzenia wewnątrz certyfikatu.

Trzy sprawdzenia, które łatwo pomylić w głowie

Kotwica zaufania mieszka w dyrektywie ca. Sprawdzanie roli należy do remote-cert-tls. Sprawdzanie tożsamości należy do verify-x509-name, gdy profil go używa, albo do dowolnego sprawdzania nazwy, które dodaje wdrożenie.

Obejmują różne awarie:

Profil może mieć wszystkie trzy i nadal być słaby, jeśli CA jest zbyt szeroko współdzielony, co jest kwestią zarządzania kluczami, a nie dyrektywy.

Co czyta sprawdzanie roli

Dyrektywa jest makrem. Rozwija się w wymóg użycia klucza i wymóg rozszerzonego użycia klucza nazywający rolę serwera internetowego TLS, więc certyfikat drugiej strony musi faktycznie deklarować ten cel. Certyfikat wydany do uwierzytelniania klienta tego nie spełnia, nawet gdy ten sam urząd podpisał oba.

To ma znaczenie, ponieważ współdzielone CA jest częste w małych wdrożeniach. Jeden urząd podpisuje każdego klienta i serwer, a bez sprawdzania roli każdy z tych certyfikatów mógłby ukończyć stronę serwera uścisku dłoni. Sprawdzanie nie czyni tego scenariusza niemożliwym, ale usuwa jego trywialną wersję.

Dyrektywa jest celowo asymetryczna: klienci noszą remote-cert-tls server, a serwery noszą remote-cert-tls client. Zamień je, a każde połączenie zawiedzie z błędem roli, który wygląda jak uszkodzony certyfikat.

Starsze profile czasami używają ns-cert-type do tego samego celu. Bieżące strony podręcznika traktują tę opcję jako zastąpioną, więc profil, który nadal na niej polega, warto migrować, a nie debugować.

Dlaczego wyłączenie wydaje się naprawą

Gdy sprawdzanie roli zawodzi, połączenie zatrzymuje się z błędem weryfikacji, a oczywistym krokiem jest usunięcie wiersza. Połączenie wtedy wstaje, co wydaje się postępem i w rzeczywistości jest trybem awarii, któremu dyrektywa ma zapobiegać. Teraz akceptujesz drugą stronę, której certyfikat nigdy nie był przeznaczony do tej roli.

Zamiast tego przeczytaj błąd. Nazywa sprawdzenie, które zawiodło, a certyfikat po drugiej stronie można zbadać, aby zobaczyć, jakie rozszerzenia naprawdę zawiera. Dwie minuty czytania rozstrzygają, czy wina leży w wydaniu, czy w konfiguracji. Zgadywanie kosztuje popołudnie i zwykle kończy się osłabionym profilem. Odnowiony certyfikat serwera, który utracił rozszerzone użycie klucza, jest prawdziwą awarią odnowienia, a nie powodem do poluzowania klienta.

Sprawdzanie nazwy to osobna dyrektywa

Spełnienie sprawdzania roli mówi, że druga strona jest jakimś serwerem podpisanym przez twój urząd. Nie mówi nic o tym, którym, co ma znaczenie, gdy to samo CA wydaje certyfikaty kilku bramom i jedna z nich jest przejęta lub wykorzystana ponownie.

verify-x509-name porównuje podmiot certyfikatu z wartością, którą konfigurujesz, z trybami dopasowania dla dokładnego podmiotu, prefiksu lub jednego pola. Użyj pola, które naprawdę identyfikuje bramę, i spodziewaj się, że będziesz je świadomie aktualizować, gdy nazwa się zmieni.

Żadna z dyrektyw nie zastępuje dobrego obchodzenia się z kluczami. Jeśli plik klucza klienta jest kopiowany razem z profilem, tożsamość drugiej strony jest tylko tak silna jak lista dystrybucyjna.

Zbadaj certyfikat, zanim zmodyfikujesz profil

Przeczytaj certyfikat drugiej strony i dziennik klienta, w tej kolejności. Certyfikat mówi, jakie role deklaruje; dziennik mówi, które sprawdzenie go odrzuciło.

Te polecenia wypisują rozszerzenia użycia i wiersze weryfikacji ze szczegółowego połączenia:

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

Jeśli rozszerzenia pokazują rolę serwera, a dziennik nadal zgłasza błąd roli, profil prawdopodobnie wskazuje zły plik certyfikatu, a nie zły certyfikat. Jeśli rozszerzenia pokazują tylko uwierzytelnianie klienta, przestań patrzeć na klienta i napraw wydanie. W każdym razie przywróć sprawdzanie, zanim nazwiesz połączenie zdrowym, ponieważ udany uścisk dłoni po usunięciu weryfikacji dowodzi mniej niż błąd, który zastąpił.