OpenVPN verify-x509-name: subject, name i name-prefix

Najpierw przeczytaj typ dopasowania, potem tekst: verify-x509-name dyrektywa może wyglądać poprawnie i mimo to przyjąć certyfikat, któremu nie zamierzałeś ufać. Dwie linie z tym samym oczekiwanym tekstem, ale różnymi typami to dwa różne wymagania. Najpierw czytaj typ, potem tekst. Traktuj dyrektywę jako jeszcze jeden warunek połączenia, a nie całą weryfikację.

Co opcja rzeczywiście stwierdza

Dyrektywa wskazuje tożsamość, którą musi nosić certyfikat drugiej strony. Gdy porównanie się nie powiedzie, OpenVPN przerywa uzgadnianie i tunel się nie podnosi. Wszystko inne w profilu nadal obowiązuje: certyfikat musi łańcuchowo prowadzić do zaufanego CA, a kontrola roli musi przejść, więc jest to dodatkowy warunek, a nie zamiennik. Profil, który spełnia oczekiwanie nazwy, ale nie przechodzi kontroli roli, nadal jest zepsuty, i log zwykle to mówi.

Różni się to także od walidacji nazwy hosta wykonywanej przez przeglądarkę. Przeglądarka dopasowuje nazwy do nazw alternatywnych subject według reguł swojego stosu TLS, podczas gdy OpenVPN porównuje jedno pole certyfikatu z wybranym typem. Dlatego wklejenie nazwy hosta w stylu przeglądarki do dyrektywy może dać niezgodność, nawet gdy certyfikat naprawdę obejmuje usługę.

subject: pełna nazwa wyróżniająca, znak po znaku

Gdy nie zapisano typu, domyślny jest subject, a oczekiwana wartość musi odtworzyć cały subject DN certyfikatu. Kolejność pól, separatory, odstępy i escaping liczą się wszystkie, ponieważ porównanie odbywa się na łańcuchu tak, jak jest zakodowany. Jeśli pominiesz typ, wybrałeś najsurowsze z trzech porównań. Nie ma etapu normalizacji, który uratowałby różnicę kosmetyczną. Warto to wiedzieć przed pierwszym odnowieniem, a nie po nim.

Ta surowość jest krucha między odnowieniami. CA, która przestawia atrybuty, wstawia dodatkowe pole lub zmienia sposób escapingu wartości, tworzy nowy łańcuch dla tej samej maszyny, a dyrektywa, która działała latami, zaczyna zawodzić przy kolejnym wydaniu. Przechowywanie zaakceptowanego DN w rejestrze zmian zamienia kolejne odnowienie w różnicę. Tam, gdzie operator publikuje pełny DN i gwarantuje jego kształt, subject jest rozsądnym wyborem; gdzie indziej węższe pole łatwiej utrzymać w prawdzie.

name: jedno pole, zwykle nazwa zwyczajna

Typ name porównuje jedno pole subject. O ile profil nie mówi inaczej, tym polem jest nazwa zwyczajna, a oczekiwana wartość to dokładnie to pole, nie DN wokół niego.

Haczyk polega na tym, że nowoczesne certyfikaty nie zawsze umieszczają nazwę usługi w CN. Wiele z nich trzyma ją w nazwie alternatywnej subject i zostawia CN puste lub ogólne, więc certyfikat, który przeglądarka akceptuje, może nadal nie przejść tego porównania. Zanim napiszesz oczekiwanie, obejrzyj certyfikat, który faktycznie ci wydano, i potwierdź, które pole wybiera profil. Puste CN porównane z nazwą to niezgodność, a nie wypadek konfiguracji.

name-prefix: szeroki z założenia, więc ogranicz zakres

Oczekiwanie typu name-prefix pasuje do początku wybranego pola. To wygodne dla schematu nazewnictwa i niebezpieczne dla wszystkiego, co jest współdzielone.

Jeśli oczekiwaniem jest vpn.example , przeszłyby oba vpn.example.com i vpn.example.net , pod warunkiem że reszta łańcucha jest zaufana. Szerokość jest cechą i jednocześnie tą częścią, którą trzeba uzasadnić na piśmie. Prefiks jest rozsądny, gdy CA i schemat nazewnictwa są twoje, a znacznie słabszy, gdy publiczna CA wydaje w tym samym wzorcu. Jeśli schemat potrzebuje elastyczności, ogranicz go po stronie CA, zamiast poszerzać kontrolę klienta.

Wybierz typ na podstawie identyfikatora, a potem to udowodnij

Pracuj wstecz od tożsamości, którą zamierza operator. Jeśli publikuje pełny DN i utrzymuje go stabilnym, subject to wyraża. Jeśli nazywa usługę nazwą zwyczajną, użyj name. Jeśli posiada schemat nazewnictwa i akceptuje całą jego przestrzeń, name-prefix mówi to wprost.

Odnowienia to miejsce, w którym dyrektywa jest sprawdzana. Porównuj zatwierdzoną tożsamość z nowym certyfikatem, a nie ze starym plikiem, ponieważ nowy adres punktu końcowego nie oznacza nowej tożsamości certyfikatu. Nie usuwaj dyrektywy tylko dlatego, że znajomy adres odpowiada: osiągalność i zamierzona druga strona to różne fakty, a adres dowodzi jedynie, że coś odpowiedziało. Zapisz dokładny błąd i publiczne dane nazwy w oczyszczonym raporcie, ponieważ niezgodność nazwy można pokazać bez żadnego materiału klucza prywatnego.

Po obsługiwanej poprawce połącz się ponownie z wszystkimi zamierzonymi kontrolami i zweryfikuj zasób, którego naprawdę potrzebujesz. Sukces oznacza, że zamierzony serwer został zaakceptowany, a nie że jakiś certyfikat został przepchnięty. Oficjalny podręcznik OpenVPN 2.6 manual dokumentuje trzy typy i ich uwagi o zaufaniu, i to jest referencja, którą się cytuje, gdy interfejs dostawcy nie zgadza się z profilem.