Dlaczego OpenVPN nadal prosi o plik klucza prywatnego, gdy jest token

Wkładasz token, narzędzie samego dostawcy go widzi, a klient VPN nadal prosi o plik klucza prywatnego. To pytanie nie jest dowodem, że token nie jest obsługiwany. Zwykle oznacza, że profil nigdy nie kazał klientowi użyć tokenu, więc wrócił do danych wejściowych certyfikatu i klucza, których oczekuje domyślnie.

Dwie osobne wartości muszą być poprawne, zanim to cofnięcie ustanie: dostawca, który udostępnia token, oraz tożsamość certyfikatu w nim. Są podawane przez różne opcje i łatwo je pomylić.

Klient prosi o plik, bo tak mu każe profil

Profil domyślny oczekuje pliku certyfikatu i pliku klucza prywatnego albo jednego pakietu PKCS#12. Gdy tych danych wejściowych brakuje, klient nie ma czego wczytać i zachowuje się prawie jak przy brakującym pliku, dlatego objaw jest czytany jako zepsuta ścieżka, a nie brakujący mechanizm. Ścieżka PKCS#11 zastępuje te dane wejściowe, zamiast je uzupełniać, więc profil, który nadal wskazuje plik klucza, będzie dalej używał tego pliku. Usuń dane wejściowe plików świadomie i pozwól tokenowi dostarczyć obie połowy.

Opcja dostawcy wskazuje bibliotekę oprogramowania pośredniego, a nie urządzenie i nie certyfikat. To, czy spakowany klient może wczytać tę bibliotekę, zależy od sposobu jej zbudowania, w tym od opcjonalnego wsparcia p11-kit, które niektóre kompilacje włączają, a inne pomijają. Ogólny poradnik nie powie ci, jaki układ ma twoja paczka.

Serializowana tożsamość to inna wartość

Tożsamość certyfikatu to długi serializowany ciąg tworzony przez proces wykrywania, i nie jest to ścieżka biblioteki, PIN tokenu ani nazwa konta VPN. Często zawiera znaki wymagające cudzysłowów, a wartość bez cudzysłowów może zostać obcięta lub błędnie odczytana bez jasnego błędu. Użyj własnej opcji klienta wykrywanie tożsamości, aby wylistować to, co udostępnia token, a potem dokładnie skopiuj zamierzony wpis. Wybranie pierwszego obiektu z listy to sposób, w jaki urządzenie ostatecznie przedstawia niewłaściwy certyfikat.

Wynik wykrywania odpowiada też na wcześniejsze pytanie: czy token jest w ogóle widoczny przez tego dostawcę. Jeśli nic nie listuje, problem leży powyżej klienta VPN i należy do oprogramowania pośredniego.

Proces, który się łączy, musi dotrzeć do tokenu

Operacja na tokenie, która działa w twojej sesji pulpitu, niczego nie dowodzi o usłudze systemowej. Usługa może działać jako inny użytkownik, w innej przestrzeni nazw montowania, ze ścieżką modułów pomijającą bibliotekę dostawcy lub bez uprawnienia do otwarcia węzła urządzenia. Ustal, który proces faktycznie utrzymuje połączenie, i testuj z tego kontekstu.

Obsługa PIN zasługuje na osobną decyzję. Implementacja referencyjna oferuje pamięć podręczną PIN i chronioną ścieżkę uwierzytelniania, a obie istnieją po to, by operator wybrał przepływ pracy, zamiast go wymyślać. Nie zamieniaj wymagania bez nadzoru w PIN w postaci jawnej w współdzielonym profilu, bo to wymienia ochronę tokenu na wygodę. Tam, gdzie token zabrania eksportu klucza, podpisywanie odbywa się na urządzeniu, a PIN jest jedynym lokalnym sekretem. Traktuj go z ostrożnością, jakiej to wymaga.

Czego token nie zastępuje

Token uwierzytelnia klienta zgodnie z wdrożoną polityką i nie zastępuje sprawdzeń klienta wobec serwera. Pomyślnie wybrany certyfikat nie jest pozwoleniem na przyjęcie nieoczekiwanego certyfikatu bramy, a oba sprawdzenia chronią przeciwne kierunki.

Rejestracja nadal musi odbyć się u wystawcy, a brama nadal musi autoryzować tożsamość.

W celu akceptacji rozdziel etapy: dostawca się wczytuje, zamierzony certyfikat zostaje znaleziony, klucz prywatny jest używany z lokalną autoryzacją, VPN się uwierzytelnia, a operacja na zasobie kończy się powodzeniem. Zatrzymaj się na pierwszym nieudanym etapie, zamiast przechodzić przez hasła i reinstalować stos kryptograficzny.

Zapisuj wersje, własność modułów, wybrany identyfikator publiczny i oczyszczone błędy, a PIN-y i pakiety poświadczeń trzymaj poza tym zapisem.