Odnowiony certyfikat VPN: część klientów nadal go odrzuca

Połowa środowiska łączy się ponownie po odnowieniu, a trzy urządzenia odmawiają, każde z ostrzeżeniem o tożsamości bramy. Samo odnowienie jest rutynowe. To, co trzymają te trzy urządzenia, to przypięcie do starego obiektu, a przypięcie nie jest listą CA, sprawdzeniem nazwy ani wpisem w magazynie zaufania. Porównaj trzy mechanizmy, zanim dotkniesz jakiegokolwiek klienta.

Jedno odnowienie, dwa zachowania

Klienci, którzy łączą się ponownie, mają decyzję o zaufaniu, która nadal przechodzi, a ci, którzy odmawiają, mają wymóg, którego nowy certyfikat nie spełnia. Ta różnica to informacja, nie szum. Przeczytaj dokładnie komunikat klienta, który zawodzi. Niezgodność nazwy, nieznany wystawca i zmieniony odcisk to trzy różne werdykty, a tylko ostatni wskazuje na przypięcie.

Sprawdź też, który profil wybrał zawodzący klient. Zaimportowana kopia żyjąca we własnym magazynie nie zmienia się, gdy administrator edytuje oryginalny plik gdzie indziej.

Odnowienie zastępuje obiekt, nie tylko datę

Odcisk identyfikuje zakodowaną zawartość certyfikatu. Odnowienie tworzy nowy certyfikat, więc odcisk zmienia się nawet wtedy, gdy nazwa podmiotu i klucz publiczny pozostają identyczne. To jest oczekiwane i nieszkodliwe dla klientów, którzy ufają CA i weryfikują nazwę. To jest zgubne dla klienta skonfigurowanego tak, by akceptował dokładnie jeden certyfikat, i jest też zgubne dla klienta, którego magazyn zaufania nigdy nie otrzymał nowego wystawcy.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

Drugi wiersz odpowiada na inne pytanie, czy para kluczy przetrwała. Odnowienie, które używa ponownie klucza, zachowuje tę wartość i zmienia tylko certyfikat, i to jest dokładnie ten przypadek, w którym administrator ma pokusę założyć, że nic się nie zmieniło. Sprawdź certyfikat wdrożony, a nie ten na hoście budowania. Porównanie pliku w repozytorium dowodzi, co zostało wygenerowane, a nie tego, co odbiorca prezentuje w tej chwili.

Przeczytaj, co przypina klient

Niektóre klienty trzymają odcisk w swoim profilu i porównują go przy każdym połączeniu. Inne przechowują go w magazynie zaufania platformy, a jeszcze inne polegają tylko na CA. Naprawa różni się w każdym przypadku, więc najpierw zidentyfikuj mechanizm.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

Pierwsze polecenie pokazuje przypięcie w konwencjonalnym profilu; drugie pokazuje odcisk, który punkt końcowy naprawdę obsługuje teraz. Gdy te dwa się różnią, zlokalizowałeś awarię bez zgadywania. Nie wklejaj nowej wartości do każdego klienta, który się skarży. Klient odrzucający z powodu wystawcy będzie odrzucał dalej, a ty wmówisz sobie, że problemem był odcisk, kiedy nim nie był.

Porównaj certyfikat obsługiwany przez każdy backend

Przerywane wyniki zwykle oznaczają więcej niż jeden punkt końcowy, a odnowienie zastosowane na jednym węźle zostawia pozostałe prezentujące stary obiekt. Porównaj każdy backend po adresie, a nie po wspólnej nazwie.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Pula, w której jeden węzeł zostaje w tyle, wyjaśnia klienta, który łączy się przy drugiej próbie, a zawodzi przy pierwszej. Wyjaśnia też kontrolę monitoringu, która przechodzi, podczas gdy użytkownicy się skarżą. Najpierw napraw opóźnienie. Wdrażanie konfiguracji zaufania, zanim każdy węzeł obsłuży nowy certyfikat, tworzy okno, w którym nic nie działa, a wdrożenie jej później zostawia klientów z nieprzewidywalnymi błędami.

Zmieniaj zaufanie zarządzaną ścieżką

Potwierdź wymianę przez już zaufany kanał administracyjny, zanim przyjmiesz ją gdziekolwiek. Wiarygodna data ważności nie jest dowodem własności. Zaktualizuj zarządzaną konfigurację przez proces, który jest jej właścicielem, z każdym planowanym nakładaniem się akceptowalnych tożsamości, i zachowaj weryfikację nazwy wymaganą przez wdrożenie. Przypięcie bez sprawdzania nazwy to słabsza konstrukcja niż zaufanie do CA, które zastąpiło.

Następnie zweryfikuj każdego klienta, połącz się, potwierdź tożsamość, którą zaakceptował, i zanotuj wersję certyfikatu, której teraz ufa. Ostrzeżenie zignorowane raz ma zwyczaj wracać przy następnym odnowieniu.