Błędy TLS tylko w firmowym VPN: napraw właściwy magazyn zaufania
To samo narzędzie, ten sam laptop, tylko VPN psuje TLS. Przeczytaj komunikat, znajdź pakiet CA, który czyta plik binarny, i dodaj jeden korzeń zamiast wyłączać weryfikację.
Kompilacja Go, instalacja Composera i klient Pythona działają w domu, a wszystkie zawodzą wewnątrz firmowego VPN. Ten wzorzec mówi o ścieżce, a nie o aplikacji. Coś na tunelu zmieniło łańcuch certyfikatów widziany przez twój proces albo zresetowało uścisk dłoni, zanim jakikolwiek łańcuch dotarł. Oba błędy wyglądają w terminalu podobnie i wymagają zupełnie innych reakcji.
Trzy komunikaty, trzy mechanizmy
Błąd x509 certificate signed by unknown authority oznacza, że zbudowano łańcuch, a jego korzenia brakuje w magazynie zaufania, którego używa ten proces. Błąd self-signed certificate in certificate chain zwykle oznacza, że proxy inspekcyjne odpowiedziało własnym certyfikatem, a to łańcuch, którego twoje środowisko nie rozpoznaje. SSL EOF podczas uścisku dłoni oznacza, że połączenie zamknięto, zanim wysłano jakikolwiek użyteczny certyfikat, i to jest urządzenie pośredniczące, które odrzuca ClientHello, a nie problem zaufania.
Dodanie flagi trybu niezabezpieczonego sprawia, że wszystkie trzy komunikaty znikają, a przechwytywanie zostaje na miejscu, i usuwa sprawdzenie, które złapałoby prawdziwego atakującego.
Znajdź pakiet, który proces naprawdę czyta
Firmowy korzeń zainstalowany w magazynie Windows naprawia przeglądarki i aplikacje .NET, które korzystają z magazynu systemowego. Nic nie robi dla kompilacji działającej w kontenerze, który nosi własny pakiet CA, ani dla procesu Pythona z certifi czy procesu Node z jego dołączoną listą. Go czyta pulę systemową środowiska, w którym działa plik binarny, czyli kontenera, a nie laptopa. Jedna maszyna daje więc jednocześnie działającą przeglądarkę i zawodzące narzędzie kompilacji.
Pytaj narzędzie, zamiast zakładać. python3 -c "import ssl; print(ssl.get_default_verify_paths())" wypisuje pliki, które Python sprawdzi, a node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" pokazuje, czy nadpisanie jest już ustawione. W przypadku kontenera uruchom to samo sprawdzenie wewnątrz obrazu, bo to środowisko kompilacja naprawdę wykorzystuje.
Zainstaluj jeden korzeń tam, gdzie działa kompilacja
Pobierz korzeń inspekcji z IT jako plik PEM i zweryfikuj jego odcisk palca osobnym kanałem, zanim mu zaufasz. W obrazach opartych na Debianie skopiuj go do /usr/local/share/ca-certificates/ i uruchom update-ca-certificates; obrazy z rodziny RHEL używają update-ca-trust po umieszczeniu pliku w /etc/pki/ca-trust/source/anchors/. W kompilacji kontenera dodaj te kroki przed zawodzącym poleceniem, aby warstwa została zapisana w pamięci podręcznej ponad instalacją zależności.
Dla lokalnego devcontainera zamontuj PEM i uruchamiaj to samo polecenie aktualizacji przy starcie, zamiast zapiekać je w osobistym obrazie, którego nikt inny nie odtworzy. Narzędzia dostarczające własny pakiet potrzebują własnego udokumentowanego nadpisania: pip ma ustawienie certyfikatu, npm ma ustawienie cafile, a większość pozostałych akceptuje standardowe zmienne środowiskowe.
To nie to samo co akceptowanie dowolnego certyfikatu. Dodajesz jeden konkretny korzeń, uzyskany od strony przeprowadzającej inspekcję, do jednego środowiska, a weryfikacja pozostaje włączona dla każdego innego łańcucha. Zapisz, który plik dodano i kiedy wygasa, bo korzeń inspekcji jest odnawiany jak każdy inny CA.
Gdy uścisk dłoni umiera przed certyfikatem
Jeśli nic nie zostanie przedstawione, żadna zmiana magazynu zaufania nie pomoże. Porównaj to samo żądanie z tunelem włączonym i wyłączonym, a następnie sprawdź łańcuch bezpośrednio za pomocą openssl s_client -connect host:443 -servername host -showcerts. Połączenie, które kończy się poza VPN, a wewnątrz zostaje zresetowane, jest decyzją polityki urządzenia pośredniczącego, a lekarstwem jest wyjątek dla tego hosta, a nie kolejny certyfikat. Poproś o przepuszczenie rejestru pakietów lub punktu końcowego API bez zmian.
Dzielenie tunelu, aby narzędzie omijało VPN, pozwala uniknąć inspekcji tego ruchu, co może naruszać politykę i nie czyni narzędzia godnym zaufania.
Zapisz wynik dla każdego narzędzia
Krótka notatka wymieniająca plik binarny, czytany przez niego plik zaufania, zmienną środowiskową w grze i zatwierdzony wyjątek oszczędza następnej osobie całej diagnozy. Prowadź notatkę dla każdego narzędzia, a nie dla każdego laptopa, bo laptop rzadko jest tym, co się zmieniło.
I trzymaj dwa zdania osobno w zgłoszeniu: zainstalowaliśmy konkretny firmowy korzeń i wyłączyliśmy weryfikację. Tylko jedno z nich jest działaniem wsparcia.