Połączenie nie jest prywatne - jak naprawić błąd (Chrome, Edge, telefon)

Komunikat "Połączenie nie jest prywatne" znaczy, że przeglądarka nie zaufała certyfikatowi SSL strony. Najczęstsza przyczyna po Twojej stronie: zły zegar w urządzeniu albo publiczne Wi-Fi. Szybka naprawa: ustaw automatyczną datę i godzinę, zaloguj się do sieci, spróbuj w trybie incognito. Jeśli to Twoja witryna - certyfikat wygasł.

W skrócie: ten ekran to prawie zawsze problem konfiguracji, nie włamanie. Poniżej rozdzielam dwie sytuacje, bo mieszają się w jednym komunikacie. Pierwsza: chcesz tylko wejść na cudzą stronę i widzisz ostrzeżenie. Druga: to Twoja witryna pokazuje błąd i musisz naprawić certyfikat na serwerze. Ścieżki są zupełnie inne, więc idź od razu do swojej.

Co znaczy "Połączenie nie jest prywatne"

Kiedy wchodzisz na stronę po HTTPS, przeglądarka robi dwie rzeczy naraz: szyfruje ruch (żeby nikt po drodze nie podsłuchał) i sprawdza certyfikat SSL/TLS, który potwierdza tożsamość serwera. Certyfikat SSL to nie tylko szyfrowanie danych na linii przeglądarka-strona - to też podpis zaufanego urzędu certyfikacji (CA), który mówi "ta domena jest tym, za kogo się podaje".

Komunikat pojawia się w jednej sytuacji: przeglądarka nie potrafi zweryfikować tego certyfikatu. Powodów jest kilka i warto je od siebie odróżnić, bo każdy prowadzi do innej naprawy:

• certyfikat wygasł (skończyła się data ważności),
• certyfikat dotyczy innej domeny niż ta, którą otwierasz (np. jest na example.com, a wchodzisz na www.example.com),
• certyfikat nie jest podpisany przez zaufany urząd certyfikacji (samopodpisany albo wewnętrzny CA),
• zegar Twojego urządzenia jest tak przesunięty, że ważny certyfikat "wygląda" na nieważny.

Czy to atak? Zwykle nie. To bardziej awaria niż włamanie. Ale ostrzeżenie "hakerzy mogą próbować wykraść Twoje dane" nie jest wymyślone - na publicznym Wi-Fi realnie istnieje ryzyko ataku typu Man-in-the-middle, gdzie ktoś wpina się między Ciebie a serwer. Konkret: jeśli chcesz się gdzieś zalogować, wpisać hasło albo dane karty, a widzisz ten ekran - nie klikaj "dalej". Na zwykłej stronie informacyjnej ryzyko jest małe.

To rozróżnienie - błąd po stronie użytkownika (zegar, sieć, urządzenie) kontra po stronie witryny (certyfikat serwera) - steruje całą resztą tego tekstu.

Kody błędu NET::ERRCERT* - co która nazwa znaczy

Kliknij "Zaawansowane" na ekranie ostrzeżenia, a Chrome lub Edge pokaże dokładny kod. To najważniejsza informacja diagnostyczna, a większość poradników ją pomija. Sprawdź, co masz:

Pro tip admina: NET::ERR_CERT_DATE_INVALID to jedyny kod, który równie często oznacza problem u Ciebie (zły zegar), co na serwerze (wygasły certyfikat). Reszta kodów niemal zawsze wskazuje na konfigurację witryny - jako odwiedzający nic z nimi nie zrobisz poza kontaktem z właścicielem strony.

Naprawa dla odwiedzającego - chcesz wejść na stronę

To Ty widzisz błąd na cudzej stronie i chcesz się na nią dostać. Krok po kroku, od najczęstszej przyczyny:

1. Sprawdź datę i godzinę. Najczęstsza przyczyna w ogóle. Zły zegar sprawia, że przeglądarka uznaje ważny certyfikat za wygasły albo jeszcze nieaktywny. Włącz automatyczne ustawianie daty i czasu: Windows (Ustawienia - Czas i język), macOS (Ustawienia - Ogólne - Data i godzina), Android i iPhone (Ustawienia - data automatyczna). Po zmianie odśwież stronę.
2. Publiczne Wi-Fi z portalem logowania. Hotel, kawiarnia, lotnisko - najpierw musisz zalogować się do sieci przez tzw. captive portal. Wejdź na dowolną zwykłą stronę po http://, żeby wymusić pojawienie się okna logowania, a dopiero potem otwieraj docelową witrynę.
3. Tryb incognito. Otwórz stronę w oknie prywatnym (Ctrl+Shift+N na Windowsie, Shift+Cmd+N na Macu). Incognito pomija rozszerzenia i stary cache, więc od razu widać, czy winne jest coś w Twoim profilu przeglądarki.
4. Wyczyść cache, pliki cookie i stan SSL. Przeglądarka mogła zapamiętać stary, nieważny certyfikat. Wyczyść dane przeglądania z ostatniej godziny i spróbuj ponownie.
5. Wyłącz chwilowo VPN lub antywirus skanujący HTTPS. Niektóre programy antywirusowe i VPN-y podstawiają własny certyfikat, żeby zajrzeć do zaszyfrowanego ruchu - i to one wywołują ostrzeżenie. Wyłącz je na próbę.
6. Zaktualizuj przeglądarkę i system. Stary Windows 7 albo wiekowy Android nie znają nowych urzędów certyfikacji, więc odrzucają nawet poprawne certyfikaty. Zaktualizuj przeglądarkę do najnowszej wersji, a jeśli to Windows 7 - doinstaluj aktualne certyfikaty root albo przejdź na nowszy system.
7. Ostateczność: "Zaawansowane - Przejdź do strony (niebezpieczne)". Ta opcja istnieje i czasem jej użyjesz, ale z jasną zasadą: rób to tylko, gdy ufasz stronie i nie wpisujesz na niej haseł ani danych karty. To nie jest naprawa - to obejście na własne ryzyko.

Jak kliknąć dalej w Chrome, Edge, Safari i na telefonie

Ścieżki różnią się między przeglądarkami. Krótko, gdzie szukać:

• Chrome (desktop) - na ekranie z komunikatem kliknij "Zaawansowane", zobaczysz kod błędu i link "Przejdź do witryny (niebezpieczne)". Kłódkę i szczegóły certyfikatu podejrzysz później, klikając ikonę po lewej od adresu.
• Microsoft Edge - analogicznie: "Zaawansowane", a niżej "Kontynuuj do tej witryny (niezalecane)". Edge korzysta z tego samego silnika co Chrome, więc kody błędu są identyczne.
• Safari (Mac i iPhone) - kliknij "Pokaż szczegóły", a następnie "Odwiedź tę witrynę" i potwierdź. Safari częściej niż Chrome reaguje na zły zegar, więc najpierw sprawdź datę.
• Telefon i Android - na telefonie błąd prawie zawsze wynika ze złej daty lub strefy czasowej (typowo po podróży i zmianie stref) albo z publicznego Wi-Fi. Ustaw datę automatyczną, poczekaj chwilę na synchronizację i odśwież stronę. Ekran w Chrome na Androidzie ma to samo "Zaawansowane - Przejdź do witryny".

Trade-off: kliknięcie "dalej" daje dostęp, ale na czas tej sesji tracisz gwarancję, że rozmawiasz z prawdziwym serwerem. Na blogu czy w encyklopedii to akceptowalne. W banku, sklepie czy panelu logowania - nie.

Naprawa dla właściciela strony - to Twoja witryna pokazuje błąd

Tu zaczyna się prawdziwa robota. Jeśli błąd widzą Twoi odwiedzający, problem jest na serwerze i musisz go naprawić u źródła. Krok po kroku, według przyczyny.

Certyfikat wygasł. Najczęstszy przypadek. Sprawdź datę ważności z terminala:

openssl s_client -connect twojadomena.pl:443 -servername twojadomena.pl 2>/dev/null | openssl x509 -noout -dates

Konkret: jeśli data w polu notAfter już minęła - odnów certyfikat. Najlepiej ustaw darmowy Let's Encrypt z automatycznym odnawianiem (certbot z zadaniem w cronie) albo włącz auto-SSL w panelu hostingu. Certyfikat, który odnawia się sam, to koniec tego problemu na dobre.

Zły hostname albo brak www. Jeśli certyfikat pokrywa twojadomena.pl, ale nie www.twojadomena.pl, część użytkowników zobaczy NET::ERR_CERT_COMMON_NAME_INVALID. Rozwiązanie: certyfikat obejmujący oba warianty (SAN) albo wildcard *.twojadomena.pl.

Brak łańcucha pośrednich CA. Serwer wysyła tylko certyfikat liścia, bez certyfikatów pośrednich, więc część klientów nie potrafi zbudować ścieżki zaufania. Objaw bywa mylący - działa w jednej przeglądarce, nie działa w innej. Sprawdź to na SSL Labs albo lokalnie tym samym openssl s_client i dołóż brakujący łańcuch (chain) do konfiguracji serwera.

Mixed content i przekierowania. Strona ładuje część zasobów po http://, choć sama stoi na HTTPS. Wymuś HTTPS przekierowaniem 301 i włącz nagłówek HSTS, żeby przeglądarka od razu sięgała po wersję szyfrowaną.

Certyfikat samopodpisany. Typowe dla panelu administracyjnego, NAS-a, routera czy localhost. Dla wewnętrznego narzędzia dodaj wyjątek albo własny CA do zaufanych. Dla produkcji - zawsze zaufany certyfikat z prawdziwego urzędu, nigdy samopodpisany.

Diagnoza zdalna z terminala. Zanim zmienisz cokolwiek na serwerze, sprawdź go z zewnątrz. Krótki test HTTPS z innej maszyny pokazuje błąd certyfikatu prosto w konsoli:

curl -vI https://twojadomena.pl

Różnicę między curl a wget przy takiej diagnozie rozkładam we wpisie curl kontra wget. A gdy SSL kończy się nie na serwerze aplikacji, tylko na warstwie pośredniej, zajrzyj do konfiguracji reverse proxy. To podstawowe narzędzie każdego admina i punkt wyjścia do reszty diagnostyki.

Częste błędy i pułapki

Kilka rzeczy, na których ludzie regularnie się przewracają:

• Klikanie "Przejdź dalej" na stronie logowania lub w banku. Tu naprawdę można stracić dane. Granica jest prosta: strona informacyjna - ryzyko małe; cokolwiek z hasłem lub kartą - stop.
• "Wyłączanie" ostrzeżenia flagami przeglądarki zamiast naprawy przyczyny. To maskowanie problemu, nie rozwiązanie. Ostrzeżenie zniknie, ale połączenie dalej nie będzie bezpieczne.
• Naprawianie przeglądarki, gdy winny jest zegar. Zanim wyczyścisz pół systemu, sprawdź datę. Serio, w większości przypadków to wystarcza.
• Odnowienie certyfikatu bez przeładowania serwera. Klasyk po stronie właściciela: nowy certyfikat leży na dysku, ale nginx czy Apache dalej serwuje stary z pamięci. Przeładuj usługę po odnowieniu.
• Certyfikat tylko na wersję bez www (albo tylko z www). Połowa użytkowników widzi błąd, połowa nie, a Ty nie wiesz, o co chodzi. Pokryj oba warianty.
• Mylenie błędu z atakiem i panika. Zamiast się stresować, przeczytaj kod NET::ERR_CERT_* - on od razu mówi, gdzie jest problem.
• Certyfikat odnowiony, ale w cache przeglądarki dalej stary. Po naprawie na serwerze wyczyść u siebie stan SSL albo sprawdź witrynę w oknie incognito - inaczej testujesz starą wersję i wydaje Ci się, że nic nie pomogło.

Pro tip admina: ustaw monitoring wygaśnięcia certyfikatu. Większość paneli hostingowych ma to wbudowane, a dla własnego serwera wystarczy prosty skrypt z openssl w cronie, który raz na dobę sprawdza pole notAfter i wysyła alert na tydzień przed końcem ważności. To tańsze niż tłumaczenie klientom, czemu strona nagle straszy błędem.

FAQ

Co znaczy "połączenie nie jest prywatne"? Przeglądarka nie zaufała certyfikatowi SSL strony i dlatego zablokowała połączenie. Powód to zwykle wygasły certyfikat, certyfikat na inną domenę, niezaufany urząd certyfikacji albo zły zegar w Twoim urządzeniu. To najczęściej problem konfiguracji, a nie włamanie ani atak hakera.

Czy to bezpieczne, żeby kliknąć "Przejdź dalej"? Na zwykłej stronie informacyjnej zazwyczaj tak, ryzyko jest małe. Ale nigdy nie klikaj dalej przy logowaniu, bankowości i płatnościach - na publicznym Wi-Fi realnie grozi wtedy atak Man-in-the-middle i wyciek danych. Jeśli masz wpisać hasło lub numer karty, zamknij stronę.

Jak naprawić błąd w Chrome? Zacznij od daty i godziny - ustaw automatyczne. Potem spróbuj trybu incognito (Ctrl+Shift+N), wyczyść cache i pliki cookie oraz zaktualizuj Chrome do najnowszej wersji. Jeśli błąd jest tylko na jednej stronie, kliknij "Zaawansowane" i sprawdź kod NET::ERR_CERT_* - on wskazuje przyczynę.

Dlaczego błąd pojawia się na telefonie? Najczęściej przez złą datę lub strefę czasową, zwłaszcza po podróży i zmianie stref - certyfikat wygląda wtedy na nieważny. Druga typowa przyczyna to publiczne Wi-Fi z portalem logowania. Włącz automatyczną datę, zaloguj się do sieci i odśwież stronę, a błąd zwykle znika.

Mam ten błąd na Windows 7 - co zrobić? Stary system nie zna nowych urzędów certyfikacji, więc odrzuca poprawne certyfikaty jako niezaufane. Doinstaluj aktualne certyfikaty root przez Windows Update i zaktualizuj przeglądarkę. Docelowo przejdź na nowszy system - Windows 7 nie dostaje już aktualizacji bezpieczeństwa i takich problemów będzie przybywać.

Jak naprawić błąd na mojej stronie? Sprawdź datę ważności certyfikatu i łańcuch pośrednich CA komendą openssl s_client. Jeśli certyfikat wygasł - odnów go, najlepiej przez darmowy Let's Encrypt z automatycznym odnawianiem albo auto-SSL w panelu hostingu. Upewnij się, że certyfikat pokrywa wersję z www i bez www, i przeładuj serwer.

Żeby błąd nie wracał

Konkret dla właściciela strony: najpewniejszy sposób, by ten komunikat nigdy nie wrócił, to hosting, który sam wystawia i odnawia darmowy certyfikat SSL (Let's Encrypt) i pozwala wpiąć witrynę za CDN z zarządzanym SSL. Jeśli dobierasz serwer pod ten scenariusz, sprawdź ranking hostingów i VPS - porównuję tam auto-SSL i konfigurację certyfikatów u różnych dostawców.

A gdy administrujesz własnym serwerem, całą diagnostykę i odnowienie certyfikatu robisz zdalnie po SSH. To ten sam punkt wyjścia, od którego zaczyna się większość roboty admina - reszta to już openssl, curl i spokojne czytanie kodu błędu.