Certyfikat bramy jest w porządku: dlaczego logowanie IKEv2 PEAP nadal zawodzi

Certyfikat bramy VPN jest ważny, łańcuch się weryfikuje, a klient IKEv2 nadal odrzuca logowanie z komunikatem o przedziale ważności certyfikatu. Pierwszy odruch to ponowne wydanie certyfikatu bramy albo zmiana metody EAP, i oba są zwykle błędne. Próba logowania niesie dwie odrębne tożsamości serwera: certyfikat bramy używany przez IKE oraz certyfikat przedstawiany przez to, co kończy PEAP. Jedna z nich jest w porządku, a druga jest powodem, dla którego klient się zatrzymał.

Dwie tożsamości, jedna próba logowania

Certyfikat w profilu VPN należy do wymiany IKE: dowodzi, że brama jest drugą stroną wskazaną w profilu, zgodnie ze skonfigurowaną polityką IKE. Certyfikat, który tu zawodzi, należy do innej rozmowy, sesji TLS, którą PEAP otwiera z tym, co uwierzytelnia użytkownika, często serwerem RADIUS takim jak NPS, a nie samą bramą. Trzecia kontrola, dane logowania użytkownika, odbywa się wewnątrz tej sesji. Ważne hasło nie naprawi wygasłego certyfikatu serwera, a ważny certyfikat bramy nie może ręczyć za punkt końcowy PEAP.

To warstwowanie wyjaśnia, dlaczego błąd certyfikatu pojawia się w miejscu, gdzie jedynym skonfigurowanym certyfikatem był certyfikat bramy. Wyjaśnia też, dlaczego ponowne wydanie tego certyfikatu niczego nie zmienia.

Czytaj wiersz dziennika względem etapu

Znajdź komunikat, który podaje przyczynę i daty. Skarga na przedział ważności obok błędu podmiotu oznacza, że serwer odrzucił certyfikat, który otrzymał, a nie że użytkownik odrzucił logowanie. Następnie znajdź etap: dziennik charon strongSwana pokazuje IKE_SA .* established przed rozpoczęciem wymiany EAP, więc błąd certyfikatu po tym wierszu należy do tożsamości EAP, a błąd przed nim wskazuje bramę. Tekst etapu w panelu połączenia klienta Windows mówi to samo.

Sprawdź zegar klienta, zanim dotkniesz jakiegokolwiek certyfikatu. Urządzenie odbiegające o godziny daje ten sam błąd ważności co naprawdę wygasły certyfikat. Ustawienie zegara to poprawka na pięć sekund, a wymiana certyfikatu, który nigdy nie był problemem, to awaria.

Ustal, który punkt końcowy kończy PEAP

W rozwiązaniu z bramą i RADIUS-em brama przekazuje EAP dalej i go nie kończy. Wtyczka eap-radius strongSwana przekazuje wymianę serwerowi RADIUS, który posiada sesję TLS PEAP i jej certyfikat. Skoreluj jedną nieudaną próbę w obu dziennikach i potwierdź, który proces naprawdę wybrał certyfikat dla tej sesji.

Dla NPS certyfikat musi znajdować się w magazynie komputera lokalnego, mieć przeznaczenie uwierzytelniania serwera, odpowiadać nazwie oczekiwanej przez klientów i być czytelny dla konta usługi. Wymagania firmy Microsoft dotyczące certyfikatów dla NPS wymieniają te warunki. Inne serwery EAP mają własne reguły wyboru, więc nie kopiuj szczegółów NPS do wdrożenia FreeRADIUS ani odwrotnie. Reguła, która obowiązuje w obu przypadkach, jest taka, że punkt końcowy kończący PEAP posiada certyfikat, który zamierzasz zmienić.

Wymień certyfikat tam, gdzie kończy się EAP

Odnow lub wymień certyfikat w punkcie końcowym, który kończy PEAP, zgodnie z obsługiwaną procedurą, zachowując przeznaczenie uwierzytelniania serwera i oczekiwaną nazwę. Zainstaluj pełny łańcuch tam, gdzie usługa go szuka, i przyznaj usłudze dostęp do klucza prywatnego. Uruchom usługę ponownie lub powiąż ją ponownie, ponieważ wiele usług trzyma stary certyfikat w pamięci i nadal go przedstawia. Plik skopiowany na maszynę niczego nie dowodzi co do tego, który certyfikat usługa naprawdę przedstawia.

Potwierdź zmianę, korelując następną próbę z własnym dziennikiem usługi albo sprawdzając certyfikat przedstawiony przez sesję. Jeśli ten dziennik nadal pokazuje stary odcisk, ponowne uruchomienie nie zadziałało.

Nie zakładaj, że najnowszy plik w katalogu jest tym używanym. Kopia z właściwą nazwą i niewłaściwymi uprawnieniami niczego nie zmienia. Oceniaj zmianę po przedstawionej tożsamości, a nie po znaczniku czasu pliku.

Czego nie robić

Nie wyłączaj weryfikacji PEAP i nie wymuszaj słabszej metody wewnętrznej, aby obejść błąd. To zmienia politykę i usuwa właściwość uwierzytelniania serwera, która właśnie wychwyciła wygasły certyfikat. Wymieniłbyś działającą kontrolę na działające połączenie, a następny wygasły certyfikat przyszedłby bez niczego, co by go zapowiedziało.

Nie traktuj udanego połączenia z innego systemu operacyjnego jako dowodu, że certyfikat jest akceptowalny. Ten klient może używać innej metody EAP, innego magazynu zaufania albo wcale nie weryfikować serwera, więc jego sukces nic nie mówi o kontroli, która tu zawiodła. Utrzymuj jeden celowy test negatywny, na przykład certyfikat z błędną nazwą albo niezaufany łańcuch, który zawodzi zgodnie z oczekiwaniem. Jeśli ten test teraz przechodzi, usunąłeś kontrolę, a nie naprawiłeś certyfikatu. Zapisz, która tożsamość zawiodła, aby następna osoba nie zaczynała znowu od certyfikatu bramy.