Certyfikat IKEv2 na iPhonie: rejestracja ręczna lub zarządzana

Wybranie RSA tylko dlatego, że narzędzie certyfikatów bramy używa go domyślnie, to decyzja podjęta przed pytaniem, które ma znaczenie: jak te iPhone'y będą rejestrowane? Połączenie wpisywane przez użytkownika i profil konfiguracji dostarczany przez zarządzanie ujawniają różne ustawienia, a niektóre wybory certyfikatu istnieją tylko na jednej z tych ścieżek. Ustaw kolejność poprawnie, a plan certyfikatu stanie się krótki; ustaw źle, a wydasz dane uwierzytelniające, których telefon nie użyje. Traktuj poniższe kroki jako sekwencję, bo każdy zawęża wybory dostępne dla następnego.

Krok pierwszy: wybierz ścieżkę rejestracji

Konfiguracja ręczna oznacza, że użytkownik wprowadza adres serwera, wybiera metodę uwierzytelniania i podaje dowolne dane logowania, na które pozwala interfejs. Rejestracja zarządzana oznacza, że profil niesie adres, identyfikatory i odwołanie do ładunku danych logowania. Ścieżka zarządzana może wyrazić kombinacje, których ekran ręczny nie potrafi, dlatego decyzja o certyfikacie musi przyjść po tym wyborze, a nie przed nim.

Obie ścieżki mogą uwierzytelnić telefon. Różnią się tym, co można skonfigurować, i tym, kto jest właścicielem tożsamości, więc wybierz jedną świadomie, zamiast mieszać profil zarządzany z ręcznym wprowadzaniem danych logowania.

Krok drugi: wybierz algorytmy dla wybranej ścieżki

Dla iPhone'ów skonfigurowanych ręcznie notatki strongSwan o interoperacyjności z iOS zalecają certyfikat serwera RSA, ponieważ klient ręczny może nie akceptować certyfikatu serwera ECDSA; te same notatki traktują macOS osobno. Czytaj to jako wskazówkę dla obsługiwanego zestawu klientów, nie jako wieczne prawo o urządzeniach Apple. Profil zarządzany ma więcej miejsca: może jawnie wybrać typ certyfikatu, w tym tożsamość klienta ECDSA, gdy ładunek i brama oba to obsługują.

Przed wdrożeniem czegokolwiek zweryfikuj wersje iOS, które naprawdę obsługujesz. Telefon laboratoryjny na najnowszej wersji nie opisuje floty obejmującej starsze urządzenia, a algorytm działający w laboratorium może nadal zawieść na najstarszym telefonie w terenie. Zakres wersji weź z zarządzania urządzeniami, a nie z pamięci. Jeśli flota obejmuje kilka wersji, najpierw przetestuj najstarszą, bo tam interfejs ręczny jest najbardziej ograniczający.

Krok trzeci: czytaj pola profilu jako osobne rzeczy

Kilka podobnie nazwanych kluczy opisuje różne obiekty. Adres zdalny to host, do którego telefon dzwoni. Identyfikator zdalny to tożsamość IKE, której telefon oczekuje od bramy. Odwołanie do certyfikatu w ładunku wskazuje dane logowania klienta, a pole typu certyfikatu wybiera typ używany do uwierzytelniania maszyny IKEv2. Żaden z nich nie jest algorytmem podpisu CA, choć słowa się pokrywają.

Odwołanie do ładunku IKEv2 firmy Apple wymienia RSA jako domyślny typ certyfikatu z jawnymi wariantami ECDSA i wiąże klucz nazwy wystawcy z określonymi ustawieniami uwierzytelniania. Czytaj te relacje w odwołaniu dla wybranej metody, zamiast kopiować jeden klucz z działającego wdrożenia.

Krok czwarty: dopasuj tożsamość bramy do jej certyfikatu

Użyj jawnej nazwy bramy, na przykład vpn.example.com i umieść pasującą alternatywną nazwę podmiotu w certyfikacie serwera. Przewodnik strongSwan dla Apple oczekuje też rozszerzonego użycia klucza do uwierzytelniania serwera. Wybór RSA lub ECDSA niczego z tego nie zmienia: algorytm nie naprawi niezgodności nazwy, brakującego EKU ani niekompletnego łańcucha.

Rozpowszechnianie kotwicy zaufania to osobne zadanie od potwierdzania tożsamości. Telefon potrzebuje łańcucha certyfikatów, który może zweryfikować, i musi być skonfigurowany tak, aby oczekiwał nazwy, którą naprawdę umieściłeś w certyfikacie.

To, że inna platforma łączy się skutecznie, jest dowodem o regułach walidacji tej platformy, a nie pozwoleniem na poluzowanie reguł telefonu. Utrzymuj kontrole identyczne u wszystkich klientów, chyba że masz udokumentowany powód do różnic.

Krok piąty: oddziel tożsamość klienta od zaufania do CA

Certyfikat klienta i jego klucz prywatny nie są tym samym obiektem co certyfikat CA, któremu telefon ufa. Spakowanie certyfikatu CA w tożsamość PKCS#12 nie instaluje go automatycznie jako kotwicy zaufania na każdym obsługiwanym urządzeniu, więc traktuj dystrybucję zaufania jako osobny krok z własną weryfikacją.

Jeśli projekt używa zamiast tego EAP opartego na haśle, telefon potrzebuje zamierzonego uwierzytelnienia konta oraz walidacji serwera. Ta ścieżka nie uzasadnia wysłania jednego wspólnego prywatnego klucza klienta do całej floty, co jest innym projektem z dużo gorszym trybem awarii.

Zakończ plan, myśląc o odnowieniu i unieważnieniu: kto ponownie wydaje dane logowania klienta, jak aktualizowany jest profil i jak odcina się zgubiony telefon. Zapisz wersję profilu i wersje urządzeń, według których weryfikowałeś, bo to właśnie ten zapis czyni następną wymianę certyfikatu rutynową zmianą.