Niezgodność certyfikatu SSTP: nazwa, którą musi przedstawić serwer

SSTP klient akceptuje serwer dopiero po pomyślnej weryfikacji TLS, a ta kontrola porównuje nazwę, łańcuch i przeznaczenie. Nazwa pochodzi z profilu połączenia, a nie z adresu, który przypadkiem możesz pingować. Gdy jedna z trzech rzeczy się nie zgadza, klient zgłasza problem z certyfikatem i nigdy nie dociera do monitu logowania.

Nazwa w profilu decyduje, co jest sprawdzane

SSTP uruchamia TLS przez TCP 443, więc klient zachowuje się jak każdy inny klient TLS: pobiera nazwę hosta z profilu, żąda tej nazwy i porównuje z nią certyfikat. Jeśli wpiszesz w profilu adres IP, porównanie staje się porównaniem adresów IP, którego większość certyfikatów serwera nie spełnia.

Dlatego test w przeglądarce może się udać, gdy VPN zawodzi, ponieważ przeglądarka użyła innej nazwy niż profil. Ten sam podział pojawia się, gdy DNS split-horizon tłumaczy nazwę hosta VPN na adres wewnętrzny, a przeglądarka dotarła do publicznego. Najpierw uzgodnij profil z udokumentowaną nazwą hosta, potem porównuj certyfikaty. Wszystko inne, co zmienisz wcześniej, jest zgadywaniem.

Co musi zawierać certyfikat serwera

Nowoczesne klienty porównują z rozszerzeniem alternatywnych nazw podmiotu, więc nazwa hosta musi tam występować jako wpis DNS. Sama nazwa pospolita nie wystarcza dzisiejszym stosom weryfikacji, a znak wieloznaczny obejmuje jedną etykietę, a nie dowolną wymyśloną przez ciebie subdomenę. Trzy certyfikaty pokazują granicę: właściwa nazwa z niewłaściwym przeznaczeniem potwierdza tożsamość i potem zawodzi na kontroli przeznaczenia, właściwa nazwa i przeznaczenie z brakującym certyfikatem pośrednim zawodzą na łańcuchu, a nazwa występująca tylko w nazwie pospolitej zawodzi, zanim którekolwiek z tych dwóch zacznie mieć znaczenie.

Certyfikat potrzebuje też przeznaczenia uwierzytelniania serwera, wartości rozszerzonego użycia klucza podanej w specyfikacji SSTP firmy Microsoft, czyli serverAuth z identyfikatorem obiektu 1.3.6.1.5.5.7.3.1. Użycie klucza i ważny łańcuch dopełniają zestaw. Certyfikat, który istnieje na serwerze, został wydany dla właściwej nazwy, ale tylko do uwierzytelniania klienta, nadal zawodzi.

Sprawdź łańcuch i zegar przed danymi logowania

Awarie czasu i zaufania dają ten sam widoczny wynik co niezgodność nazwy, a oba są tańsze w diagnozie niż problem z hasłem. Sprawdź zegar serwera i zegar klienta, a potem przeczytaj łańcuch tak, jak widzi go klient:

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

Pierwsze polecenie wypisuje nazwę, okno ważności i nazwy alternatywne, z którymi klient będzie porównywał. Drugie zgłasza błędy weryfikacji wraz z przedstawionym łańcuchem i właśnie tam pojawia się brakujący certyfikat pośredni. W systemie Windows zapytanie do usługi czasu mówi, czy zegar jest korygowany, czy po prostu się rozjechał.

Wewnętrzny CA dodaje jeszcze jeden warunek: klient musi ufać temu CA. Zainstaluj korzeń organizacji zatwierdzonym kanałem dystrybucji, a nie ze strony oferującej certyfikat zastępczy, ponieważ ta decyzja to cały model zaufania w miniaturze.

Weryfikacja serwera i uwierzytelnianie użytkownika to kolejne etapy o różnych awariach. Błąd certyfikatu oznacza, że klient nigdy nie zaufał serwerowi, natomiast odrzucone hasło oznacza, że zaufał, a dane logowania były błędne. Wyłączenie weryfikacji certyfikatu, by dotrzeć do monitu hasła, usuwa gwarancję zamiast ją naprawiać. Aby udowodnić, że reszta ścieżki działa, przetestuj tę samą nazwę hosta i ten sam port z klienta, który już ufa łańcuchowi, i zostaw wdrożony profil w spokoju.

Popraw nazwę lub certyfikat i przetestuj ponownie

Trzy warunki decydują o naprawie. Jeśli nazwa w profilu jest błędna, popraw profil lub dodaj brakującą nazwę do certyfikatu. Jeśli łańcuch jest niekompletny, zainstaluj certyfikat pośredni na serwerze. Jeśli przeznaczenie jest błędne, wystaw nowy zamiast łatać wokół tego.

Po zmianie połącz się ponownie z obsługiwanym klientem i potwierdź, że pojawia się monit logowania, a następnie że tunel się podnosi. Zapisz w zgłoszeniu używaną nazwę hosta, wystawcę i datę wygaśnięcia. To właśnie ten zapis sprawia, że następne odnowienie jest zaplanowanym zadaniem, a nie kolejną awarią, i pokazuje następnej osobie, który z trzech warunków naprawdę był naruszony.