Jak naprawić błąd „Ta witryna nie może zapewnić bezpiecznego połączenia”

Błąd "This site can't provide a secure connection" oznacza, że przeglądarka nie mogła zakończyć uzgadniania TLS z docelowym serwerem. Próba połączenia została przerwana przed ustanowieniem jakiegokolwiek szyfrowanego kanału, przez co przeglądarka nie była w stanie zweryfikować tożsamości serwera ani wynegocjować zestawu szyfrów.

Ten błąd pojawia się w Chrome, Firefox, Edge i Safari i prawie zawsze towarzyszy mu określony kod błędu — najczęściej ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH lub SSL_ERROR_HANDSHAKE_FAILURE_ALERT. Każdy kod wskazuje na inną warstwę awarii: konfigurację certyfikatu serwera, stos TLS klienta lub ścieżkę sieciową między nimi. Zidentyfikowanie odpowiedzialnej warstwy przed zmianą jakichkolwiek ustawień pozwoli zaoszczędzić znaczną ilość czasu.

Co tak naprawdę dzieje się podczas uzgadniania TLS

Zanim przejdziemy do rozwiązań, warto zrozumieć mechanizm awarii. Gdy przeglądarka łączy się z witryną HTTPS, wykonuje uzgadnianie TLS w ciągu milisekund:

1. Przeglądarka wysyła wiadomość ClientHello, informując o obsługiwanych wersjach TLS i zestawach szyfrów.
2. Serwer odpowiada komunikatem ServerHello, wybierając wersję protokołu i szyfr, a następnie przedstawia łańcuch certyfikatów.
3. Przeglądarka weryfikuje certyfikat względem zaufanych głównych urzędów certyfikacji (CA), sprawdza datę wygaśnięcia, weryfikuje, czy domena pasuje do Subject Alternative Name (SAN), i potwierdza, że certyfikat nie został odwołany (przez OCSP lub CRL).
4. Obie strony wyprowadzają klucze sesji i rozpoczynają szyfrowaną komunikację.

Awaria na którymkolwiek z tych czterech etapów powoduje wyświetlenie komunikatu "can't provide a secure connection". Kod błędu w panelu szczegółów przeglądarki dokładnie wskazuje, który etap zawiódł.

Główne przyczyny powiązane z kodami błędów

Jeśli kod błędu wskazuje odpowiedzialność administratora serwera, a nie masz kontroli nad serwerem, Twoje możliwości ograniczają się do skontaktowania się z właścicielem witryny. Pozostałe sekcje skupiają się na błędach, które możesz rozwiązać po stronie klienta, a następnie na rozwiązaniach po stronie serwera dla administratorów.

Rozwiązania po stronie klienta

1. Sprawdź certyfikat przed wprowadzeniem jakichkolwiek zmian

Kliknij kłódkę (lub ikonę ostrzeżenia) na pasku adresu i wybierz Połączenie jest bezpieczne > Certyfikat jest ważny. Sprawdź:

• Okres ważności: Data "Not After" musi być w przyszłości.
• Wystawiony dla: Domena w polu SAN certyfikatu musi dokładnie pasować do URL, łącznie z subdomenami.
• Wystawiony przez: Łańcuch CA musi kończyć się na głównym CA, któremu ufa Twój system operacyjny.

Jeśli certyfikat wygasł lub nie pasuje, a nie jesteś właścicielem serwera, zatrzymaj się tutaj i skontaktuj się z właścicielem witryny. Jeśli zarządzasz serwerem, przejdź do sekcji po stronie serwera poniżej.

2. Zsynchronizuj datę i godzinę systemową

Walidacja certyfikatu jest wrażliwa na czas. Zegar systemowy, który jest nawet kilka minut spóźniony, może spowodować, że przeglądarka uzna ważny certyfikat za wygasły lub że certyfikat jeszcze nieważny jest używany przedwcześnie.

Windows:

w32tm /resync /force

Alternatywnie kliknij prawym przyciskiem myszy zegar systemowy, wybierz Dostosuj datę/godzinę i włącz Ustaw czas automatycznie za pomocą usługi Windows Time.

Linux (systemd):

timedatectl set-ntp true
timedatectl status

macOS: Otwórz Ustawienia systemowe > Ogólne > Data i godzina i włącz Ustaw datę i godzinę automatycznie.

Po synchronizacji uruchom ponownie przeglądarkę i przetestuj ponownie.

3. Wyczyść stan SSL i pamięć podręczną przeglądarki

Przeglądarki buforują wyniki walidacji certyfikatów i zasady HSTS (HTTP Strict Transport Security). Nieaktualna pozycja w pamięci podręcznej może blokować dostęp nawet po rozwiązaniu problemu z certyfikatem po stronie serwera.

Chrome — wyczyść dane przeglądania:

Przejdź do chrome://settings/clearBrowserData, wybierz Cały czas, zaznacz Pliki cookie i inne dane witryn oraz Obrazy i pliki w pamięci podręcznej, a następnie kliknij Wyczyść dane.

Chrome — wyczyść wpis HSTS dla konkretnej domeny:

Przejdź do chrome://net-internals/#hsts, wpisz domenę w polu Usuń zasady bezpieczeństwa domeny i kliknij Usuń. Jest to szczególnie przydatne, gdy domena była wcześniej tylko HTTPS, a teraz jest błędnie skonfigurowana.

Windows — wyczyść stan SSL na poziomie systemu operacyjnego:

Control Panel > Network and Internet > Internet Options > Content tab > Clear SSL State

Czyści to pamięć podręczną certyfikatów używaną przez Internet Explorer, Edge (starszy) i niektóre aplikacje Windows.

Firefox: Przejdź do about:preferences#privacy, przewiń do Pliki cookie i dane witryn i kliknij Wyczyść dane.

4. Wyłącz inspekcję HTTPS przez program antywirusowy

Produkty zabezpieczające od dostawców takich jak Avast, AVG, Kaspersky, ESET i Bitdefender wykonują przechwytywanie SSL/TLS — działają jako lokalny serwer proxy man-in-the-middle, ponownie podpisując certyfikaty własnym głównym CA. Gdy ich główny CA nie jest prawidłowo zainstalowany w magazynie zaufania przeglądarki lub gdy moduł przechwytywania jest wadliwy, każde połączenie HTTPS kończy się niepowodzeniem.

Aby sprawdzić, czy to jest przyczyną:

1. Tymczasowo wyłącz funkcję Web Shield, Skanowanie HTTPS lub Filtrowanie SSL w ustawieniach programu antywirusowego.
2. Przeładuj niedziałającą stronę.
3. Jeśli błąd zniknie, program antywirusowy jest winowajcą.

Trwałym rozwiązaniem jest dodanie dotkniętej domeny do listy wykluczeń programu antywirusowego, zamiast globalnego wyłączania skanowania HTTPS, co obniżyłoby poziom bezpieczeństwa.

5. Zaktualizuj przeglądarkę

Nowoczesny TLS wymaga obsługi przez przeglądarkę co najmniej TLS 1.2, a TLS 1.3 dla optymalnego bezpieczeństwa. Przeglądarki starsze niż mniej więcej Chrome 70, Firefox 63 lub Edge 79 mogą nie obsługiwać TLS 1.3 lub mieć znane błędy uzgadniania.

Chrome:

Przejdź do chrome://settings/help. Chrome automatycznie sprawdza aktualizacje i instaluje je po ponownym uruchomieniu.

Firefox:

Przejdź do about:support, a następnie Sprawdź aktualizacje w menu Pomoc.

Aktualizowanie przeglądarki zapewnia również aktualność wbudowanego magazynu głównych CA przeglądarki, co ma znaczenie w przypadku certyfikatów wydanych przez nowsze CA.

6. Sprawdź ustawienia protokołu TLS w przeglądarce

Chrome i Edge (oparte na Chromium):

Te przeglądarki nie udostępniają przełączników wersji TLS w interfejsie użytkownika od Chrome 84. TLS 1.0 i 1.1 są trwale wyłączone. Jeśli witryna wymaga TLS 1.0 lub 1.1, witryna musi zostać zaktualizowana — nie ma obejścia po stronie klienta i nie powinno go być.

Aby sprawdzić eksperymentalne flagi TLS, przejdź do chrome://flags i wyszukaj TLS. W większości kompilacji produkcyjnych nie pojawią się żadne flagi wymagające działania.

Firefox:

Przejdź do about:config i wyszukaj security.tls.version.min. Wartość powinna wynosić 3 (odpowiadające TLS 1.2). Ustawienie jej na 1 lub 2 w celu dostosowania do uszkodzonego serwera stanowi zagrożenie bezpieczeństwa i powinno być wykonywane wyłącznie w izolowanych środowiskach testowych.

Internet Explorer / starszy Edge:

Przejdź do Opcje internetowe > Zaawansowane > Zabezpieczenia i upewnij się, że zaznaczone są opcje Użyj TLS 1.2 i Użyj TLS 1.3. Odznacz Użyj SSL 3.0, Użyj TLS 1.0 i Użyj TLS 1.1.

7. Wyłącz lub sprawdź rozszerzenia przeglądarki

Rozszerzenia z dostępem do sieci — szczególnie VPN, blokery reklam, narzędzia do ochrony prywatności i przełączniki proxy — mogą przechwytywać lub modyfikować połączenia TLS. Aby wyizolować konflikt rozszerzeń:

Przejdź do chrome://extensions/ i wyłącz wszystkie rozszerzenia. Przeładuj niedziałającą stronę. Jeśli błąd zniknie, włączaj rozszerzenia jedno po drugim, przeładowując po każdym, aż do zidentyfikowania problematycznego rozszerzenia.

8. Zmień resolver DNS

DNS nie wpływa bezpośrednio na TLS, ale resolver DNS zwracający nieprawidłowe adresy IP (z powodu zatruwania, filtrowania lub ingerencji dostawcy usług internetowych) może kierować przeglądarkę do serwera, który przedstawia certyfikat dla niewłaściwej domeny, powodując błąd ERR_CERT_COMMON_NAME_INVALID.

Przełączenie na publiczny resolver eliminuje manipulację DNS na poziomie dostawcy usług internetowych:

Windows — zmiana DNS przez PowerShell:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")

Zastąp "Ethernet" rzeczywistą nazwą interfejsu (użyj Get-NetAdapter aby wyświetlić listę interfejsów).

Linux:

sudo nano /etc/resolv.conf

Dodaj:

nameserver 1.1.1.1
nameserver 8.8.8.8

Zalecane publiczne resolvery:

9. Zresetuj stos sieciowy (Windows)

Uszkodzony katalog Winsock lub stos TCP/IP może powodować sporadyczne awarie TLS, które wydają się niezwiązane z certyfikatami. Uruchom następujące polecenia jako Administrator:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Uruchom ponownie komputer po wykonaniu wszystkich pięciu poleceń. Nie pomijaj ponownego uruchomienia — netsh winsock reset w szczególności wymaga restartu, aby zmiany weszły w życie.

Rozwiązania po stronie serwera dla administratorów

Jeśli zarządzasz serwerem WWW prezentującym certyfikat, poniżej przedstawiono najczęstsze przyczyny po stronie serwera i sposoby ich usunięcia.

Wygasły lub błędnie skonfigurowany certyfikat SSL

Wygasły certyfikat jest najczęstszą przyczyną tego błędu na poziomie serwera. Jeśli prowadzisz witrynę w środowisku VPS Hosting, odnowienie certyfikatu powinno być zautomatyzowane.

Sprawdź wygaśnięcie certyfikatu z wiersza poleceń:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Automatyzacja odnowienia za pomocą Certbot (Let's Encrypt):

sudo certbot renew --dry-run

Dodaj zadanie cron lub timer systemd, aby uruchamiać certbot renew dwa razy dziennie — certyfikaty Let's Encrypt wygasają co 90 dni, a Certbot odnawia je tylko wtedy, gdy pozostało mniej niż 30 dni.

0 0,12 * * * root certbot renew --quiet

Jeśli potrzebujesz certyfikatu z walidacją komercyjną z rozszerzoną walidacją lub pokryciem wildcard, Certyfikaty SSL od zaufanego CA zapewniają łańcuch zaufania wymagany przez wszystkie główne przeglądarki.

Niekompletny łańcuch certyfikatów

Bardzo częsta błędna konfiguracja: serwer przedstawia tylko certyfikat końcowy bez certyfikatów pośredniego CA. Przeglądarka nie może zbudować ścieżki zaufania do głównego CA, który rozpoznaje, co skutkuje błędem ERR_CERT_AUTHORITY_INVALID.

Diagnoza za pomocą SSL Labs:

Uruchom swoją domenę przez SSL Labs Server Test (zewnętrzne narzędzie). Problem z łańcuchem zostanie natychmiast oznaczony.

Naprawa w Nginx:

Dyrektywa ssl_certificate musi wskazywać na plik zawierający pełny łańcuch — Twój certyfikat, a następnie wszystkie certyfikaty pośrednie:

cat your_domain.crt intermediate.crt > fullchain.crt

ssl_certificate /etc/nginx/ssl/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;

Naprawa w Apache:

SSLCertificateFile /etc/apache2/ssl/your_domain.crt
SSLCertificateKeyFile /etc/apache2/ssl/your_domain.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt

Przestarzałe wersje TLS i słabe zestawy szyfrów

Przeglądarki usunęły obsługę TLS 1.0 i TLS 1.1. Jeśli Twój serwer oferuje tylko te wersje protokołu, nowoczesne przeglądarki całkowicie odmówią połączenia.

Zalecana konfiguracja TLS dla Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;

Zalecana konfiguracja TLS dla Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

Po zmodyfikowaniu konfiguracji serwera przetestuj za pomocą:

openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

Niezgodność domeny certyfikatu

Jeśli Twój certyfikat obejmuje www.example.com, ale użytkownicy uzyskują dostęp przez example.com (lub odwrotnie), przeglądarka zgłosi niezgodność domeny. Prawidłowym rozwiązaniem jest wydanie certyfikatu z obiema nazwami w polu SAN lub użycie certyfikatu wildcard (*.example.com).

Podczas konfigurowania nowej domeny w środowisku Serwery dedykowane, zawsze sprawdź, czy pole SAN obejmuje każdy wariant nazwy hosta, na który serwer będzie odpowiadał, przed uruchomieniem produkcyjnym.

Blokowanie zawartości mieszanej

Strona załadowana przez HTTPS, która odwołuje się do zasobów HTTP (obrazy, skrypty, arkusze stylów), wyzwala ostrzeżenia o zawartości mieszanej. Chociaż nie powoduje to bezpośrednio błędu "can't provide a secure connection", może powodować częściowe awarie strony, które są błędnie diagnozowane jako błędy TLS.

Sprawdź zawartość mieszaną za pomocą:

curl -s https://yourdomain.com | grep -Eo 'src="http://[^"]*"|href="http://[^"]*"'

Porównanie przyczyn po stronie klienta i serwera

Uwagi dotyczące środowiska hostingowego

Środowisko hostingowe, w którym działasz, bezpośrednio wpływa na łatwość rozwiązywania problemów TLS po stronie serwera.

W przypadku Hostingu współdzielonego, zarządzanie certyfikatami odbywa się zazwyczaj przez panel sterowania. Większość nowoczesnych platform hostingu współdzielonego zawiera bezpłatną integrację z Let's Encrypt, ale masz ograniczoną kontrolę nad ogólnosystemowymi ustawieniami protokołu TLS.

Na VPS z cPanel uzyskujesz dostęp do AutoSSL do automatycznego udostępniania certyfikatów i możesz bezpośrednio konfigurować ustawienia TLS Apache lub Nginx. Jest to zalecane środowisko dla witryn, w których precyzja konfiguracji TLS ma znaczenie.

Na serwerach bare-metal Serwery dedykowane masz pełną kontrolę nad całym stosem TLS — wersją OpenSSL, wyborem zestawu szyfrów, zszywaniem OCSP, wstępnym ładowaniem HSTS i przypinaniem certyfikatów — ale jesteś również w pełni odpowiedzialny za utrzymanie aktualności konfiguracji.

Praktyczna lista kontrolna decyzji

Użyj tej listy kontrolnej, aby systematycznie diagnozować błąd, zamiast losowo stosować poprawki:

• Czy błąd pojawia się na wszystkich witrynach HTTPS, czy tylko na jednej?
• Wszystkie witryny: skup się na zegarze systemowym, skanowaniu HTTPS przez program antywirusowy, aktualizacji przeglądarki, magazynie głównych CA systemu operacyjnego.
• Jedna witryna: problem jest prawie na pewno po stronie serwera.

• Co mówi konkretny kod błędu?
• ERR_CERT_DATE_INVALID: najpierw sprawdź zegar systemowy, a następnie wygaśnięcie certyfikatu.
• ERR_CERT_AUTHORITY_INVALID: sprawdź kompletność łańcucha certyfikatów.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH: serwer używa przestarzałego TLS lub nieobsługiwanych szyfrów.
• ERR_CERT_COMMON_NAME_INVALID: SAN certyfikatu nie pasuje do domeny.

• Czy błąd znika w innej sieci?
• Tak: przyczyną jest inspekcja TLS przez zaporę sieciową, proxy lub dostawcę usług internetowych.

• Czy błąd znika po wyłączeniu programu antywirusowego?
• Tak: skonfiguruj wykluczenie dla domeny w ustawieniach skanowania HTTPS programu antywirusowego.

• Czy jesteś administratorem serwera?
• Uruchom diagnostykę openssl s_client i test SSL Labs przed dotknięciem jakiegokolwiek pliku konfiguracyjnego.
• Zautomatyzuj odnowienie certyfikatu natychmiast po rozwiązaniu bieżącego problemu.

FAQ

Dlaczego błąd "This site can't provide a secure connection" pojawia się tylko na jednej witrynie?

Gdy błąd jest izolowany do jednej domeny, główna przyczyna jest prawie zawsze po stronie serwera: wygasły certyfikat, niekompletny łańcuch certyfikatów, niezgodność nazwy domeny w polu SAN certyfikatu lub serwer skonfigurowany do używania tylko przestarzałych wersji TLS (1.0 lub 1.1), których nowoczesne przeglądarki już nie akceptują.

Czy VPN może powodować ten błąd?

Tak. Niektórzy klienci VPN kierują zapytania DNS przez własne resolvery lub wykonują inspekcję ruchu, która zakłóca uzgadnianie TLS. Jeśli błąd pojawia się tylko wtedy, gdy VPN jest aktywny, wyłącz funkcję "split tunneling" lub "inspekcja SSL" VPN lub dodaj dotkniętą domenę jako wykluczenie.

Czy wyczyszczenie pamięci podręcznej zawsze naprawia błędy SSL?

Nie. Wyczyszczenie pamięci podręcznej rozwiązuje błędy spowodowane nieaktualnymi zasadami HSTS lub buforowanymi nieprawidłowymi odpowiedziami certyfikatów. Nie ma żadnego wpływu na problemy z certyfikatami po stronie serwera, problemy z zegarem systemowym ani przechwytywanie przez program antywirusowy. Używaj czyszczenia pamięci podręcznej jako pierwszego kroku, a nie uniwersalnego rozwiązania.

Jak sprawdzić, czy certyfikat SSL serwera jest prawidłowo skonfigurowany bez przeglądarki?

Użyj OpenSSL z dowolnej maszyny z dostępem do sieci:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Dane wyjściowe pokazują pełny łańcuch certyfikatów, wynegocjowaną wersję TLS, wybrany zestaw szyfrów i wszelkie błędy weryfikacji. Jest to najbardziej niezawodna metoda diagnostyczna dla problemów TLS po stronie serwera.

Jaka jest różnica między ERR_SSL_PROTOCOL_ERROR a ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_PROTOCOL_ERROR wskazuje, że serwer wysłał odpowiedź, która nie jest zgodna z żadnym rozpoznanym formatem rekordu TLS — często spowodowane przez serwer wysyłający odpowiedź HTTP na porcie 443, błędnie skonfigurowany load balancer lub zaporę sieciową przerywającą połączenie w trakcie uzgadniania. ERR_SSL_VERSION_OR_CIPHER_MISMATCH oznacza, że uzgadnianie rozpoczęło się prawidłowo, ale klient i serwer nie mogli uzgodnić wzajemnie obsługiwanej wersji TLS lub zestawu szyfrów, zazwyczaj dlatego, że serwer obsługuje tylko przestarzałe protokoły.