Certyfikat VPN na Macu: dlaczego wybór tożsamości pozostaje pusty
Klient potrzebuje certyfikatu wraz z kluczem prywatnym, w magazynie, który odczytuje. Sprawdź najpierw tożsamość, a potem czy brama ją akceptuje.
Zainstalowałeś certyfikat, pojawia się w Keychain Access pod przyjazną nazwą, a wybór tożsamości klienta VPN nadal jest pusty. Klient nie szuka certyfikatu. Szuka tożsamości: certyfikatu powiązanego z kluczem prywatnym, który może dowieść posiadania, przechowywanego tam, gdzie klient ma prawo go czytać.
To, o co prosi klient, to tożsamość
Struktura bezpieczeństwa Apple traktuje certyfikat i tożsamość jako różne obiekty. Certyfikat to dane publiczne. Tożsamość to ten certyfikat wraz z kluczem prywatnym, i tylko tożsamość może ukończyć wyzwanie. Zaufany certyfikat CA pozwala natomiast klientowi ocenić wystawcę; nie czyni maszyny posiadaczem wydanych poświadczeń klienta.
| Item | What it can do | What it cannot do |
|---|---|---|
| CA or server certificate | Validate the gateway's chain | Authenticate this client |
| Client certificate without key | Nothing for authentication | Prove possession of anything |
| Identity (cert plus key) | Answer the authentication challenge | Guarantee the gateway accepts it |
Dlatego import pliku .cer nigdy nie tworzy użytecznej tożsamości klienta. Plik zawiera tylko materiał publiczny, a żadna zmiana nazwy ani zaufanie nie czyni z niego pary kluczy.
Trzy powody, dla których wybór pozostaje pusty
Pierwszy to brakujący klucz prywatny, co oznacza, że proces rejestracji lub importu go nie dostarczył. Drugi to magazyn, którego klient nie sprawdza: profil w zakresie użytkownika zagląda do pęku kluczy użytkownika, a element umieszczony w magazynie systemowym może być dla niego niewidoczny. Trzeci to niezgodność przeznaczenia lub polityki, gdy certyfikat istnieje, ale nie jest ważny do uwierzytelniania klienta zgodnie z regułami wdrożenia.
security find-identity -v -p ssl-clientTo wylicza tożsamości, które system uznaje za ważne do uwierzytelniania klienta. Jeśli liczba wynosi zero, problem jest powyżej klienta VPN i żadna edycja profilu go nie naprawi. Jeśli tożsamość pojawia się tutaj, ale nie w kliencie, różnica tkwi w magazynie lub zakresie klienta.
Gdzie mieszka klucz prywatny i kto może go używać
Gdy importujesz tożsamość przez Keychain Access, okno importu proponuje docelowy pęk kluczy. To, który cel jest właściwy, zależy od klienta i od tego, czy profil ma zakres użytkownika, czy urządzenia. Stara odpowiedź zalecająca pęk kluczy systemowych nie jest uniwersalną regułą, a kopiowanie elementów między magazynami nie jest naprawą.
System Roots to zbiór zaufania. Umieszczenie tam certyfikatu zmienia, którym wystawcom system ufa; nie tworzy klucza prywatnego i nie jest magazynem tożsamości. Przenoszenie niepowiązanych certyfikatów, aby zapełnić wybór, to rodzaj naprawy, po której maszyna pozostaje z trwale rozszerzonym zbiorem zaufania.
Dostęp do klucza prywatnego to osobna kontrola. Przyznanie każdej aplikacji uprawnienia do użycia klucza rozwiązuje problem wyboru jednego klienta i przekazuje tę samą możliwość wszystkiemu innemu na maszynie. Przyznaj je klientowi, który go potrzebuje, i sprawdź, czy klucz jest oparty na sprzęcie lub oznaczony jako nieeksportowalny; jeśli tak, trzeba użyć obsługiwanego dostawcy, a nie wyeksportowanej kopii.
Jak profil wskazuje poświadczenie
W zarządzanej natywnej konfiguracji IKEv2 profil odwołuje się do ładunku poświadczenia przez PayloadCertificateUUID. Znaczenie mają wskazana tożsamość i sposób jej udostępnienia; edycja nazwy wyświetlanej w profilu nie naprawia odwołania wskazującego na niewłaściwy ładunek lub na taki, który nigdy nie dostarczył klucza.
Dostawca zewnętrzny może używać zupełnie innego mechanizmu wyboru, na przykład własnego magazynu lub monitu systemowego. Przeczytaj dokumentację tego dostawcy, zamiast przenosić założenia natywnego profilu, i zweryfikuj odwołanie w profilu faktycznie zainstalowanym, a nie w wersji roboczej w konsoli zarządzania.
Wybór i akceptacja to osobne etapy
Wypełniony wybór oznacza, że klient potrafi znaleźć i użyć tożsamości. Nie mówi nic o tym, czy brama ją zaakceptuje. Serwer nadal sprawdza wystawcę, okno ważności, status unieważnienia i mapowanie tego poświadczenia na konto.
Przetestuj oba etapy jawnie, w tej kolejności. Potwierdź, że tożsamość jest oferowana, połącz się, a następnie poproś właściciela bramy o potwierdzenie, które poświadczenie zostało przedstawione i która reguła mapowania je wykorzystała. Jeśli klient oferuje tożsamość, a serwer ją odrzuca, pozostała praca jest po stronie serwera. Ponowna instalacja certyfikatu na Macu nie zmieni tego wyniku, ilekroć by się ją powtórzyło.