Jak zaimportować certyfikat VPN na Androidzie i zweryfikować klucz

Zaimportowanie certyfikatu klienta VPN na Androidzie zajmuje kilka minut. Sprawdzenie, czy trafił we właściwe miejsce, zajmuje więcej czasu i właśnie ten etap większość ludzi pomija, gdy okno instalacji zgłasza sukces. Komunikat o sukcesie oznacza tylko, że plik został przeanalizowany. Nie mówi nic o tym, który dostawca trzyma klucz prywatny ani czy kopia wciąż leży w folderze Downloads.

Krok 1: Przeczytaj plik P12, zanim opuści twoją maszynę

Zacznij od samego pliku. Jeśli nie potrafisz nazwać podmiotu, wystawcy i daty ważności w nim zawartych, importujesz coś, czego później nie zweryfikujesz.

Pakiet PKCS#12 zwykle zawiera certyfikat klienta, jego klucz prywatny i łańcuch wystawcy. openssl pkcs12 -in client.p12 -info -noout wypisuje MAC i algorytmy szyfrowania bez wypluwania materiału klucza, więc widzisz, czy pakiet jest chroniony hasłem i jakim szyfrem. Następnie uruchom keytool -list -v -keystore client.p12 -storetype PKCS12, aby uzyskać alias, odcisk SHA-256 i okno ważności, które porównasz z telefonem.

Wyślij hasło innym kanałem niż plik albo przekaż plik w zarządzanym przepływie dystrybucji, który nie zostawia kopii. Hasło wklejone w tę samą wiadomość czatu co archiwum zamienia dwie kontrole w jedną.

Krok 2: Zainstaluj go w gnieździe, które aplikacja VPN naprawdę czyta

Na fabrycznym Androidzie 11 do 14 ścieżka prowadzi przez Ustawienia, Zabezpieczenia, Szyfrowanie i dane logowania, Zainstaluj certyfikat, następnie VPN i certyfikat użytkownika aplikacji. Sformułowania i zagnieżdżenie zmieniają się między wersjami i nakładkami producentów, więc podążaj za etykietą typu danych logowania, a nie za zapamiętaną pozycją menu. W profilu służbowym instaluj od wewnątrz strony służbowej, ponieważ dane logowania nie przekraczają granicy profilu.

Nie umieszczaj tożsamości klienta w gnieździe certyfikatu CA. To gniazdo zasila magazyn zaufania użytkownika, a od Androida 7 aplikacje ignorują CA dodane przez użytkownika, chyba że pozwala na to ich konfiguracja bezpieczeństwa sieci, więc certyfikat klienta pozostawiony tam nigdy nie pojawia się w selektorze kluczy VPN.

Niektóre klienty VPN nigdy nie dotykają magazynu systemowego i zamiast tego importują P12 do własnego katalogu aplikacji. To uzasadniona konstrukcja, ale zmienia każdy kolejny krok: klucz żyje teraz w piaskownicy aplikacji i jest dokładnie tak silny, jak ta aplikacja radzi sobie z własnym magazynem. Sprawdź dokumentację klienta, zanim założysz, że KeyChain bierze udział.

Krok 3: Udowodnij, który dostawca trzyma klucz

Import potwierdza analizę, a nie wsparcie sprzętowe. Od Androida 12 KeyInfo.getSecurityLevel() raportuje, czy klucz znajduje się w Zaufanym środowisku wykonawczym, w StrongBox czy w oprogramowaniu, i zastępuje starsze wywołanie isInsideSecureHardware(). Jeśli klient VPN nie pokazuje tej wartości, odcisk z kroku 1 jest twoim rozwiązaniem zapasowym. Certyfikat ponownie zakodowany podczas importu nie będzie zgodny bajt po bajcie, ale klucz publiczny i podmiot nadal będą.

Nieeksportowalny nie znaczy bezużyteczny. Klucza, który nie może opuścić urządzenia, nadal może użyć każda aplikacja, której użytkownik zezwoli na wybór tego aliasu, i dlatego monit o alias jest realną kontrolą, a nie formalnością. Dokumentacja Android Keystore jest warta jednej lektury, jeśli podejmujesz tę decyzję projektową.

Potem policz kopie, które zrobiłeś. P12 na laptopie, ten w załączniku zgłoszenia i ten w zeszłomiesięcznej kopii zapasowej to nadal ważne tożsamości, dopóki wystawca ich nie unieważni. Ochrona sprzętowa instancji na telefonie nic dla nich nie robi.

Krok 4: Ustal, do kogo należy wymóg blokady ekranu

Mieszają się tu trzy sekrety: PIN odblokowania urządzenia, hasło klucza prywatnego i hasło konta VPN. Monit o jeden nigdy nie jest prośbą o zresetowanie pozostałych, a zresetowanie niewłaściwego jest sposobem, w jaki ludzie zamykają się poza profilem, który działał dobrze.

Gdy administrator urządzenia lub polityka zarządzanego profilu wymaga blokady, wymóg należy do tej polityki, a nie do certyfikatu. adb shell dumpsys device_policy wymienia aktywnych administratorów i jakość hasła, którą egzekwują, co jest najszybszym sposobem sprawdzenia, czy agent MDM jest powodem zmiany twoich reguł PIN. Usunięcie certyfikatu nie złagodzi polityki, a usunięcie polityki jest decyzją administracyjną, a nie korektą ustawień.

Spodziewaj się też kompromisu w użyteczności. Jeśli klucz wymaga autoryzacji użytkownika, tunel nie może wstać przed pierwszym odblokowaniem, więc zaplanowane synchronizacje i zdalne wybudzenia zawodzą z założenia. Zdecyduj o tym przed wdrożeniem, nie po.

Unikaj skrótu polegającego na edycji locksettings.db albo odtwarzaniu starego obejścia dla zapomnianego wzoru. Te procedury pisano pod konkretne kompilacje, mogą zostawić magazyn danych logowania w stanie, którego framework już nie oczekuje, i nigdy nie zmieniają polityki, która zażądała blokady.

Krok 5: Wycofaj tożsamość i zweryfikuj odmowę

Wycofanie ma trzy części i tylko pierwsza jest lokalna. Usuń profil VPN, skasuj certyfikat użytkownika w Ustawienia, Zabezpieczenia, Szyfrowanie i dane logowania, Dane logowania użytkownika, a następnie zleć wystawcy unieważnienie numeru seryjnego certyfikatu. Samo lokalne usunięcie zostawia dane logowania, które serwer nadal akceptuje, jeśli ktoś zachował P12.

Zweryfikuj wynik, zamiast go zakładać. Spróbuj połączenia z wycofanym profilem i potwierdź, że serwer je odrzuca. Tunel, który nadal wstaje, oznacza, że unieważniłeś zły numer seryjny albo klient po cichu przeszedł na inną zainstalowaną tożsamość.

Jeśli wycofujesz nieudany import, zaimportuj ponownie z oryginalnego zaszyfrowanego pakietu i ponownie sprawdź odcisk, zamiast używać ponownie odszyfrowanego pliku klucza pozostawionego na dysku.