Prawidłowe hasło VPN nie zastąpi brakującego certyfikatu

Dane logowania są poprawne, profil importuje się czysto, a połączenie nadal kończy się niepowodzeniem, zanim uwierzytelnianie się zakończy. W Windows komunikat może być błędem 798, dotyczącym certyfikatu, którego nie znaleziono dla metody EAP. W OpenVPN dziennik klienta pokazuje uścisk dłoni TLS, który nigdy nie zadowala serwera. Oba opisują ten sam brakujący obiekt: certyfikat klienta, który klient powinien był przedstawić.

Hasło dowodzi znajomości tajemnicy; certyfikat dowodzi posiadania klucza, i jedno nie zastępuje drugiego.

Hasło nigdy nie było problemem

Błąd 798 to nieudane wyszukanie certyfikatu. Klient został poproszony o certyfikat zgodny ze skonfigurowaną metodą uwierzytelniania, przeszukał swój magazyn i nie znalazł nic użytecznego. Może to oznaczać, że certyfikatu brakuje, jest obecny bez klucza prywatnego, wygasł albo jest przechowywany tam, gdzie wyszukiwanie nie dociera. Ponowne wpisanie hasła nie może zmienić żadnego z tych warunków, dlatego błąd powraca nawet przy poprawnych danych.

Przeczytaj komunikat, zanim zaczniesz działać. Odrzucenie danych logowania, nieudane wyszukanie certyfikatu i nieudany uścisk dłoni TLS to trzy różne ustalenia, a tylko jedno z nich dotyczy hasła.

Co musi zawierać magazyn klienta

Zaangażowane są dwa obiekty. Certyfikat klienta musi być zainstalowany dla użytkownika, który uruchamia klienta VPN, wraz z kluczem prywatnym, a korzeń wystawcy musi być zaufany. Plik .cer zawiera tylko certyfikat publiczny, więc sam nie może niczego uwierzytelnić. W menedżerze certyfikatów Windows tożsamość klienta należy do magazynu osobistego bieżącego użytkownika, a korzeń do magazynu zaufanych korzeni.

Zainstalowanie tożsamości w magazynie komputera lub tylko w magazynie korzeni nie spełnia wyszukiwania skierowanego do osobistego magazynu użytkownika. Sprawdź magazyn, znacznik klucza prywatnego i daty ważności razem, a następnie uruchom ponownie klienta, aby ponownie odczytał magazyn.

Dwa produkty, ten sam brakujący element

Serwery OpenVPN domyślnie wymagają certyfikatu klienta. Dodanie auth-user-pass do klienta wysyła nazwę użytkownika i hasło, a uścisk dłoni TLS nadal prosi o certyfikat, więc samo hasło nie może ukończyć połączenia w ramach verify-client-cert require. Serwer można ustawić tak, aby niczego nie wymagał, co czyni hasło jedynym elementem uwierzytelniającym klienta i jest rzeczywistym osłabieniem. Skrypt powłoki za auth-user-pass-verify może weryfikować dane logowania, a wymaga włączonego wykonywania skryptów, co czyni go bardziej ryzykownym rozwiązaniem niż porządny backend uwierzytelniania.

Profil oparty tylko na haśle zależy też od przysłanych opcji, które z kolei zależą od włączenia mechanizmu pobierania.

Nie naprawiaj brakującego certyfikatu przez wyłączanie kontroli

Pokusa polega na poluzowaniu weryfikacji, aby komunikat zniknął. To usuwa kontrolę, która wykonywała swoją pracę, i zostawia połączenie, które nie dowodzi już tego, co twierdzi. Jeśli brama niedawno zmieniła swój korzeń, pobierz ponownie pakiet klienta zamiast edytować profil, ponieważ stary pakiet może wciąż zawierać poprzedni korzeń. Jeśli w edytorze profilu brakuje opcji uwierzytelniania certyfikatem, zainstalowana wersja Windows może nie udostępniać tej metody; zaktualizuj system zamiast ręcznie edytować XML.

Zapisz, w którym magazynie był certyfikat, który użytkownik uruchomił klienta i czy obecny był klucz prywatny. Te trzy wyjaśniają prawie każdy przypadek tej awarii.

Hasło było w porządku. Element uwierzytelniający, którego metoda naprawdę potrzebowała, był gdzie indziej.