Po migracji strony SSL nagle przestaje działać, przeglądarka pokazuje ostrzeżenie, a zamiast kłódki w pasku adresu widzisz komunikat o „niezabezpieczonym połączeniu”? To jeden z najczęstszych problemów po przenosinach hostingu, zmianie serwera, wdrożeniu nowego CMS albo przełączeniu domeny na nową infrastrukturę. Z zewnątrz wygląda jak drobiazg, ale w praktyce potrafi uderzyć w SEO, konwersję, logowanie użytkowników, płatności i wiarygodność firmy.
Najgorsze w tym problemie jest to, że objawy bywają różne. U jednej osoby nie ładuje się cała strona. U innej działa tylko strona główna, ale panel admina zwraca błąd. Ktoś inny widzi komunikat, że certyfikat jest wystawiony na inną domenę. Bywa też tak, że po migracji wszystko działa na pierwszy rzut oka, lecz w tle ładowane są zasoby po HTTP i przeglądarka blokuje obrazki, skrypty lub style. W efekcie strona wygląda „rozsypana”, formularze nie działają, a koszyk w sklepie internetowym nie przechodzi do płatności.
Wniosek jest prosty: po migracji SSL trzeba sprawdzić nie tylko sam certyfikat, ale całą ścieżkę działania strony: DNS, konfigurację serwera, przekierowania, adresy w bazie danych, CDN, wtyczki, cache i integracje zewnętrzne. W tym artykule pokazuję, jak przejść przez diagnozę krok po kroku i jak naprawić problem bez wprowadzania kolejnych usterek.
Szybka odpowiedź
Jeżeli po migracji masz problem z SSL, zacznij od czterech rzeczy:
- sprawdź, czy certyfikat jest wystawiony dokładnie na tę domenę, której używasz, również w wersji z
wwwi bezwww, - upewnij się, że serwer podaje pełny łańcuch certyfikatu, a nie tylko sam certyfikat końcowy,
- zweryfikuj przekierowania z HTTP na HTTPS i czy nie ma pętli przekierowań,
- poszukaj mieszanych treści, czyli zasobów ładowanych po starym adresie HTTP.
Jeśli nie masz pewności, czy problem leży po stronie certyfikatu, DNS, aplikacji czy CDN, nie wykonuj przypadkowych zmian. Jedna błędna korekta potrafi wyłączyć stronę lub zablokować logowanie. Najpierw zrób kopię zapasową i dopiero potem wprowadzaj poprawki.
Diagnoza problemu
„SSL po migracji” to skrót myślowy. W praktyce chodzi o zestaw możliwych problemów, które ujawniają się po przeniesieniu strony na nowy serwer, nowy hosting, nowy adres IP, nowy panel administracyjny albo po zmianie konfiguracji domeny. Wiele osób zakłada, że wystarczy „wgrać certyfikat” i wszystko będzie gotowe. Niestety to nie działa w ten sposób.
SSL/TLS nie jest jedną rzeczą, tylko ciągiem zależności. Przeglądarka sprawdza między innymi:
- czy domena, którą odwiedza użytkownik, zgadza się z nazwą na certyfikacie,
- czy certyfikat jest ważny czasowo,
- czy certyfikat został wydany przez zaufane centrum certyfikacji,
- czy serwer przekazuje pełny łańcuch zaufania,
- czy połączenie nie jest podszywane lub przerywane przez błędną konfigurację reverse proxy, CDN lub WAF.
Po migracji najczęściej psuje się nie sam certyfikat, tylko otoczenie, w którym działa. Dlatego strona może wyglądać poprawnie w jednym miejscu, a w innym generować alerty. Przykładowo:
- na nowym serwerze certyfikat został zainstalowany, ale konfiguracja Apache/Nginx wskazuje na inny plik,
- domena została przepięta w DNS, ale propagacja jeszcze nie zakończyła się na wszystkich serwerach pośrednich,
- CMS nadal zapisuje w treści linki do starych adresów HTTP,
- panel logowania lub koszyk w sklepie korzysta z osobnego subdomenowego endpointu, który nie ma ważnego certyfikatu,
- CDN lub usługa cache pokazuje starą wersję pliku konfiguracyjnego,
- wtyczka bezpieczeństwa wymusza przekierowanie w sposób powodujący pętlę.
Ważne jest też to, że objawy bywają mylące. Komunikat „Twoje połączenie nie jest prywatne” nie zawsze oznacza zły certyfikat. Może oznaczać błędną datę na urządzeniu, problem z łańcuchem, konflikt domeny, zły adres IP po migracji, a nawet interwencję pośredniego proxy. Z kolei brak kłódki w pasku adresu nie musi świadczyć o tym, że certyfikat nie działa. Czasami strona jest dostępna przez HTTPS, ale część zasobów ładowana jest po HTTP i to właśnie przeglądarka uznaje za zagrożenie.
Jeśli problem wystąpił natychmiast po migracji, diagnozę zacznij od trzech osi: domena, serwer, aplikacja. Jeśli problem pojawił się po kilku godzinach lub dniach, dodaj jeszcze DNS i cache. Jeśli strona działa tylko u niektórych użytkowników, sprawdź CDN, przeglądarki, pamięć podręczną oraz czas lokalny urządzenia. To właśnie różnice w tych elementach powodują, że jedna osoba widzi stronę poprawnie, a druga dostaje błąd certyfikatu.
Możliwe przyczyny
Poniżej znajdują się najczęstsze źródła problemów z SSL po migracji. Warto je czytać nie jak listę abstrakcyjnych możliwości, ale jak praktyczną mapę dochodzenia do przyczyny.
1. Certyfikat nie pasuje do domeny
Najprostszy i bardzo częsty przypadek. Strona została przeniesiona z jednej wersji domeny na drugą, na przykład z example.pl na www.example.pl lub odwrotnie, a certyfikat został wystawiony tylko dla jednej z nich. W efekcie przeglądarka widzi niezgodność nazwy i blokuje połączenie. Problem jest szczególnie częsty przy migracji na inny hosting, gdzie nowa konfiguracja nie uwzględniała dokładnie tych samych wariantów domeny co poprzednia.
2. Brak pełnego łańcucha certyfikatu
Nawet poprawny certyfikat może nie zadziałać, jeśli serwer nie wysyła intermediate certificates, czyli certyfikatów pośrednich. W praktyce wygląda to tak, jakby serwer mówił: „mam certyfikat”, ale nie udowadniał całej ścieżki zaufania. Efekt zależy od przeglądarki i urządzenia, ale często pojawia się ostrzeżenie o zaufaniu do certyfikatu lub błąd ładowania HTTPS.
3. Zły VirtualHost lub zła konfiguracja serwera
Na serwerach współdzielonych i VPS-ach częsty jest problem, w którym certyfikat został poprawnie dodany, lecz konfiguracja Apache albo Nginx wskazuje inny plik, inny blok serwera lub inny port. Po migracji łatwo o sytuację, w której HTTPS działa dla jednej witryny, a dla drugiej serwer zwraca domyślny certyfikat panelu lub hosta technicznego.
4. Pętle przekierowań
Po migracji często ustawia się automatyczne przekierowanie z HTTP na HTTPS, ale nie uwzględnia się konfiguracji już aktywnej w panelu hostingu, w CMS albo w CDN. Wtedy strona próbuje przekierowywać sama siebie w kółko. Użytkownik widzi komunikat o zbyt wielu przekierowaniach albo strona w ogóle się nie otwiera.
5. Mieszane treści
To jeden z najbardziej zdradliwych problemów. Sama strona jest na HTTPS, ale w kodzie znajdują się zasoby ładowane po HTTP: obrazki, arkusze CSS, pliki JavaScript, fonty, iframe, skrypty analityczne, elementy zewnętrzne. Przeglądarka może blokować takie zasoby albo ostrzegać, że strona nie jest w pełni bezpieczna. Czasem wystarczy jeden stary adres zapisany w bazie danych, by cały front wyglądał nieprofesjonalnie.
6. Baza danych i konfiguracja CMS wskazują stare adresy
Po migracji strona mogła zostać przeniesiona z nową domeną lub nową ścieżką, ale w bazie danych nadal siedzą stare adresy HTTP. Dotyczy to treści wpisów, ustawień motywu, pól konfiguracyjnych, danych wtyczek, adresów mediów i linków w zamówieniach lub mailach transakcyjnych. Problem jest bardzo częsty w WordPressie, PrestaShop, Magento i innych systemach, gdzie adresy są zapisane w wielu miejscach.
7. CDN, proxy lub WAF pośredniczą w ruchu
Jeśli po migracji korzystasz z CDN, reverse proxy lub zapory aplikacyjnej, SSL może być terminowany na innym etapie niż myślisz. Oznacza to, że certyfikat na origin server może być poprawny, ale warstwa pośrednia nadal podaje starą konfigurację, nie ten certyfikat lub nieaktualne reguły przekierowań. To częste w przypadku stron o dużym ruchu i sklepów internetowych.
8. Propagacja DNS jeszcze się nie zakończyła
Po migracji domena mogła zostać skierowana na nowy adres IP, ale różni użytkownicy trafiają jeszcze na różne serwery w zależności od lokalizacji, pamięci podręcznej operatora DNS i czasu od ostatniej zmiany. Przez kilka godzin, a czasem dłużej, jedni widzą nową wersję strony, inni starą. Jeśli na starym serwerze SSL wygasł albo certyfikat był inny, pojawiają się trudne do powtórzenia błędy.
9. Problem z datą i godziną na urządzeniu
To rzadziej problem po stronie serwera, a częściej po stronie użytkownika. Jeżeli zegar w komputerze lub telefonie jest rozjechany, przeglądarka może uznać certyfikat za nieważny. Przy diagnozie warto jednak brać to pod uwagę, zwłaszcza jeśli zgłasza się tylko jedna osoba lub jeden typ urządzenia.
10. Certyfikat wygasł albo nie został odnowiony po migracji
Po przenosinach łatwo przeoczyć automatyczne odnowienie. Nowy serwer może nie mieć ustawionego zadania odświeżania certyfikatu, firewall może blokować walidację Let’s Encrypt, a zmiana DNS mogła przerwać proces odnowienia. Wtedy problem pojawia się nie od razu, tylko po upływie ważności certyfikatu.
Rozwiązanie krok po kroku
Poniższa procedura jest bezpieczna dla większości standardowych migracji. Jeśli obsługujesz sklep internetowy, stronę firmową z formularzami lub serwis oparty o wiele integracji, wykonuj ją na spokojnie i po kolei. Nie przeskakuj etapów, bo to zwiększa ryzyko wprowadzenia błędów.
Krok 1: Zrób kopię zapasową
Zanim zmienisz cokolwiek w certyfikacie, DNS, konfiguracji serwera czy bazie danych, wykonaj kopię plików i bazy danych. Jeżeli masz dostęp do snapshotu lub backupu hostingu, sprawdź, czy da się go odtworzyć. W przypadku problemów z SSL i przekierowaniami jedna nieuważna zmiana potrafi odciąć dostęp do panelu administracyjnego.
Krok 2: Sprawdź, jak dokładnie objawia się problem
Zapisz, co widzisz w przeglądarce: komunikat o nieprawidłowym certyfikacie, brak kłódki, ostrzeżenie o mieszanej zawartości, pętlę przekierowań, błąd DNS, brak odpowiedzi serwera. To ważne, bo inne działania naprawcze stosuje się przy błędzie certyfikatu, a inne przy mixed content. Jeżeli możesz, sprawdź problem w kilku przeglądarkach i na kilku urządzeniach.
Krok 3: Zweryfikuj domenę i warianty adresu
Ustal, czy strona ma działać z www, bez www, na subdomenie, czy na kilku wariantach równolegle. Certyfikat musi obejmować wszystkie wykorzystywane nazwy. Jeśli migracja zmieniła docelowy adres, sprawdź, czy DNS i konfiguracja serwera wskazują dokładnie ten sam wariant, który jest zapisany w certyfikacie.
Krok 4: Sprawdź, czy certyfikat jest zainstalowany na właściwym hoście
Na serwerach z wieloma stronami bardzo łatwo przypisać certyfikat do złej witryny. Wejdź w konfigurację hosta, upewnij się, że certyfikat jest przypisany do właściwej domeny i że odpowiada temu samemu katalogowi dokumentów, z którego serwer serwuje stronę. Jeśli korzystasz z panelu hostingowego, sprawdź też, czy nie ma osobnej konfiguracji dla subdomen i aliasów.
Krok 5: Upewnij się, że serwer wysyła pełny chain
Jeżeli masz dostęp do konfiguracji, zweryfikuj, czy używany jest pełny plik certyfikatu, a nie sam certyfikat końcowy. W praktyce na Nginx często oznacza to poprawny plik fullchain.pem zamiast samego cert.pem. Na Apache analogicznie należy dopilnować, by serwer podawał komplet wymaganych certyfikatów pośrednich. Brak chainu to częsta przyczyna błędów po migracji.
Krok 6: Skontroluj przekierowania HTTP/HTTPS
Sprawdź, czy przekierowanie z HTTP na HTTPS działa tylko w jednym miejscu. Jeżeli robi to panel hostingu, wtyczka CMS, reguła w pliku serwera i jeszcze CDN, bardzo łatwo o konflikt. Docelowo przekierowanie powinno być jedno, spójne i przewidywalne. Po włączeniu przekierowań otwórz stronę w przeglądarce prywatnej i sprawdź, czy adres końcowy jest poprawny oraz czy nie ma zapętlenia.
Krok 7: Wyszukaj mieszane treści
Przeskanuj stronę pod kątem zasobów ładowanych przez HTTP. W CMS sprawdź treści wpisów, widgety, ustawienia motywu, stopkę, nagłówki, formularze, mapy, osadzone filmy i integracje zewnętrzne. W kodzie źródłowym szukaj linków zaczynających się od http://. Jeżeli strona korzysta z bazy danych, warto wykonać kontrolowaną zamianę adresów, ale tylko po wcześniejszej kopii i po dokładnym sprawdzeniu, czy nie ruszasz wartości technicznych, których nie wolno zmieniać.
Krok 8: Zaktualizuj adres strony w CMS
W wielu systemach trzeba ręcznie ustawić główny adres strony na HTTPS. Jeśli tego nie zrobisz, CMS może nadal generować linki HTTP, mimo że strona jest dostępna bezpiecznie. Dotyczy to zarówno adresu witryny, jak i adresu panelu administracyjnego w niektórych konfiguracjach. Po zmianie wyczyść cache aplikacji.
Krok 9: Wyczyść cache na każdym poziomie
Po migracji to absolutna konieczność. Wyczyść cache CMS, cache wtyczek, cache serwera, cache CDN, a także pamięć przeglądarki podczas testów. Jeśli jedna warstwa nadal trzyma starą wersję strony, możesz dojść do błędnych wniosków i naprawiać dobry element zamiast zepsutego.
Krok 10: Przetestuj panel, formularze i transakcje
Nie ograniczaj się do strony głównej. Po SSL po migracji często psują się logowanie, rejestracja, formularze kontaktowe, koszyk, płatności, wysyłka e-maili, integracje z zewnętrznymi systemami i webhooki. Sprawdź każdy kluczowy proces, bo strona może wyglądać dobrze wizualnie, a jednocześnie być funkcjonalnie uszkodzona.
Krok 11: Sprawdź certyfikat na poziomie serwera i przeglądarki
Otwórz szczegóły certyfikatu i porównaj: nazwę domeny, datę ważności, wystawcę, SAN-y, typ klucza, informację o pośrednich certyfikatach. Jeżeli korzystasz z wielu środowisk, upewnij się, że testujesz właściwy host, a nie np. starą wersję strony z pamięci DNS. W razie potrzeby odpytywanie strony wykonaj z kilku lokalizacji lub użyj narzędzi diagnostycznych dostępnych w panelu hostingu.
Krok 12: Dopiero na końcu popraw SEO i indeksację
Jeżeli przez jakiś czas strona była dostępna pod HTTP lub z błędami certyfikatu, po naprawie trzeba zadbać o konsekwencję indeksacji. Sprawdź mapę adresów, canonicale, przekierowania, wersje www/non-www i spójność wewnętrznych linków. To ważne, bo problem z SSL po migracji bardzo często zostawia po sobie ślad w wyszukiwarce i analityce.
W praktyce najszybsza ścieżka naprawy wygląda tak: certyfikat na właściwą domenę, pełny chain, jedna poprawna reguła przekierowania, aktualizacja adresów w CMS, czyszczenie cache i testy funkcjonalne. Dopiero jeśli problem zostaje, wchodzisz głębiej w konfigurację DNS, CDN, reverse proxy i logi serwera.
Najczęstsze błędy
- instalacja certyfikatu bez sprawdzenia, czy obejmuje właściwą domenę i wszystkie warianty adresu,
- jednoczesne ustawienie przekierowań w panelu hostingu, CMS i CDN,
- użycie tylko certyfikatu końcowego zamiast pełnego chainu,
- pozostawienie starych adresów HTTP w bazie danych i szablonach,
- testowanie wyłącznie strony głównej zamiast całej ścieżki użytkownika,
- czyszczenie tylko jednej warstwy cache i uznanie problemu za rozwiązany,
- ignorowanie subdomen, API, panelu administracyjnego i środowisk stagingowych,
- zmiana DNS bez uwzględnienia czasu propagacji,
- naprawa „na próbę” przez wyłączanie kolejnych zabezpieczeń zamiast diagnozy przyczyny,
- brak backupu przed edycją bazy, konfiguracji serwera i wtyczek.
Wiele z tych błędów nie powoduje natychmiastowej awarii, ale tworzy niestabilne środowisko. Strona niby działa, lecz losowo wyświetla ostrzeżenia, gubi sesje, blokuje elementy lub przestaje przechodzić płatność na wybranych urządzeniach. Właśnie dlatego po migracji trzeba patrzeć szerzej niż tylko na ikonę kłódki.
Kiedy nie robić tego samodzielnie
Samodzielna naprawa ma sens, jeśli problem jest prosty i dobrze rozumiesz środowisko, na którym działa strona. Nie warto jednak robić tego na własną rękę, gdy:
- strona obsługuje płatności, logowanie użytkowników lub dane wrażliwe,
- masz sklep internetowy i każda minuta niedostępności oznacza realną stratę,
- po migracji działa CDN, reverse proxy, WAF lub wiele subdomen,
- certyfikat musi obejmować kilka domen lub środowisk,
- nie masz dostępu do pełnej konfiguracji serwera,
- problem pojawia się tylko u części użytkowników i trudno go odtworzyć,
- strona działa na niestandardowym stacku technologicznym,
- po zmianach przestał działać panel administracyjny,
- nie masz pewności, jak wykonać backup i odwrócić zmiany.
Jeśli wchodzisz w obszar serwera produkcyjnego bez doświadczenia, możesz niechcący wyłączyć stronę całkowicie, zwłaszcza przy jednoczesnej edycji certyfikatu, przekierowań i cache. W środowiskach biznesowych to zbyt duże ryzyko.
Kiedy zgłosić się do specjalisty
Do specjalisty warto zgłosić się od razu, gdy problem:
- nie daje się zidentyfikować po podstawowej diagnostyce,
- wraca mimo pozornie poprawnych zmian,
- dotyczy wielu warstw jednocześnie: DNS, serwera, CMS i CDN,
- wpływa na sprzedaż, formularze lub panel logowania,
- występuje po wdrożeniu na produkcję i nie ma miejsca na eksperymenty,
- wiąże się z błędami bezpieczeństwa, nie tylko z wygodą użytkownika.
Specjalista przyspiesza diagnozę, bo sprawdza logi serwera, nagłówki HTTP, konfigurację certyfikatu, status propagacji DNS, reguły przekierowań i zachowanie warstwy pośredniej. Najważniejsze jest jednak to, że wie, czego nie zmieniać. W przypadku SSL po migracji to często oszczędza godziny pracy i chroni przed utratą ruchu.
Podsumowanie
Problem SSL po migracji nie jest jedną usterką, tylko zbiorem możliwych konfliktów między certyfikatem, serwerem, DNS, CMS i dodatkowymi usługami. Dlatego naprawa wymaga metody, a nie zgadywania. Zaczynasz od weryfikacji domeny i certyfikatu, potem sprawdzasz chain, przekierowania i mieszane treści, a na końcu czyścisz cache i testujesz najważniejsze procesy użytkownika.
Jeśli temat dotyczy prostej strony wizytówki, problem często da się rozwiązać samodzielnie w kilkadziesiąt minut. Jeżeli jednak mówimy o sklepie, systemie rezerwacji, panelu klienta lub stronie z wieloma integracjami, lepiej nie ryzykować. Niewłaściwa zmiana w SSL po migracji może spowodować nie tylko ostrzeżenie w przeglądarce, ale też utratę zaufania użytkowników i spadek widoczności w wyszukiwarce.
Najważniejsze: nie zatrzymuj się na komunikacie błędu. Zawsze sprawdzaj cały łańcuch: domena, certyfikat, serwer, przekierowania, treść, cache, integracje. Tylko tak znajdziesz prawdziwą przyczynę i unikniesz powrotu problemu.
CTA do kontaktu
Jeśli po migracji Twoja strona nadal pokazuje błąd SSL, ostrzeżenie o bezpieczeństwie albo ładuje się niepewnie tylko na części urządzeń, nie odkładaj naprawy na później. Skontaktuj się z zespołem R99.PL, aby przeprowadzić diagnostykę, ustalić źródło problemu i bezpiecznie przywrócić poprawne działanie strony bez ryzykownych prób na produkcji.
