Logowanie VPN z certyfikatem na Macu: tożsamość, użycie klucza czy zaufanie do bramy?
Za logowaniem z certyfikatem stoją trzy decyzje: która tożsamość jest wybierana, czy komponent VPN może użyć swojego klucza i czy brama jest zaufana.
Logowania VPN oparte na certyfikacie proszą Maca o coś węższego niż hasło: użyj tego konkretnego klucza prywatnego, w tym kontekście wykonania, aby potwierdzić tożsamość wobec tej bramy. Gdy się nie udaje, komunikat zwykle opisuje tylko ostatnią rzecz, która poszła źle, a ona rzadko jest przyczyną. Przejście przez trzy decyzje w kolejności, w jakiej podejmuje je system, utrzymuje diagnozę uczciwą i nie pozwala traktować lokalnego problemu z uprawnieniami jako błędu walidacji łańcucha.
Przejdź przez logowanie w kolejności, w jakiej robi to Mac
Najpierw klient wybiera tożsamość: certyfikat sparowany z użytecznym kluczem prywatnym, dostępny przez obsługiwany magazyn lub dostawcę poświadczeń. Potem komponent VPN prosi o wykonanie operacji kryptograficznej tym kluczem, a lokalny model autoryzacji odpowiada. Dopiero gdy oba się udadzą, następuje uścisk dłoni zdalny, w którym Mac ocenia bramę, a brama ocenia dowód klienta.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
Czytaj tabelę od góry do dołu i zatrzymaj się na pierwszym wierszu, który zawodzi. Wszystko poniżej błędu jest nieudowodnione, dlatego „certyfikat nie jest zaufany” to tak częsty i tak niewiarygodny wniosek.
Co faktycznie obejmuje lokalne uprawnienie
W modelu pęku kluczy macOS chronione elementy noszą reguły dostępu właściwe dla operacji oraz listę zaufanych aplikacji. Podpisywanie kluczem prywatnym jest jedną z takich operacji, a reguły dotyczą pliku wykonywalnego, który to robi, a nie certyfikatu jako dokumentu. Dokumentacja Apple dotycząca kontroli dostępu rysuje też granicę między tym modelem a pękiem kluczy iCloud i układem grup dostępu, więc rada napisana dla jednego nie przenosi się na drugi.
Wynikają z tego dwie konsekwencje. Widoczny na liście certyfikat publiczny nie dowodzi, że komponent działający w tle VPN może w ogóle dotrzeć do tego klucza. A uprawnienie przyznane aplikacji frontowej nic nie mówi o osobnym pomocniku czy rozszerzeniu sieciowym, bo to inny kod o innych tożsamościach.
Ustal rzeczywistą implementację i jej obsługiwany mechanizm udostępniania poświadczeń, zamiast kopiować ścieżkę pliku wykonywalnego ze starego klienta. Najpierw potwierdź, którą tożsamość system w ogóle zaproponuje:
security find-identity -v -p ssl-clientJak czytać errSecInteractionNotAllowed
Ten status zgłasza niedozwoloną interakcję z Security Server i nic nie mówi o łańcuchach certyfikatów. Czytaj go razem z operacją, która go wywołała: żądanie podpisania wysłane z kontekstu, który nie może pokazać okna, zawiedzie w ten sposób nawet wtedy, gdy klucz i certyfikat są całkowicie ważne. Zacząć trzeba od operacji, która to zapisała, a nie od magazynu certyfikatów. Cokolwiek zmienisz w kotwicach zaufania, pozostawi błąd dokładnie tam, gdzie był.
Traktuj więc kod jako powód, by zbadać kontekst wykonania i autoryzację. Potraktowanie go jako dowodu, że CA bramy nie jest zaufany, prowadzi do niewłaściwej połowy problemu, a zmiana tam wprowadzona w ogóle nie wpłynie na błąd.
Naprawiaj wąsko, nie szeroko
Zacznij od instrukcji rejestracji lub importu właściciela połączenia. Zapisz wersję klienta, zakres profilu, wybraną tożsamość i pierwszy istotny lokalny błąd, bo te cztery fakty są potrzebne przy przekazaniu do wsparcia i od nich zależy późniejsze porównanie. Profil zarządzany lub tożsamość oparta na sprzęcie mogą wymagać, by administrator lub dostawca naprawił przekazanie, i żadna liczba lokalnych kliknięć tego nie zastąpi.
Gdy produkt oczekuje zgody użytkownika, ustal, który komponent o nią prosi, i zatwierdź tylko ten dostęp w obsługiwanym przepływie. Gdy komponent nie ma sposobu wywołać okna w kontekście, w którym działa, przygotowanie musi podążać drogą udokumentowaną przez dostawcę, a nie oknem wyłudzonym z innego terminala.
Dwie zmiany są łączone w starszych poradach i obie są zbyt szerokie. Przyznanie każdej aplikacji dostępu do klucza prywatnego rozszerza lokalne użycie klucza daleko poza wymaganie, a ustawienie certyfikatu na Always Trust zmienia ocenę certyfikatów dla wszystkiego na maszynie. Żadna z nich nie wyraża „ta zatwierdzona implementacja VPN, używająca tej zamierzonej tożsamości”.
Sprawdź lokalnie, zanim odczytasz bramę
Po naprawie potwierdź, że lokalna operacja się udaje zanim zinterpretujesz jakąkolwiek odpowiedź z drugiej strony. Jeśli podpisywanie teraz działa, późniejsze odrzucenie nazwy, łańcucha lub dopuszczenia klienta jest nowym wynikiem, a nie nawrotem, i należy do innej decyzji z innym właścicielem.
Użyteczne przekazanie nazywa tę z trzech decyzji, która zawiodła, i na tym się zatrzymuje. Nigdy nie zawiera klucza prywatnego i nigdy nie resetuje niepowiązanych elementów pęku kluczy w nadziei, że czysta karta pomoże. Te dwa nawyki ustal przed incydentem, a nie w jego trakcie, gdy pokusa, by spróbować wszystkiego naraz, jest najsilniejsza. Zgłoszenie, które mówi „odbudowano pęk kluczy”, prawie nic nie mówi następnemu czytelnikowi o pierwotnej usterce.