Komunikat „Połączenie nie jest prywatne”, „Połączenie z tą witryną nie jest bezpieczne” albo informacja o błędzie certyfikatu SSL nie zawsze oznaczają ten sam problem. Przyczyną może być wygasły certyfikat, jego niewłaściwa konfiguracja, brak obsługi HTTPS, błąd dotyczący domeny, niepełny łańcuch certyfikatów lub problem występujący wyłącznie na urządzeniu użytkownika. Dlatego pierwszym krokiem nie powinno być ponowne instalowanie certyfikatu, lecz sprawdzenie dokładnego komunikatu i kodu błędu wyświetlanego przez przeglądarkę. To często pozwala szybko zawęzić źródło problemu. Jeśli ostrzeżenie pojawia się na wielu urządzeniach i w różnych sieciach, warto zacząć od konfiguracji strony i serwera. Gdy widzi je tylko jeden użytkownik, przyczyna może znajdować się po jego stronie.
W tym artykule dowiesz się m.in.:
- co oznaczają komunikaty „Połączenie nie jest bezpieczne” i „Połączenie nie jest prywatne” oraz dlaczego nie zawsze wskazują na ten sam problem;
- jakie są najczęstsze przyczyny błędu certyfikatu SSL – od wygaśnięcia certyfikatu po niezgodność z nazwą domeny;
- czym różni się problem z certyfikatem od braku HTTPS oraz błędu mixed content;
- jak rozpoznać, czy źródło problemu znajduje się po stronie strony internetowej, serwera czy urządzenia użytkownika;
- co oznaczają popularne kody błędów, takie jak ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID czy NET::ERR_CERT_AUTHORITY_INVALID;
- jak krok po kroku sprawdzić certyfikat, warianty domeny, przekierowania oraz zasoby ładowane przez HTTP;
- jak prawidłowo przeprowadzić migrację strony z HTTP na HTTPS bez tworzenia problemów z indeksacją;
- czy certyfikat SSL wpływa na SEO i dlaczego większym zagrożeniem od samego braku HTTPS może być niewłaściwie wykonana migracja;
- jak ograniczyć ryzyko ponownego pojawienia się błędów SSL po zmianie hostingu, DNS, CDN lub konfiguracji strony.
- Co oznacza komunikat „Połączenie nie jest bezpieczne”?
- Certyfikat SSL wygasł – co zrobić?
- Certyfikat działa bez www, ale z www już nie. Dlaczego?
- Co to jest mixed content i dlaczego może powodować problemy z HTTPS?
- Jak sprawdzić, dlaczego SSL nie działa?
- Błąd „Połączenie nie jest prywatne” tylko na jednym komputerze – czy to problem strony?
- Jak prawidłowo przejść z HTTP na HTTPS?
- Czy przekierowania 301 z HTTP na HTTPS obniżają pozycje?
- Jak zapobiegać kolejnym błędom certyfikatu?
- Najważniejsze: jak naprawić błąd SSL?
- Błąd certyfikatu SSL – fakty warte zapamiętania
- Najczęściej zadawane nam pytania
- #1 Dlaczego Chrome pokazuje „Połączenie nie jest prywatne”?
- #2 Co oznacza ERR_CERT_DATE_INVALID?
- #3 Co oznacza ERR_CERT_COMMON_NAME_INVALID?
- #4 Czy można wejść na stronę mimo ostrzeżenia SSL?
- #5 Dlaczego błąd SSL widzę tylko na jednym komputerze?
- #6 Czy darmowy certyfikat SSL jest bezpieczny?
- #7 Czy SSL pomaga w SEO?
- #8 Czy po przejściu na HTTPS trzeba zmieniać sitemap?
- #9 Czy trzeba zmienić wszystkie linki HTTP na stronie?
- #10 Co zrobić, gdy nie wiem, dlaczego certyfikat nie działa?
Co oznacza komunikat „Połączenie nie jest bezpieczne”?
Przeglądarka wyświetla ostrzeżenie, gdy nie może potwierdzić, że połączenie ze stroną spełnia wymagania dotyczące bezpieczeństwa albo gdy witryna w ogóle nie korzysta z HTTPS. Nie oznacza to automatycznie, że strona została zhakowana. Oznacza natomiast, że nie należy ignorować sposobu, w jaki przesyłane są dane pomiędzy przeglądarką a serwerem. W prawidłowo skonfigurowanej stronie HTTPS transmisja jest szyfrowana, a certyfikat pomaga przeglądarce potwierdzić tożsamość serwera. Popularne określenie „certyfikat SSL” pozostało w powszechnym użyciu, choć współczesne połączenia HTTPS wykorzystują protokół TLS, będący następcą SSL. Dla właściciela witryny ostrzeżenie ma również bardzo praktyczny wymiar. Użytkownik, który przed wejściem na stronę widzi ekran informujący o problemie z prywatnością lub bezpieczeństwem połączenia, może po prostu zrezygnować z dalszej wizyty. Szczególnie problematyczne jest to w sklepach internetowych, serwisach zbierających dane z formularzy i wszystkich miejscach, w których użytkownik loguje się albo podaje informacje kontaktowe.
Dlaczego pojawia się błąd certyfikatu SSL?
Nie istnieje jedna przyczyna wszystkich błędów SSL. Dlatego warto zwrócić uwagę nie tylko na samo ostrzeżenie, ale również na kod podany przez przeglądarkę. Do najczęstszych problemów należą:
| Komunikat lub problem | Możliwa przyczyna | Co warto sprawdzić? |
|---|---|---|
| ERR_CERT_DATE_INVALID | certyfikat jest nieważny lub występuje problem z datą | datę ważności certyfikatu oraz ustawienia daty i czasu urządzenia |
| ERR_CERT_COMMON_NAME_INVALID | certyfikat nie odpowiada domenie | domeny objęte certyfikatem, np. wariant z www i bez www |
| NET: :ERR_CERT_AUTHORITY_INVALID | przeglądarka nie ufa wystawcy lub łańcuchowi certyfikatów | wystawcę certyfikatu oraz konfigurację certyfikatów pośrednich |
| „Niezabezpieczona” | witryna działa przez HTTP | dostępność wersji HTTPS i przekierowania |
| problemy tylko z częścią strony | zasoby są pobierane przez HTTP | mixed content, np. obrazy, skrypty, style i iframe |
| błąd występujący tylko u jednej osoby | problem lokalny | datę systemową, sieć rozszerzenia, oprogramowanie zabezpieczające |
Sam kod błędu potrafi więc oszczędzić sporo czasu. Inaczej wygląda naprawa wygasłego certyfikatu, inaczej błędu nazwy domeny, a jeszcze inaczej sytuacji, w której HTTPS działa prawidłowo, ale witryna pobiera niektóre elementy przy użyciu HTTP.
Certyfikat SSL wygasł – co zrobić?
Certyfikaty mają określony okres ważności. Jeśli nie zostaną w porę odnowione lub nowy certyfikat nie zostanie prawidłowo zainstalowany na serwerze, przeglądarka może zacząć ostrzegać użytkowników przed wejściem na stronę.
W takiej sytuacji należy sprawdzić:
- do kiedy certyfikat jest ważny,
- czy został już wystawiony kolejny certyfikat,
- czy mechanizm automatycznego odnawiania działa poprawnie,
- czy odnowiony certyfikat został rzeczywiście wdrożony na właściwym serwerze,
- czy konfiguracja nie jest dodatkowo obsługiwana przez CDN lub proxy.
Samo korzystanie z automatycznie odnawianego certyfikatu nie daje pewności, że problem nigdy się nie pojawi. Wystarczy błąd konfiguracji serwera, zmiana DNS albo problem podczas odnowienia, aby przeglądarka zaczęła zgłaszać nieważny certyfikat. Dlatego warto kontrolować nie tylko jego termin ważności, ale również sam proces odnawiania.
Certyfikat działa bez www, ale z www już nie. Dlaczego?
To częsty problem związany z zakresem certyfikatu. Dla przeglądarki:
https://domena.pl
oraz
https://www.domena.pl
to dwa różne hosty. Certyfikat musi więc obejmować wszystkie warianty domeny, które mają być dostępne dla użytkowników. Jeżeli certyfikat wystawiono wyłącznie dla domena.pl, a użytkownik otwiera www.domena.pl, może pojawić się komunikat o niezgodności nazwy domeny. Analogiczny problem występuje przy niektórych subdomenach. Trzeba wtedy sprawdzić pola określające domeny objęte certyfikatem i upewnić się, że odpowiadają rzeczywistej konfiguracji serwisu. Jednocześnie dobrze ustalić jedną docelową wersję domeny i przekierować do niej pozostałe warianty.
Co to jest mixed content i dlaczego może powodować problemy z HTTPS?
Zdarza się, że sama podstrona otwiera się przez HTTPS, ale część znajdujących się na niej elementów jest nadal pobierana przez HTTP. To właśnie mixed content, czyli mieszana zawartość.
Problem może dotyczyć między innymi:
- grafik,
- plików JavaScript,
- arkuszy CSS,
- fontów,
- ramek iframe,
- filmów i materiałów osadzanych z innych serwisów.
Przykładowo strona może działać pod adresem https://example.pl, ale w kodzie znajdować się będzie grafika pobierana z http://example.pl/zdjecie.jpg.
Przy przejściu na HTTPS warto więc przeskanować całą witrynę, a nie tylko sprawdzić stronę główną. Stare adresy HTTP mogą pozostawać w treści artykułów, szablonach CMS, skryptach, stylach lub wtyczkach. W zależności od rodzaju zasobu przeglądarka może ostrzec użytkownika albo zablokować jego załadowanie.
Jak sprawdzić, dlaczego SSL nie działa?
Jeżeli strona nagle zaczęła wyświetlać błąd certyfikatu, warto prowadzić diagnostykę w określonej kolejności. Dzięki temu nie trzeba zmieniać konfiguracji „na próbę”.
Sprawdź dokładny kod błędu w przeglądarce
Informacja taka jak ERR_CERT_COMMON_NAME_INVALID daje znacznie więcej wskazówek niż samo „połączenie nie jest bezpieczne”.
Sprawdź certyfikat
Zweryfikuj jego datę ważności, domeny, wystawcę oraz łańcuch certyfikatów.
Otwórz stronę na innym urządzeniu
Jeżeli problem występuje również tam, zwiększa się prawdopodobieństwo, że źródłem jest strona lub serwer.
Sprawdź różne warianty domeny
Przetestuj wersję z `www`, bez `www` oraz inne używane subdomeny.
Zweryfikuj przekierowania
Użytkownik wpisujący adres HTTP powinien zostać skierowany do właściwej wersji HTTPS, bez zbędnych pętli i wieloetapowych przekierowań.
Sprawdź mixed content
Szczególną uwagę zwróć na starsze podstrony oraz zasoby ładowane z zewnętrznych domen.
Jeżeli korzystasz z CDN lub proxy, sprawdź również jego konfigurację
Certyfikat widziany przez użytkownika nie zawsze musi być tym samym, który został zainstalowany bezpośrednio na serwerze źródłowym. Dopiero po takiej diagnozie wiadomo, czy potrzebne jest odnowienie certyfikatu, zmiana konfiguracji domeny, poprawienie łańcucha certyfikatów czy modyfikacja kodu strony.
Błąd „Połączenie nie jest prywatne” tylko na jednym komputerze – czy to problem strony?
Nie zawsze. Jeśli witryna działa poprawnie na innych komputerach i telefonach, a komunikat wyświetla się tylko na jednym urządzeniu, warto najpierw sprawdzić jego konfigurację. Źródłem problemu może być między innymi nieprawidłowa data i godzina systemowa, konkretna sieć Wi-Fi, rozszerzenie przeglądarki albo oprogramowanie, które przechwytuje i analizuje połączenia HTTPS.
Dobrym testem jest otworzenie tej samej witryny:
- w innej przeglądarce,
- na innym urządzeniu,
- w innej sieci,
- w trybie prywatnym/incognito.
Jeśli ostrzeżenie pojawia się niezależnie od urządzenia i połączenia internetowego, należy już dokładniej zbadać certyfikat i konfigurację serwera.
Jak prawidłowo przejść z HTTP na HTTPS?
Inna sytuacja występuje wtedy, gdy strona dopiero przechodzi z HTTP na HTTPS. Samo zainstalowanie certyfikatu nie kończy migracji. Adresy muszą zostać właściwie przekierowane, a konfiguracja witryny powinna konsekwentnie wskazywać nową wersję.
Z perspektywy Google zmiana HTTP → HTTPS oznacza zmianę adresów URL. Warto więc przeprowadzić ją w sposób uporządkowany.
Ustaw przekierowania z HTTP na HTTPS
Każdy stary adres powinien prowadzić do swojego odpowiednika po HTTPS.
Przykładowo:
http://example.pl/oferta/
powinno przekierowywać bezpośrednio do:
https://example.pl/oferta/
Nie należy kierować wszystkich starych podstron na stronę główną tylko dlatego, że jest dostępna przez HTTPS. Zachowanie relacji jeden stary URL → jeden właściwy nowy URL pomaga zarówno użytkownikom, jak i wyszukiwarkom zrozumieć zmianę.
Zaktualizuj linkowanie wewnętrzne
Po wdrożeniu przekierowań warto poprawić linki znajdujące się bezpośrednio w witrynie. Jeśli menu nadal prowadzi najpierw do HTTP, a dopiero później następuje przekierowanie do HTTPS, tworzymy niepotrzebny dodatkowy krok.
Dotyczy to także:
- linków w treści,
- grafik,
- canonicali,
- hreflangów,
- plików CSS i JavaScript,
- odnośników generowanych przez szablon strony.
Im mniej serwis polega na przekierowaniach wewnątrz własnej struktury, tym czytelniejsza jest jego konfiguracja.
Zaktualizuj sitemap
Mapa strony powinna zawierać aktualne adresy HTTPS. Po migracji warto przesłać ją w Google Search Console i kontrolować sposób indeksowania nowych URL-i. W Search Console można również sprawdzić wybrane adresy za pomocą narzędzia do inspekcji URL. Jest to szczególnie przydatne, jeżeli po migracji część podstron nie pojawia się w wynikach albo Google nadal wskazuje starszą wersję adresu.
Sprawdź canonicale oraz blokady indeksowania
Podczas prac nad nową wersją strony stosuje się czasem noindex albo blokady w robots.txt, aby środowisko testowe nie zostało zaindeksowane. Problem zaczyna się wtedy, gdy takie ustawienia pozostają aktywne po publikacji. Po wdrożeniu HTTPS należy więc sprawdzić nie tylko certyfikat, ale również:
- canonicale,
- meta robots,
- robots.txt,
- odpowiedzi HTTP,
- sitemap,
- linkowanie wewnętrzne.
Błąd w którymś z tych obszarów może sprawić, że technicznie działająca strona HTTPS będzie miała problemy z indeksacją.
Czy certyfikat SSL wpływa na pozycjonowanie?
HTTPS jest jednym z sygnałów uwzględnianych przez Google, ale nie należy traktować instalacji certyfikatu jako sposobu na samodzielne wywindowanie strony w wynikach wyszukiwania. Znacznie większe znaczenie mają m.in. jakość strony, treści, sposób odpowiadania na intencję wyszukiwania, linkowanie czy kondycja techniczna serwisu. Z perspektywy SEO większym problemem niż sam „brak dodatkowego punktu za HTTPS” może być źle przeprowadzona migracja. Nieprawidłowe przekierowania, błędne canonicale, pozostawione adresy HTTP w sitemap albo zablokowanie nowych URL-i mogą utrudniać Google prawidłowe przetworzenie zmiany. Warto też pamiętać, że przy większej migracji widoczność może przez pewien czas się wahać, gdy Google ponownie skanuje i indeksuje adresy. Samo wystąpienie krótkotrwałych zmian nie musi więc oznaczać, że migracja została wykonana nieprawidłowo.
Czy przekierowania 301 z HTTP na HTTPS obniżają pozycje?
Nie należy wychodzić z założenia, że prawidłowe stałe przekierowanie samo w sobie powoduje utratę wartości SEO. Jest ono standardowym sposobem poinformowania wyszukiwarki, że dany zasób na stałe znajduje się pod nowym adresem.
Problemem może być natomiast:
- przekierowanie starej podstrony do niepowiązanej treści,
- wielokrotne przekierowanie HTTP → HTTPS → inny URL → kolejny URL,
- pozostawienie części adresów bez właściwego odpowiednika,
- tworzenie pętli przekierowań.
Po migracji dobrze jest więc przeskanować stronę i sprawdzić nie tylko to, czy przekierowanie istnieje, ale również dokąd prowadzi i ile kroków wymaga dotarcie do docelowej podstrony.
Jak zapobiegać kolejnym błędom certyfikatu?
SSL/TLS nie powinien być konfiguracją, o której przypominamy sobie dopiero wtedy, gdy użytkownicy zaczynają zgłaszać ostrzeżenia w przeglądarce.
Warto regularnie kontrolować:
- datę ważności certyfikatu,
- automatyczne odnawianie,
- warianty domeny objęte certyfikatem,
- konfigurację po zmianie hostingu lub DNS,
- ustawienia CDN,
- adresy HTTP pojawiające się w nowych treściach,
- prawidłowość przekierowań.
Szczególnie ostrożnie trzeba podchodzić do zmian infrastrukturalnych. Migracja hostingu, uruchomienie CDN, zmiana domeny czy przebudowa strony mogą sprawić, że poprawnie działający wcześniej HTTPS zacznie wymagać ponownej konfiguracji.
Najważniejsze: jak naprawić błąd SSL?
Jeżeli przeglądarka pokazuje komunikat „Połączenie nie jest bezpieczne”, najpierw sprawdź dokładny kod błędu. Następnie zweryfikuj ważność i zakres certyfikatu, konfigurację serwera, obsługiwane warianty domeny oraz to, czy witryna nie pobiera zasobów przez HTTP. Jeżeli problem pojawił się po migracji strony z HTTP na HTTPS, sprawdź również przekierowania, canonicale, linkowanie wewnętrzne, sitemap i indeksację w Google Search Console. Nie warto rozpoczynać naprawy od przypadkowego zmieniania ustawień — prawidłowa diagnoza zwykle znacząco zawęża zakres potrzebnych prac.
Błąd certyfikatu SSL – fakty warte zapamiętania
- Komunikat „Połączenie nie jest bezpieczne” nie zawsze oznacza, że strona została zhakowana. Może wskazywać m.in. na brak HTTPS, wygasły certyfikat, problem z domeną albo konfiguracją urządzenia.
- Warto zwracać uwagę na dokładny kod błędu przeglądarki, ponieważ często pozwala on szybko wskazać źródło problemu.
- Wygasły certyfikat to tylko jedna z możliwych przyczyn. Błędy mogą wynikać również z niezgodności domeny, niepełnego łańcucha certyfikatów czy konfiguracji CDN.
- Certyfikat powinien obejmować wszystkie używane warianty domeny, np. wersję z www, bez www oraz potrzebne subdomeny.
- Strona może działać przez HTTPS, a mimo to zawierać mixed content, czyli zasoby pobierane za pomocą niezabezpieczonego HTTP.
- Gdy błąd występuje tylko na jednym urządzeniu, warto sprawdzić m.in. datę systemową, przeglądarkę, rozszerzenia, oprogramowanie zabezpieczające oraz sieć.
- Podczas migracji HTTP → HTTPS samo zainstalowanie certyfikatu nie wystarcza. Należy również zadbać o przekierowania, linkowanie wewnętrzne, canonicale i sitemap.
- Google zaleca stosowanie trwałych przekierowań przy zmianach adresów URL, a prawidłowo wykonane przekierowania 301 nie powodują utraty PageRank.
- HTTPS jest jednym z sygnałów wykorzystywanych przez Google, ale sam certyfikat SSL nie zastępuje działań SEO ani jakościowej i technicznej optymalizacji witryny.
- Certyfikat SSL/TLS chroni transmisję danych między przeglądarką a serwerem, ale nie zabezpiecza witryny przed wszystkimi rodzajami ataków.
Dobra wskazowka bo mialem problem z SSL a nie wiedzialem jak to naprawic serio przydatne info