Skomplikowany problem z ERR_SSL_PROTOCOL_ERROR

[Sevence]

Cześć,

 

Zwracam się do was z prośbą w związku z tym problemem. Szukam rozwiązania od dłuższego czasu i nie mam pojęcia co mogę więcej zrobić. 

 

Niewielki procent użytkowników zawsze to są użytkownicy IOS doświadczają problemu ERR_SSL_PROTOCOL_ERROR. Co ciekawe, dzieje się to głównie na sieciach mobilnych 5G/LTE. Na WIFI na tym samym urządzeniu wszystko działa poprawnie. Po kilku krotnym odświeżeniu strony w końcu za którymś udaje im się połączyć. I teraz tak strona jest oczywiście za Cloudflare certyfikat wygenerowany właśnie w nim jest również na serwerze. 

 

Na serwerze używam openlitespeed o takiej konfiguracji to jest httpd_config.conf

listener Https {
	address						*:443
	binding						1023
	secure						1
	reusePort                   1
	keyFile						/etc/ssl/CF/key.pem
	certFile					/etc/ssl/CF/cert.pem
	certChain					1
	enableQuic					0
	enableStapling				1
	ocspRespMaxAge				86400

	
	map							sharegon.pl sharegon.pl
}

 

Dodatkowo w vhost

vhssl {
	keyFile						/etc/ssl/CF/key.pem
	certFile					/etc/ssl/CF/cert.pem
	certChain					1
	enableSpdy					1
	sslProtocol					24
    sslSessionCache             1
    sslSessionTickets           1	
	enableStapling				1
	ocspRespMaxAge				86400
}

 

W Cloudflare mam ustawiony FULL STRICT

Always Use HTTPS - jest włączone

HTTP Strict Transport Security (HSTS) - wyłączyłem

Minimum TLS Version - TLS 1.2 (próbowałem również 1.0) 

Opportunistic Encryption - wyłączyłem (myślałem że może to powoduje problem niestety nie)

TLS 1.3 - włączone

Automatic HTTPS Rewrites  - włączone

 

QUIC - wyłączony na serwerze i również w CF

 

Tu jak wygląda problem, za którymś razem w końcu uda się połączyć.

 

 

 

Jakby ktoś miał jakikolwiek pomysł co mogę zrobić aby rozwiązać ten problem przyjmę każdą wskazówkę. Dodam, że ci sami użytkownicy twierdzą że problem dotyczy tylko mojej strony na inne wchodzą bez tego typu problemów. 

Edytowane 7 Grudnia 2025 przez Sevence

[Sevence]

Ustawiłem DEBUG w ols na 5 i wyrzuciło mi istotny błąd mam wrażenie:

2025-12-09 23:13:57.695944 [DEBUG] [2002988] [104.23.170.190:10042-1#sharegon.pl] writeStaticFileBlock, leave early, count: 10
2025-12-09 23:13:57.695947 [DEBUG] [2002988] [104.23.170.190:10042-1#sharegon.pl] flushBody() return 1
2025-12-09 23:13:57.695950 [DEBUG] [2002988] [104.23.170.190:10042] NtwkIOLink::flushSslWpending()...
2025-12-09 23:13:57.695952 [DEBUG] [2002988] [104.23.170.190:10042] SSL wpending: 32812
2025-12-09 23:13:57.695954 [DEBUG] [2002988] [104.23.170.190:10042] [SSL: 0x1738e588] flush
2025-12-09 23:13:57.695959 [DEBUG] [2002988] [104.23.170.190:10042] [SSL] more to flush, continue write.
2025-12-09 23:13:57.696020 [DEBUG] [2002994] [104.23.170.190:10050-1#sharegon.pl] getStaticFileBlock using pread(16384)-> 16384
2025-12-09 23:13:57.696023 [DEBUG] [2002994] [104.23.170.190:10050-1#sharegon.pl] sendStaticFileEx writeStaticFileBlock 16384
2025-12-09 23:13:57.696036 [DEBUG] [2002994] SSL_write( 0x173924d8, 0x7ffc8c2a9db0, 16384) return -1, pending 65624
2025-12-09 23:13:57.696041 [DEBUG] [2002994] SslError:error:00000003:invalid library (0):OPENSSL_internal:bignum routines
2025-12-09 23:13:57.696046 [DEBUG] [2002994] [104.23.170.190:10050] [SSL: 0x1738b528] checkError returned 3, first error: error:00000000:invalid library (0):OPENSSL_internal:invalid library (0), last error: error:00000000:invalid library (0):OPENSSL_internal:invalid library (0)
2025-12-09 23:13:57.696049 [DEBUG] [2002994] [104.23.170.190:10050-1#sharegon.pl] writeRespBodyDirect() tried 16384 return 0.
2025-12-09 23:13:57.696051 [DEBUG] [2002994] [104.23.170.190:10050-1#sharegon.pl] writeStaticFileBlock ret: 0
2025-12-09 23:13:57.696065 [DEBUG] [2002994] [104.23.170.190:10050] NtwkIOLink::continueWrite()...
2025-12-09 23:13:57.696067 [DEBUG] [2002994] [104.23.170.190:10050] Throttled!
2025-12-09 23:13:57.696069 [DEBUG] [2002994] [104.23.170.190:10050] write resumed!

 

Czy ktoś się spotkał z czymś podobnym? Wygląda na to że jest spora szansa że to ten błąd powoduje te problemy. Jak go rozwiązać?

[Hostline.pl]

vhssl {
    keyFile                 /etc/ssl/CF/key.pem
    certFile                /etc/ssl/CF/cert.pem
    certChain               1
    enableSpdy              0
    sslProtocol             30
    sslSessionCache         2
    sslSessionTickets       0
    enableStapling          1
    ocspRespMaxAge          86400
}

 

[Sevence]

3 minuty temu, Hostline.pl napisał(a):

vhssl {
    keyFile                 /etc/ssl/CF/key.pem
    certFile                /etc/ssl/CF/cert.pem
    certChain               1
    enableSpdy              0
    sslProtocol             30
    sslSessionCache         2
    sslSessionTickets       0
    enableStapling          1
    ocspRespMaxAge          86400
}

 

Dzięki, spróbuję tej konfiguracji, ale jestem już zirytowany bo próbowałem wiele ustawień i bez rezultatów. 

[Sevence]

Niestety, problem nadal istnieje a powyższe rozwiązanie nie pomogło. Mam wrażenie, że kluczowe będzie rozwiązanie tego błędu z logów, ale nie spotykałem się z nim wcześniej, nie bardzo wiem dlaczego on występuje. Dodam że ols był instalowany z paczek apt. 

Edytowane 10 Grudnia 2025 przez Sevence

[oui]

Skoro korzystasz z proxy CloudFlare to oni terminują SSLa więc chyba to im powinieneś zgłosić albo sprawdzić u nich logi? Chyba że failują SSL jak ich serwer proxy ma problem z SSLem na twoim serwerem. A próbowałeś wyłączyć proxy ssla, podpiąć SSL od LE i odpalenie np. SSL Laba?

[l3szcz]

@psz

Czy jest możliwe, że to błąd po stronie Cloudflare? 

Edytowane 10 Grudnia 2025 przez l3szcz

[Sevence]

20 minut temu, oui napisał(a):

Skoro korzystasz z proxy CloudFlare to oni terminują SSLa więc chyba to im powinieneś zgłosić albo sprawdzić u nich logi? Chyba że failują SSL jak ich serwer proxy ma problem z SSLem na twoim serwerem. A próbowałeś wyłączyć proxy ssla, podpiąć SSL od LE i odpalenie np. SSL Laba?

Problem jest taki, że ci sami użytkownicy wchodzą na inne strony, które również używając CloudFlare i nie doświadczają żadnych problemów tylko u mnie. Za którymś razem uda się połączyć. Dodatkowo dotyczy to głównie sieci 5G/LTE na WiFi działa poprawnie. To głównie użytkownicy IOS. Używamy Debiana 13, czy to on może powodować problemy? W logach występuje tylko ten problem, który wysłałem powyżej. 

Edytowane 10 Grudnia 2025 przez Sevence

[Sevence]

Z tego co obserwuję to właśnie jeden z użytkowników sprawdzał jeszcze raz i właśnie zauważam że w minucie której testuje powiela się ten błąd (próbuje odświeżyć kilka razy) jestem prawie pewien że to jest przyczyna tylko nie mam pojęcia z czego to wynika. 

[Sevence]

Wybaczcie za spam, ale nie mogę edytować postu wyżej. Wszyscy którzy zgłaszają problemy używają IOS 18.6.2 

[oui]

Możesz sprawdzić z jaką wersją ssla ols został skompilowany a z jakiej korzysta w runtime. Ten pierwszy bład wskazuje na coś dziwnego z bignum 

 

openlitespeed -v

ldd /path/to/openlitespeed | grep ssl

ldconfig -p | grep libssl
openssl version

Albo wgl ręcznie skompilować od zera i tak przetestować

[Sevence]

@oui

```root@web:/usr/local/lsws/bin# ldd /usr/local/lsws/bin/openlitespeed | grep ssl

root@web:/usr/local/lsws/bin# ./openlitespeed -v

LiteSpeed/1.8.4 Open (BUILD built: Tue Nov 4 13:44:54 UTC 2025)

        module versions:

        lsquic 4.3.1

        modgzip 1.1

        cache 1.66

        mod_security 1.4 (with libmodsecurity v3.0.14)

 

root@web:/usr/local/lsws/bin# ldconfig -p | grep libssl

        libssl.so.3 (libc6,x86-64) => /lib/x86_64-linux-gnu/libssl.so.3

        libssl.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libssl.so

root@web:/usr/local/lsws/bin# openssl version

OpenSSL 3.5.4 30 Sep 2025 (Library: OpenSSL 3.5.4 30 Sep 2025)```

Edytowane 10 Grudnia 2025 przez Sevence

[psz]

7 godzin temu, l3szcz napisał(a):

@psz

Czy jest możliwe, że to błąd po stronie Cloudflare? 

 

Z logów wynika, jakby klient próbował się połączyć do portu 9358. Czy rozumuję poprawnie? To nie jest standardowy port obsługiwany przez CDN (można taki ustawić, gdy się użyje usługi Cloudflare Spectrum, lecz pokazany adres IP nie pasuje do używanego bloku adresów). Dodatkowo wydaje się, jakby OpenSSL starało się załadować jakąś dodatkową bibliotekę.

 

Nie wydaje się, żeby to był problem bezpośrednio z Cloudflare. Problem na 5G/LTE wskazuje, że mógłby to być jakiś problem z CGNAT u operatora komórkowego (jeśli wszyscy z tym problemem są u jednego operatora).

[Sevence]

Tak użytkownicy zgłaszający problem używają T-Mobile. 

[l3szcz]

@psz

Z tego co już wiem problem dzieje się wtedy gdy klienci iPhone wbijają na stronę (normalnie po porcie 443), po kilku "odświeżeniach" Chatboxa wyskakuje problem z SSL. Tylko iPhone ma ten kłopot. 

[Sevence]

8 minut temu, l3szcz napisał(a):

@psz

Z tego co już wiem problem dzieje się wtedy gdy klienci iPhone wbijają na stronę (normalnie po porcie 443), po kilku "odświeżeniach" Chatboxa wyskakuje problem z SSL. Tylko iPhone ma ten kłopot. 

Dokładnie tak tylko wcześniej następuje zakończenie sesji z czatem. Użytkownik wchodzi na forum na zakładkę czat, minimalizuje przeglądarkę rozłącza go z czatem widzi przycisk wznów połączenie i w tym momencie gdy odświeży stronę lub przejdzie na główną wywala ten błąd. Po kilkukrotnej próbie odświeżenia w końcu zaskoczy. Dotyczy to głównie IOS wersja 18.x

Edytowane 10 Grudnia 2025 przez Sevence

[darekm]

2 godziny temu, Sevence napisał(a):

Tak użytkownicy zgłaszający problem używają T-Mobile. 

niestety t-mobile  to standast z problemami z ssl

[psz]

ERR_SSL_PROTOCOL_ERROR najprawdopodobniej znaczy, że klient i serwer nie wynegocjowali połączenia TLS. Ciągle kręcimy się w okolicach iOS. Może T-Mobile'owy CGNAT coś psuje w sposób, który iOS nie toleruje, albo to jakiś świeży bug ze strony Apple.

 

Można spróbować wywnioskować jakąś kohortę klientów z Network Error Logging albo Report URI, choć pewnie nie będzie zbyt wielu szczegółowych informacji w tych raportach.

 

Można także spróbować:

- zmienić minimalną wersję TLS na 1.2 albo nawet 1.3 (wiem, że odetnie to starsze klienty, ale współczesne przeglądarki powinny być ok)

- zmienić maksymalną wersję TLS na 1.2 (może CGNAT nie lubi 1.3)

- spróbować pomanipulować Cipher Suites i spróbować zidentyfikować algorytm, który jest problemem

- sprawdzić, czy iOS 26 także wykazuje podobny problem

- spróbować wyłączyć Encrypted Client Hello (docs), dostępne w planach płatnych (więc można spróbować kupić pro na jeden miesiąc)

- spróbować wyłączyć HTTP/3 (który działa po porcie UDP 443, zamiast TCP 443), choć podejrzewam, że raczej to ustawienie nie jest problemem

Edytowane 10 Grudnia 2025 przez psz

[ćwierćadmin]

2 godziny temu, darekm napisał(a):

niestety t-mobile  to standast z problemami z ssl

 

najlepsze jest jak dostaję screena gdzie zamiast właściwego certyfikatu dla danej domeny, który jest zainstalowany i normalnie działa użytkownik dostaje jakiś certyfikat dla t-mobile

[Sevence]

W dniu 10.12.2025 o 22:38, ćwierćadmin napisał(a):

 

najlepsze jest jak dostaję screena gdzie zamiast właściwego certyfikatu dla danej domeny, który jest zainstalowany i normalnie działa użytkownik dostaje jakiś certyfikat dla t-mobile

Właśnie dostałem potwierdzenie użytkownik ma podmieniony certyfikat na ich który zgłasza że witryna jest niebezpieczna, ale po ktoryms razem uda się połączyć. Jak mogę coś zaradzić w tej sprawie? Czy może być tak że moja domena/serwer jest na jakiejś Black liście? Czy mogę jakoś zgłosić to do nich? Dlaczego tylko do mojej domeny jest ten problem. 

Edytowane 18 Grudnia 2025 przez Sevence

[psz]

Przeglądarki typowo pozwalają obejrzeć szczegóły takich certyfikatów. Polecam spytać użytkownika o screenshot szczegółów napotkanego certyfikatu (instrukcje są różne w zależności od przeglądarki, ale najczęściej należy kliknąć ikonę w pasku adresowym).

 

"Podmieniony certyfikat" raczej na pewno wskazuje na Atak man in the middle. Ta technika jest używana zarówno w złych, jak i dobrych celach. 

 

Firmy stosują oprogramowanie skanujące ruch szyfrowany w sieciach korporacyjnych lub na komputerach pracowników (w połączeniu z prywatnym certyfikatem root CA), w celu skanowania ruchu na obecność malware lub wycieku poufnych informacji.

 

Sieci korporacyjne, a nawet operatorzy Internetu mogą używać tego do blokowania połączeń do stron, np. w Polsce operatorzy mają obowiązek blokować strony z listy domen służących do nielegalnego hazardu, prowadzoną przez Ministerstwo Finansów, albo chcą zablokować strony nieodpowiednie dla dzieci (często wtedy używają baz, które przydzielają domeny do kategorii). W tym przypadku często używa się po prostu fałszywego certyfikatu, żeby przeglądarka odrzuciła takie połączenie (i dobrze, bo tak właśnie ma działać mechanizm HTTPS). Czasami, jeśli się pozwoli przeglądarce zignorować błąd, może nastąpić przekierowanie na stronę informującą o blokadzie (a może nawet przyczynie).

36 minut temu, Sevence napisał(a):

Czy może być tak że moja domena/serwer jest na jakiejś Black liście? Czy mogę jakoś zgłosić to do nich?

 

Sprawdź szczegóły zaprezentowanego certyfikatu. Może uda się ustalić producenta firewalla/MITM. Takie firmy często dostarczają bazę z kategoriami domen, do której można zgłaszać poprawki.

[Sevence]

Dostałem takie screeny. 

 

[psz]

Certyfikat powyżej jest jak najbardziej poprawny i zaufany (tzn. wystawiony przez zaufany urząd certyfikacji), ale dla...  t-mobile.pl

 

Wygląda na to, że coś popsuli u siebie w CGNAT/firewallu. Polecam kontakt z nimi i zgłoszenie problemu (wiem, że szanse, że support zrozumie problem, są nikłe). Możesz też spróbować email do NOC ([email protected], adres znaleziony we whois).

[Sevence]

Spróbuję się z nimi skontaktować, ale domyślam się jaka będzie odpowiedź. Zastanawia mnie tylko fakt że problem mają tylko u mnie. 

[darekm]

Godzinę temu, Sevence napisał(a):

Spróbuję się z nimi skontaktować, ale domyślam się jaka będzie odpowiedź. Zastanawia mnie tylko fakt że problem mają tylko u mnie. 

idzie sie dogadac  z nimi akurat  nie jestes pierwszy i zapewne nie ostatni