Błąd ERR_SSL_VERSION_OR_CIPHER_MISMATCH pojawia się, gdy przeglądarka internetowa i serwer nie potrafią ustalić wspólnego protokołu szyfrowania, najczęściej z powodu przestarzałej wersji TLS lub braku obsługi nowoczesnych zestawów szyfrów. Najskuteczniejszą metodą naprawy po stronie właściciela strony jest wymuszenie obsługi TLS 1.2 lub TLS 1.3 na serwerze oraz weryfikacja certyfikatu SSL pod kątem zgodności z algorytmami ECDHE. To jest bez mała najgorsza opcja z wszystkich błędów połączenia. Wybija użytkownika z sesji i blokuje dostęp do witryny na twardo.
Siedziałem nad tym we wtorek o 3 nad ranem. Zrobiliśmy na wdrożeniu aktualizację panelu klienta, potem zawiesiło się routowanie na starym load balancerze, więc wprowadzono poprawkę na szybko przed poniedziałkiem. Efekt? Właśnie ten komunikat wywalił na wszystkich maszynach z Windowsem 11 u klientów z zewnątrz. Zmieniliśmy te zasady na robocie, ucinając wsparcie dla zabytkowego ruchu. Przeglądarka po prostu mówi „nie ufasz mi, ja nie ufam tobie, zrywamy negocjacje”.
Dlaczego przeglądarka nagle wyrzuca błąd ERR_SSL_VERSION_OR_CIPHER_MISMATCH?
Proces nawiązywania bezpiecznego połączenia to tak zwany handshake SSL. Klient wysyła pakiet ClientHello. Mówi w nim wyraźnie, jakie wersje protokołów obsługuje i jakie zestawy szyfrów (cipher suites) preferuje. Serwer odpowiada komunikatem ServerHello. Wybiera jeden ze zgłoszonych szyfrów. Jeśli serwer ma w konfiguracji włączone wyłącznie stare protokoły typu SSLv3 lub TLS 1.0, a przeglądarka Chrome zaktualizowała w nocy politykę bezpieczeństwa i wymaga minimum TLS 1.2, negocjacje upadają. Maszyna zrywa połączenie. Otrzymujesz na ekranie szary ekran z kodem błędu.
Szczerze mówiąc, za każdym razem, gdy widzę ten komunikat na monitorze, przypomina mi się stary serwer w piwnicy urzędu na Mokotowie. Nikt nie miał do niego haseł root, a certyfikat wygasł chyba w 2018 roku. Próba wytłumaczenia dyrekcji, dlaczego pracownicy nie mogą wejść na pocztę, graniczyła z absurdem. Ludzie myślą, że kryptografia to czarna magia. A to po prostu zbiór cholernie sztywnych reguł matematycznych, które nie znoszą kompromisów. Albo masz zaktualizowany soft, albo system wykopuje cię za drzwi. Koniec kropka.
Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku wdrożeń. Administratorzy często zapominają o usunięciu algorytmu RC4 czy 3DES z pliku konfiguracyjnego. Chrome i Firefox traktują te szyfry jako złamane. Próba ich użycia natychmiast wyzwala ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
Czy to wina mojego komputera, czy serwera hostingowego?
W zdecydowanej większości przypadków winę ponosi serwer. Użytkownik domowy ma bardzo ograniczony wpływ na to, jak serwer www obsługuje kryptografię. Zdarzają się jednak sytuacje graniczne u klienta końcowego.
- Używasz systemu Windows 7, który natywnie nie potrafi poprawnie obsłużyć nowoczesnych krzywych eliptycznych bez instalacji dodatkowych łatek z Windows Update. Zostajesz odcięty od połowy internetu.
- To tyle.
- Oprogramowanie antywirusowe z funkcją głębokiego skanowania ruchu HTTPS podmienia w locie certyfikat strony na swój własny.
- Zbyt stara wersja przeglądarki internetowej, która utknęła na silniku sprzed pięciu lat.
Zwróć uwagę na asymetrię problemu. Serwer konfiguruje jeden człowiek. Odbijają się od niego tysiące użytkowników. Prawda jest zresztą absolutnie taka, że najszybszym sposobem weryfikacji jest odpalenie strony przez narzędzie zewnętrzne. Wpisujesz adres w Qualys SSL Labs. Otrzymujesz wynik z literą. F oznacza katastrofę. B wymaga poprawy.
Jak naprawić ten problem z certyfikatem po stronie administratora strony?
Wymuszamy TLS 1.2 i TLS 1.3. Odrzucamy resztę. Nie ma tu miejsca na ŻADNE sentymenty dla starszych urządzeń. Protokół TLS 1.1 został oficjalnie zdeprecjonowany przez IETF w 2021 roku. Zostawienie go na serwerze wystawia infrastrukturę na ataki typu downgrade. Zaktualizuj bibliotekę OpenSSL na swoim serwerze linuksowym. Czasami system operacyjny ma w repozytoriach tak starą wersję OpenSSL, że ta fizycznie nie zna algorytmów z rodziny GCM. Wtedy żadna zmiana w pliku konfiguracyjnym serwera www nie pomoże.
Generowanie nowego certyfikatu SSL to drugi krok. Jeśli Twój obecny certyfikat opiera się na algorytmie podpisu SHA-1, przeglądarki odrzucą go ze wstrętem. Musisz wygenerować nowy klucz prywatny i poprosić urząd certyfikacji (Let’s Encrypt, Sectigo) o wystawienie certyfikatu opartego na SHA-256. Dobrym pomysłem jest od razu przejście na certyfikaty ECC (Elliptic Curve Cryptography). Są lżejsze. Szybsze w obliczeniach. Oferują wyższy poziom bezpieczeństwa przy krótszym kluczu.
Co dokładnie muszę zmienić w konfiguracji Nginx i Apache?
Otwierasz plik konfiguracyjny swojego wirtualnego hosta. Edytujesz go z palca. W przypadku Nginx szukasz dyrektyw odpowiedzialnych za SSL. Usuwasz stare protokoły. Zmieniasz te zasady na robocie, dopisując rygorystyczną listę szyfrów. Wymuszasz na serwerze preferowanie własnych ustawień, a nie ustawień klienta.
Dla Nginx konfiguracja wygląda mniej więcej tak. Wskazujesz `ssl_protocols TLSv1.2 TLSv1.3;`. Następnie definiujesz `ssl_ciphers`. Wrzucasz tam tylko mocne algorytmy. Na przykład `ECDHE-ECDSA-AES128-GCM-SHA256` czy `ECDHE-RSA-AES256-GCM-SHA384`. Dodajesz `ssl_prefer_server_ciphers on;`. Restartujesz usługę komendą systemctl. Sprawdzasz logi. Gra muzyka.
Dla Apache proces wygląda bliżej starszych standardów. Modyfikujesz plik ssl.conf. W dyrektywie `SSLProtocol` wpisujesz `all -SSLv3 -TLSv1 -TLSv1.1`. To oznacza akceptację wszystkiego z wyjątkiem wymienionych śmieci. Ustawiasz `SSLCipherSuite` w formacie akceptowanym przez OpenSSL. Zapisujesz plik i robisz reload usługi. Blisko dziewięćdziesiąt procent ruchu w polskim internecie przetwarza się dziś prawidłowo po zastosowaniu tych konkretnych dwóch poprawek.
Kiedy proxy z Cloudflare blokuje połączenie szyfrowane?
Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Masz podpiętą domenę pod Cloudflare. Ruch idzie przez ich serwery brzegowe. Użytkownik widzi zieloną kłódkę, ale nagle dostaje w twarz błędem ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Dlaczego?
Zjawisko to występuje, gdy certyfikat Universal SSL w panelu Cloudflare utknął w stanie weryfikacji. Zamówiłeś certyfikat, ale zapomniałeś dodać rekordów TXT do weryfikacji domeny. Cloudflare nie potrafi udowodnić, że kontroluje domenę. Certyfikat nie generuje się. Sieć brzegowa nie ma czym szyfrować ruchu do użytkownika. Wystarczy wejść w zakładkę SSL/TLS, kliknąć Edge Certificates i sprawdzić status. Jeśli widnieje tam „Pending Validation”, masz odpowiedź.
Drugi przypadek to błędne ustawienie trybu szyfrowania. Ustawiasz tryb „Full (Strict)”, ale na swoim serwerze docelowym posiadasz certyfikat samopodpisany (self-signed) albo wygasły. Cloudflare próbuje nawiązać bezpieczne połączenie z twoim backendem. Backend odrzuca połączenie lub przedstawia nieważny dokument. Węzeł brzegowy zrywa połączenie z użytkownikiem i wypluwa błąd. Zmień tryb na „Full” albo po prostu zainstaluj darmowy certyfikat Let’s Encrypt na serwerze źródłowym.
Jak zwykły użytkownik może obejść niezgodność wersji SSL?
Praktycznie nie może. I bardzo dobrze. To mechanizm obronny. Zmuszanie przeglądarki do zaakceptowania przestarzałego połączenia wystawia cię na kradzież ciasteczek sesyjnych lub atak Man-in-the-Middle w publicznej sieci Wi-Fi. Możesz jednak upewnić się, że problem faktycznie nie leży na twoim biurku.
Wyłącz na pięć minut oprogramowanie antywirusowe. ESET, Kaspersky czy Bitdefender instalują własne certyfikaty główne w systemie Windows, aby dekodować ruch HTTPS i skanować go w poszukiwaniu złośliwego kodu. Czasami ten mechanizm po prostu się wykrzacza. Antywirus blokuje handshake. Jeśli po wyłączeniu ochrony strona ładuje się normalnie, musisz wyczyścić bazę certyfikatów w antywirusie lub dodać domenę do wyjątków.
Czy czyszczenie cache przeglądarki cokolwiek tutaj daje?
Tak. Przeglądarki internetowe przechowują tak zwany SSL State. To pamięć podręczna zawierająca informacje o certyfikatach i wynegocjowanych szyfrach z poprzednich sesji, by przyspieszyć kolejne ładowania strony. Jeśli administrator serwera przed chwilą wymienił certyfikat na nowy, twoja przeglądarka może nadal próbować użyć starych parametrów z cache.
W systemie Windows wchodzisz w panel sterowania. Wybierasz Opcje internetowe. W zakładce Treść klikasz przycisk „Wyczyść stan SSL”. Zamykasz wszystkie okna Chrome. Uruchamiasz ponownie. Problem znika. Na systemach macOS i Linux zazwyczaj wystarczy twarde odświeżenie strony skrótem CTRL+F5 lub wyczyszczenie standardowej pamięci podręcznej przeglądarki.
Skąd mam wiedzieć, które zestawy szyfrów (cipher suites) są obecnie bezpieczne?
Trzymasz się wytycznych od Mozilli. Zespół bezpieczeństwa Mozilli prowadzi generator konfiguracji serwerów. Oferują trzy profile. Modern. Intermediate. Old. Profil Modern obsługuje wyłącznie TLS 1.3 i nie wymaga już konfiguracji skomplikowanych zestawów szyfrów, ponieważ standard TLS 1.3 drastycznie zredukował liczbę dostępnych opcji do zaledwie kilku, niezwykle bezpiecznych algorytmów. Profil Intermediate to kompromis do obsługi urządzeń mobilnych sprzed kilku lat.
A tak wygląda podział popularnych algorytmów na te dozwolone i te, które powinieneś natychmiast wyrzucić z serwera.
| Nazwa zestawu szyfrów | Status bezpieczeństwa | Protokół |
| TLS_AES_256_GCM_SHA384 | Bezpieczny | TLS 1.3 |
| TLS_CHACHA20_POLY1305_SHA256 | Bezpieczny | TLS 1.3 |
| ECDHE-RSA-AES128-GCM-SHA256 | Akceptowalny | TLS 1.2 |
| DHE-RSA-AES256-SHA | Słaby (Brak PFS) | TLS 1.2 |
| RC4-SHA | Złamany (Natychmiast usunąć) | SSLv3 / TLS 1.0 |
| DES-CBC3-SHA | Złamany (Natychmiast usunąć) | TLS 1.0 |
Wdrażasz zmiany i testujesz. Jeśli cokolwiek przestaje działać u ciebie w firmie, sprawdzasz logi dostępowe serwera. Szukasz komunikatów o błędach negocjacji. To żmudna robota, ale warta zachodu w kontekście audytów bezpieczeństwa.
Sprawdź teraz swoje logi serwera. Ile widzisz odrzuconych handshake’ów z dzisiejszego poranka?
Często zadawane pytania (FAQ)
- Co oznacza błąd ERR_SSL_VERSION_OR_CIPHER_MISMATCH?
Błąd ten oznacza, że przeglądarka internetowa i serwer nie mogą ustalić bezpiecznego połączenia, ponieważ brakuje im wspólnego protokołu szyfrowania (np. serwer wymusza stare SSLv3, a przeglądarka wymaga TLS 1.2). - Jak szybko naprawić ten błąd jako użytkownik?
Wyczyść stan SSL w systemie Windows (Opcje internetowe -> Treść -> Wyczyść stan SSL) lub tymczasowo wyłącz skanowanie ruchu HTTPS w oprogramowaniu antywirusowym. Zaktualizuj przeglądarkę do najnowszej wersji. - Jak naprawić ERR_SSL_VERSION_OR_CIPHER_MISMATCH na serwerze?
Administrator musi zaktualizować konfigurację serwera (Nginx, Apache), wyłączyć obsługę przestarzałych protokołów (TLS 1.0, TLS 1.1) i wymusić użycie bezpiecznych zestawów szyfrów oraz TLS 1.2 lub TLS 1.3. - Czy problem może powodować Cloudflare?
Tak. Problem występuje w Cloudflare, gdy certyfikat Universal SSL utknął w fazie weryfikacji domeny lub gdy ustawiono tryb Full (Strict) przy wygasłym certyfikacie na serwerze źródłowym. - Czy stary system operacyjny ma wpływ na ten błąd?
Tak. Przestarzałe systemy, takie jak Windows 7 bez zainstalowanych odpowiednich poprawek z Windows Update, nie obsługują nowoczesnych algorytmów kryptograficznych, co prowadzi do błędów połączenia. - Jak przetestować, czy mój serwer obsługuje poprawne szyfry?
Najlepiej skorzystać z darmowych narzędzi zewnętrznych, takich jak Qualys SSL Labs. Wpisz adres swojej witryny, a skaner wygeneruje pełny raport o obsługiwanych protokołach i podatnościach.
Bibliografia
1. Naukowa i Akademicka Sieć Komputerowa – https://nask.pl
2. Zespół Reagowania na Incydenty Bezpieczeństwa Komputerowego – https://cert.pl
3. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
4. Internet Engineering Task Force – https://ietf.org
5. OpenSSL Software Foundation – https://openssl.org
