ERR_SSL_PROTOCOL_ERROR: diagnoza błędu połączenia TLS

ERR_SSL_PROTOCOL_ERROR znaczy, że przeglądarka nie zdołała zestawić bezpiecznego połączenia z serwerem. Zanim cokolwiek zmienisz, sprawdź ten sam adres z innego urządzenia i z innej sieci, a potem odpytaj serwer poleceniem OpenSSL z nazwą SNI. Wynik powie ci, czy problem siedzi w kliencie, w sieci po drodze, czy na serwerze.

Ta strona prowadzi cię drogą właściciela serwera - od zgłoszenia do warstwy, którą naprawdę trzeba naprawić. Jeśli błąd widzisz na cudzej stronie, przejdź te same porównania, zapisz adres, moment, urządzenie, sieć i komunikat, a potem przekaż komplet właścicielowi. Z takim zestawem zacznie od właściwej warstwy, a nie od samego "nie działa".

Co oznacza ERR_SSL_PROTOCOL_ERROR?

ERR_SSL_PROTOCOL_ERROR to komunikat Chromium o błędzie protokołu SSL/TLS w warstwie sieciowej przeglądarki - tak definiuje go plik net/base/net_error_list.h w źródłach projektu. Przeglądarka mówi tylko tyle, że negocjacja bezpiecznego połączenia się nie powiodła. Nie mówi, które urządzenie zawiniło ani które ustawienie masz poprawić.

To ważne, bo pierwszy odruch bywa najdroższy: wymiana certyfikatu, czyszczenie pamięci podręcznej u każdego, kto się skarży, albo wyłączanie zabezpieczeń "na próbę". Żaden z tych ruchów nie wynika z samego komunikatu. Najpierw ustal, gdzie połączenie się urywa - dopiero potem coś zmieniaj.

Jedno pojęcie przyda ci się w całej diagnozie. Podczas negocjacji klient może przekazać serwerowi nazwę hosta przez SNI, żeby serwer obsługujący wiele stron na jednym adresie wybrał właściwą. Tożsamość usługi jest potem sprawdzana względem nazwy, której użył klient. Jak działa certyfikat i cała negocjacja - to opisuje osobna strona o certyfikatach i połączeniu TLS; tutaj zostajesz przy szukaniu warstwy, na której połączenie nie powstało.

Najpierw ustal zasięg błędu

Wyobraź sobie zgłoszenie z samego rana: klientka pisze, że twój sklep "wyświetla błąd SSL i nie da się nic kupić". Otwierasz stronę u siebie - działa bez zarzutu. Prosisz ją o próbę z telefonu na sieci komórkowej - działa. Wracacie na jej laptop w biurowym Wi-Fi - błąd. Jeszcze niczego nie naprawiłeś, a już wiesz najważniejsze: serwer odpowiada światu, a problem żyje gdzieś między jej biurem a resztą internetu. Bez tych dwóch prób zaczynałbyś od wymiany certyfikatu, który nie zawinił.

Dokładnie tę pracę wykonujesz trzema porównaniami, zawsze na tej samej nazwie hosta:

1. Sprawdź ten sam adres z drugiego urządzenia w tej samej sieci. Jeśli drugie urządzenie się łączy, różnica dotyczy ścieżki pierwszego klienta - choć jeszcze nie wiesz, którego jej elementu.
2. Sprawdź ten sam adres z urządzenia w innej sieci. Rozbieżność między sieciami zawęża podejrzenia do tego, czym te ścieżki się różnią - ale bez dalszego testu nie wskaże ci konkretnego pośrednika.
3. Na urządzeniu zgłaszającym błąd otwórz inne strony HTTPS. Jeśli działają, ten klient i ta sieć potrafią zestawić bezpieczne połączenie - z tamtymi serwerami. O twoim serwerze to jeszcze niczego nie dowodzi. Jeśli nie działa nic, wróć do porównania z drugim urządzeniem w tej samej sieci.

Przy każdej próbie zapisz urządzenie, sieć i godzinę. Zmienisz dwie rzeczy naraz - i nie będziesz umiał powiedzieć, która z nich odpowiada za różnicę w wyniku.

Znajdź miejsce terminacji TLS

Zanim odpalisz jakikolwiek test serwera, odpowiedz sobie na jedno pytanie: co właściwie kończy TLS dla tego hosta? Na podstawie DNS i własnej konfiguracji ustal, z czym łączy się klient - z CDN-em, load balancerem, reverse proxy czy bezpośrednio z originem. Jeśli publiczne połączenie kończy się na CDN-ie, grzebanie w konfiguracji originu niczego nie zmieni, bo klient nigdy z nim nie rozmawia.

Dla przykładu nginx przyjmuje połączenia TLS na gnieździe oznaczonym parametrem ssl i używa wskazanego w konfiguracji certyfikatu oraz klucza - to jest kandydat na terminator, gdy ruch trafia prosto do twojej maszyny.

Gdy warstwą kończącą TLS zarządza dostawca, przygotuj do zgłoszenia: nazwę hosta, moment próby ze strefą czasową, urządzenie, sieć i dokładny komunikat. Z takim kompletem właściciel warstwy odnajdzie twoją próbę w swoim logu - a ty nie musisz publikować niczego wrażliwego.

Sprawdź endpoint poleceniem OpenSSL

Test uruchom z maszyny poza badaną infrastrukturą - takiej, która widzi serwer tak, jak widzi go użytkownik. Test odpalony z samego originu bada inną drogę i nie zastąpi próby z zewnątrz.

openssl s_client -connect HOST:PORT_HTTPS -servername HOST -verify_hostname HOST -verify_return_error -brief

HOST zastąp nazwą, którą wpisuje klient, a PORT_HTTPS portem HTTPS twojego wdrożenia - standardowo jest to port 443, ale nie zakładaj tego na podstawie innego środowiska.

Co robią poszczególne opcje:

1. -servername HOST wysyła nazwę w SNI, więc serwer z wieloma stronami wybierze tę właściwą.
2. -verify_hostname HOST sprawdza certyfikat względem tej nazwy - tej samej, której używa klient.
3. -verify_return_error przerywa połączenie po błędzie weryfikacji, zamiast go tylko wypisać i grzecznie kontynuować.
4. -brief skraca wynik do podsumowania parametrów połączenia.

Pełną pracę z tym poleceniem i resztę jego opcji przejmuje test endpointu poleceniem OpenSSL. Tutaj wynik służy ci do jednego: przypisania błędu do warstwy i wyboru następnego kroku.

Odczytaj wynik bez nadinterpretacji

Wynik testu wpadnie do jednej z pięciu przegród - i pomylenie przegródek kosztuje więcej niż sam błąd:

1. brak połączenia transportowego - do negocjacji TLS w ogóle nie doszło, analiza zatrzymuje się wcześniej;
2. odpowiedź, która nie jest TLS-em - sprawdź, czy proces na badanym porcie na pewno mówi tym protokołem;
3. alert protokołu - negocjacja ruszyła i została zerwana;
4. błąd walidacji nazwy lub łańcucha - połączenie wstało, certyfikat nie przeszedł sprawdzenia dla tej nazwy;
5. poprawne zestawienie i walidacja dla badanego hosta.

Zapisz rzeczywisty wynik i godzinę próby w notatce z incydentu - dosłownie ten, który dostałeś, nie jego pamięciową rekonstrukcję. Alert protokołu i błąd walidacji traktuj jako osobne obserwacje; nie nazywaj przyczyny, której polecenie nie potwierdziło.

Uwaga na pułapkę wyniku poprawnego: dowodzi on tylko tego, że badany endpoint działał z tego miejsca i w tym momencie. Nie dowodzi, że działa dla wszystkich klientów, sieci ani dla innych nazw obsługiwanych przez tę samą infrastrukturę.

Tabela decyzji dla ERR_SSL_PROTOCOL_ERROR

Zestaw zasięg błędu z wynikiem testu i odczytaj warstwę oraz następny ruch:

Każdy wiersz kończy się testem, nie zmianą konfiguracji bez dowodu. Wniosek zawsze ogranicza się do badanego hosta, miejsca wykonania i momentu próby - tabela nie da ci więcej, niż włożyłeś w porównania.

Co sprawdzić na edge, proxy i originie

Na warstwie, którą wskazały DNS i konfiguracja, zobacz, który proces słucha na porcie HTTPS:

ss -ltnp

Polecenie uruchom na maszynie terminatora albo w jego przestrzeni sieciowej. Opcje wybierają gniazda nasłuchujące TCP, numeryczny zapis adresów i informacje o procesie, o ile twój użytkownik ma do nich dostęp - opisuje je strona podręcznika ss(8). Port z wyniku porównaj z PORT_HTTPS użytym w teście OpenSSL: jeśli na tym porcie siedzi proces, który nie mówi TLS-em, właśnie znalazłeś swoją drugą przegródkę.

Potem zestaw godzinę próby z logiem terminatora TLS. Nazwa i miejsce logu zależą od wdrożenia, więc nie szukaj jednego uniwersalnego pliku - szukaj wpisu z momentu swojej próby. Sprawdź też mapowanie nazwy SNI: czy HOST trafia we właściwą konfigurację i właściwy certyfikat.

Dwie rzeczy, które oszczędzą ci wstydu i ryzyka. Jeśli TLS kończy edge albo reverse proxy, log originu nie zastąpi logu terminatora - patrzysz wtedy na rozmowę, która nigdy nie widziała klienta. I nie wklejaj do notatki diagnostycznej pełnej konfiguracji serwera, CDN ani materiału certyfikatu.

Jak potwierdzić naprawę?

Naprawę potwierdza powtórzenie dokładnie tej próby, która zawodziła. Uruchom identyczne polecenie OpenSSL z tej samej maszyny, z tym samym HOST i PORT_HTTPS. Potem ponów żądanie w przeglądarce, która zgłaszała błąd, i odszukaj tę nową próbę w logu terminatora.

Kryterium jest wąskie i konkretne: badany klient zestawia chronione połączenie, a test OpenSSL kończy walidację tej samej nazwy bez błędu. Taki wynik zamyka incydent dla tego hosta - o innych hostach, klientach i sieciach nadal nie mówi nic.

Pytania o ERR_SSL_PROTOCOL_ERROR

Co oznacza ERR_SSL_PROTOCOL_ERROR w Chrome?

To komunikat Chromium o błędzie protokołu SSL/TLS podczas zestawiania bezpiecznego połączenia - definiuje go plik net/base/net_error_list.h w źródłach projektu. Sam komunikat nie wskazuje winnego urządzenia ani ustawienia. Zasięg ustalasz porównaniem klientów i sieci, a serwer sprawdzasz testem OpenSSL z nazwą SNI i weryfikacją hosta.

Jak sprawdzić, czy ERR_SSL_PROTOCOL_ERROR jest po stronie serwera?

Porównaj ten sam adres na drugim urządzeniu w tej samej sieci i na urządzeniu w innej sieci. Potem uruchom test OpenSSL z maszyny poza badaną infrastrukturą. Jeśli wynik wskazuje błąd endpointu dla tej nazwy, zestaw godzinę próby z logiem warstwy kończącej TLS.

Dlaczego błąd występuje tylko na jednym urządzeniu?

Jeśli drugie urządzenie w tej samej sieci łączy się z tym samym hostem, różnica siedzi na ścieżce tego jednego klienta. To jeszcze nie wskazuje konkretnego ustawienia. Wykonaj identyczne polecenie OpenSSL na urządzeniu zgłaszającym błąd i porównaj wynik z testem zewnętrznym - rozbieżność zawęzi podejrzenia.

Czy ERR_SSL_PROTOCOL_ERROR oznacza uszkodzony certyfikat?

Nie przesądzaj tego z samego komunikatu. Chromium raportuje błąd protokołu, a certyfikat jest tylko jedną z warstw do sprawdzenia. Polecenie OpenSSL z -verify_hostname i -verify_return_error oddziela błąd walidacji certyfikatu od pozostałych wyników - i dopiero taki wynik uprawnia do wniosku o certyfikacie.

Jak sprawdzić ERR_SSL_PROTOCOL_ERROR poleceniem OpenSSL?

Z maszyny odtwarzającej drogę użytkownika uruchom openssl s_client z adresem HOST:PORT_HTTPS, opcją -servername HOST, weryfikacją -verify_hostname HOST, przerwaniem -verify_return_error i podsumowaniem -brief. Podstaw nazwę i port swojego wdrożenia. Wynik odnosi się tylko do tej ścieżki i tej próby.

Czy można bezpiecznie ominąć ERR_SSL_PROTOCOL_ERROR?

Nie omijaj walidacji i nie wyłączaj ochrony na stałe - obejście ukrywa objaw, a problem zostaje. Wskaż terminator TLS, sprawdź endpoint z właściwą nazwą SNI i zbierz log tej samej próby. Diagnozę kończy poprawne połączenie klienta i walidacja badanego hosta bez błędu.

Pozostałe przypadki zbierają runbooki błędów połączenia z serwerem.

Granica odpowiedzi i źródła

Ta strona diagnozuje jeden konkretny komunikat przeglądarki i doprowadza cię do warstwy, w której połączenie nie powstało. Mechanizm certyfikatu i negocjacji opisuje strona o certyfikatach i TLS, a pełną pracę z poleceniem przejmuje strona o openssl s_client. Instalację certyfikatu i porady dla konkretnych wersji przeglądarek czy systemów opisujemy w osobnych tekstach.

Twierdzenia techniczne w tym tekście pochodzą ze źródeł pierwotnych - z pliku net/base/net_error_list.h w źródłach Chromium, rejestru IANA Service Name and Transport Protocol Port Number Registry, RFC 6066 (sekcja 3) i RFC 9525, dokumentacji OpenSSL dla openssl-s_client i opcji weryfikacji, strony podręcznika ss(8) oraz dokumentacji nginx modułu ngx_http_ssl_module.