SAN certyfikatu IKEv2: dlaczego weryfikacja tożsamości zawodzi

Twój certyfikat łańcuchuje się do zaufanego CA, daty są prawidłowe, a drugi koniec nadal odmawia ukończenia fazy 1 z błędem tożsamości. Osiągalność i prawidłowy podpis to tylko połowa tego, co sprawdza klient IKEv2. Druga połowa to, czy oczekiwana tożsamość pojawia się w certyfikacie we właściwym polu, a to oczekiwanie ustala profil, nie nazwa pliku certyfikatu.

Objaw jest zawsze tej samej postaci

Profil połączenia zostaje zmieniony z nazwy hosta na adres IP albo odnowiony z certyfikatu zawierającego nazwę DNS na taki, który zawiera tylko adresy, itunel przestaje negocjować. Nic w ścieżce sieciowej się nie zmieniło. Klient dociera do drugiego końca, otrzymuje certyfikat i odrzuca jego tożsamość, ponieważ identyfikator, którego miał się spodziewać, nie jest reprezentowany w polu, które akceptuje. Odnowienia są zwykłym wyzwalaczem, ponieważ certyfikat zastępczy często pochodzi z innego szablonu niż ten, który zastępuje.

Obie strony zapisują wtedy coś bezużytecznego, dlatego awaria jest zwykle zgłaszana jako problem z certyfikatem. Dziennik klienta może wymieniać oczekiwaną tożsamość, a ta nazwa jest wskazówką, której szukasz, a nie datą wygaśnięcia.

Dopasuj typ identyfikatora, nie tylko wartość

SAN typu dNSName i SAN typu iPAddress to różne pola z różnymi regułami dopasowania, więc certyfikat zawierający 203.0.113.10 jako ciąg DNS nie zadowoli klienta oczekującego tożsamości IP. Nowoczesne walidatory w dużej mierze ignorują nazwę powszechną, więc przyjazna etykieta w szczegółach certyfikatu niczego nie dowodzi co do dopasowania. Jeśli podczas rozwiązywania problemów nazwę hosta zastąpiono adresem, przyjmij, że oczekiwana tożsamość przeniosła się razem z nim, dopóki nie sprawdzisz. Porównaj ciąg w profilu z ciągiem w SAN znak po znaku, bo końcowa kropka lub zbędna spacja wystarczą.

Symbole wieloznaczne są tylko udogodnieniem DNS i podlegają własnym regułom dopasowania, co jest kolejnym powodem, dla którego profil oparty na IP nigdy nie powinien na nich polegać.

Znajdź, gdzie każdy klient przechowuje oczekiwanie

W strongSwan wartość porównywana z certyfikatem pochodzi z ustawienia tożsamości drugiego końca: rightid w klasycznej konfiguracji, albo id sekcji połączenia zdalnego w swanctl. Jej dokumentacja dotycząca interoperacyjności z Apple IKEv2 jest tu przydatna, ponieważ wyjaśnia konwencje tożsamości używane przez klienta sterowanego profilem, a te konwencje wyjaśniają klasę niezgodności, która wygląda na losową w sieci.

Profile konfiguracyjne Apple zawierają pole zdalnego identyfikatora, a to właśnie tę wartość sprawdza klient, a nie adres serwera w ustawieniach połączenia. Klienci Windows i urządzeń mają własne pola z własnymi wartościami domyślnymi, a wartość domyślna często podąża za adresem, który wpisałeś. Gdy dwa pola się nie zgadzają, wygrywa to, które klient faktycznie czyta, i rzadko jest to to, które edytowałeś.

Napraw profil albo certyfikat, świadomie

Przed zmianą czegokolwiek sprawdź certyfikat drugiego końca zatwierdzonymi narzędziami i wypisz wpisy SAN wraz z ich typami. Ta kontrola nie wymaga klucza prywatnego ani przesyłania, a kwestię rozstrzyga w kilka sekund. Jeśli wdrożenie przewiduje jedną tożsamość DNS, certyfikat musi ją zawierać jako wpis dNSName, a jeśli wdrożenie przewiduje adres, certyfikat potrzebuje wpisu iPAddress dokładnie dla tego adresu.

Gdy certyfikat jest błędny, poproś operatora o poprawiony, podając konkretny oczekiwany identyfikator. Gdy profil jest błędny, popraw profil i zostaw certyfikat w spokoju. Wyłączenie walidacji tożsamości usuwa błąd i usuwa sprawdzenie, że tunel rozmawia z zamierzonym drugim końcem.

Udokumentuj oczekiwaną tożsamość dla każdej platformy klienta, ponieważ wartość, którą jeden klient wyprowadza automatycznie, na innym może wymagać podania wprost.

Podaj prośbie o odnowienie cztery fakty

Zapisz oczekiwany identyfikator i jego typ, wpisy SAN, które obecny certyfikat rzeczywiście ma, klienta i wersję wykonujące kontrolę oraz dokładny tekst błędu. Prośba o odnowienie zbudowana z tych czterech linii za pierwszym razem otrzymuje właściwy certyfikat, a nie kolejny o tej samej znajomej nazwie pliku.