Bramy wymieniają certyfikaty, a klient, który wczoraj się łączył, zaczyna zatrzymywać się na pierwszej wymianie TLS. Komunikat podaje powód weryfikacji, a nie awarię sieci, i sama maszyna się nie zmieniła, co jest użyteczną wskazówką. Zepsuła się relacja między przedstawianym teraz certyfikatem a korzeniami, które klient jest gotów brać pod uwagę. Naprawienie tego to decyzja o zaufaniu, więc podejmij ją, zanim wpiszesz opcję.

Przeczytaj błąd, zanim zmienisz jakiekolwiek ustawienie zaufania

Błąd typu brakującego podpisującego oznacza, że łańcuch kończy się na czymś, czego klient nie akceptuje. Może to być odnowiony certyfikat wewnętrznego organu, zamiennik od organu publicznego albo urządzenie pośrodku przedstawiające własny certyfikat. Samo sformułowanie nie potrafi rozróżnić tych przypadków, więc przed decyzją spójrz na wystawcę.

Uruchom połączenie raz na pierwszym planie i pozwól mu się nie udać, bo interaktywne wyjście zawiera nazwę serwera, łańcuch wystawcy i odcisk palca obliczony przez klienta. Porównaj tego wystawcę z organem, który twoja organizacja naprawdę prowadzi. Jeśli odcisk się zmienił, a wystawca nie, traktuj to jako podejrzane, dopóki odnowienie nie zostanie potwierdzone kanałem, któremu już ufasz. Zgadywanie w tym momencie to droga, na której ktoś w końcu przypina klucz podsłuchującego.

Zapisz wersję klienta w tej samej notatce. Znaczna część awarii wyglądających jak problemy z zaufaniem pochodzi ze starszego klienta, który trafia na nowszą wymianę bramy.

Wybierz między zaufaniem wystawcy a przypięciem jednego klucza

Oba warianty pozwalają połączeniu się udać. Psują się później w przeciwne strony, więc wybór należy do awarii, którą potrafisz znieść.

ApproachGood fitWhat breaks it
Trust the issuing CA with --cafileInternal PKI you can obtain over an already trusted channelCA rotation, or a client that still falls back to public roots
Pin one key with --servercertNo CA relationship, or exactly one key should ever be acceptedAny reissue that generates a new key pair

Sięgnij po plik CA, gdy certyfikat pochodzi od organu, który możesz zweryfikować niezależnie, bo odnowienia działają wtedy dalej bez dotykania argumentów klienta. Połącz go z przełącznikiem wyłączającym korzenie systemowe, inaczej publiczny organ może spełnić sprawdzenie w twoim imieniu. Zamiast tego przypnij, gdy brama nie ma CA, które możesz zdobyć, albo gdy celem jest najwęższy możliwy wyjątek. Żadna droga nie jest bezpieczniejsza w oderwaniu: CA skaluje się przez odnowienia, przypięcie łatwiej przejrzeć.

Którykolwiek wybierzesz, zaufana wartość musi dotrzeć kanałem, któremu ufano przed zmianą. Administrator, sesja konsoli na bramie albo wcześniej wykonana kopia — wszystkie się kwalifikują. Kopiowanie dowolnego odcisku wyświetlanego przez monit jest wygodne i jest dokładnie tym, na co liczy podsłuchujący.

Umieść wartość w poleceniu, które naprawdę uruchamiasz

Przypięcie jedzie w opcji certyfikatu serwera, a jej przedrostek decyduje o kodowaniu: szesnastkowe skróty klucza publicznego pod sha1 lub sha256 oraz przypięcie klucza base64 pod pin-sha256. Podanie jej wyłącza też zaufanie systemowe dla tego uruchomienia, więc przypięty klucz staje się całą decyzją.

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

Klient dopasowuje skrócony skrót, przyjmując zaledwie cztery znaki po przedrostku, co jest pułapką, a nie udogodnieniem. Skrócona wartość przechodzi lokalnie i nadal nie identyfikuje zamierzonej bramy. Skopiuj pełny ciąg wydrukowany przez klienta przy pierwszej próbie, zamiast wpisywać go ponownie z komunikatu. Potem przenieś gotową opcję do skryptu opakowującego, pliku jednostki lub profilu, który uruchamia połączenie, aby decyzja o zaufaniu była przeglądalna, a późniejsze zmiany były zamierzone.

Launchery pulpitu i wtyczka NetworkManager przechowują własną kopię argumentów połączenia. Skrypt edytowany na dysku nie dociera do wcześniej zaimportowanego profilu, więc zapisana wartość nadal wygrywa.

Obsłuż przełączenie, nie zamykając się na zewnątrz

Opcję można podać więcej niż raz, więc planowana zmiana może przyjąć klucz wychodzący i przychodzący razem. Dodaj nowe przypięcie, zanim brama się przełączy, trzymaj oba na liście, dopóki sesje migrują, i usuń wycofane, gdy starego klucza już nie ma. To okno potrzebuje właściciela, bo zapomniane podwójne przypięcie zostawia klucz zaufany bez nikogo, kto by go pilnował. Przebudowa tworząca nową parę kluczy psuje czyste przypięcie, a odzyskiwanie to ta sama procedura w drugą stronę.

Zapisz datę zmiany obok przypięcia. Przypięcie bez daty przeglądu to przyszła awaria z mylącym komunikatem błędu.

Wyklucz wersję klienta przed edycją zaufania

Przestarzały klient może zawieść podczas parsowania odpowiedzi uwierzytelniania, którą brama od tego czasu zmieniła, a komunikat powierzchniowy nadal mówi o połączeniu, nie o parserze. Porównaj zainstalowaną wersję z tym, co dokumentuje brama, i przetestuj bieżący pakiet w profilu jednorazowym, zanim zmienisz jakiekolwiek ustawienie zaufania.

openconnect --version

Po naprawie sprawdź dwie rzeczy, a nie jedną: portal ładuje się przez tunel, a zwykły adres wewnętrzny odpowiada. Zakończone uściski dłoni dowodzą tylko, że decyzja o zaufaniu została przyjęta.

Powiązane artykuły