SSL/TLS działa przed WordPressem. Jeżeli przeglądarka nie potrafi poprawnie ustanowić szyfrowanego połączenia, edycja wtyczek lub bazy zwykle nie ma sensu. Trzeba sprawdzić certyfikat, domenę, serwer, DNS i ewentualne proxy/CDN. Dopiero gdy HTTPS działa poprawnie na poziomie infrastruktury, wracamy do mixed content i przekierowań w aplikacji.
Szybka odpowiedź
Sprawdź datę ważności certyfikatu, nazwy domen zapisane w SAN, wystawcę i pełny łańcuch certyfikatów. Następnie upewnij się, że DNS prowadzi do właściwego serwera i że vhost dla danej domeny rzeczywiście serwuje właściwy certyfikat. Jeśli używasz CDN, osobno zweryfikuj certyfikat na edge i połączenie CDN→origin.
Certyfikat dla złej domeny
Certyfikat dla example.pl nie zawsze obejmuje www.example.pl, a wildcard *.example.pl nie obejmuje samej domeny głównej. Po dodaniu nowego subdomenowego stagingu lub zmianie wariantu www trzeba sprawdzić, czy certyfikat ma właściwe SAN-y. Przeglądarka porównuje nazwę hosta z certyfikatem, a nie z ustawieniami WordPressa.
Wygaśnięcie i automatyczne odnowienie
Let’s Encrypt i podobne mechanizmy odnawiają certyfikaty automatycznie tylko wtedy, gdy proces ma dostęp do wymaganej metody walidacji i poprawnie przeładowuje serwer. Monitoruj datę ważności, bo „mamy automatyczne SSL” nie gwarantuje, że odnowienie zawsze się powiedzie. DNS, firewall lub zmiana konfiguracji mogą zablokować kolejne wydanie.
Niepełny chain
Serwer powinien wysyłać certyfikat witryny wraz z wymaganymi certyfikatami pośrednimi. Błędny łańcuch może działać na jednym urządzeniu i zawodzić na innym. Testuj pełną konfigurację TLS, nie tylko to, czy certyfikat istnieje w katalogu na serwerze.
SNI i wiele domen na jednym IP
Na jednym adresie IP może działać wiele witryn HTTPS. Serwer wybiera certyfikat na podstawie nazwy hosta przekazanej w SNI. Błędny vhost lub konfiguracja domyślna może spowodować, że użytkownik dostanie certyfikat innej strony. To problem konfiguracji serwera, nie WordPressa.
HTTPS działa, ale WordPress nadal generuje HTTP
To już osobny etap. Po naprawie TLS sprawdź home/siteurl, reverse proxy i mixed content. Nie mieszaj obu diagnoz: „certyfikat nieważny” i „strona ładuje obraz po HTTP” to dwa różne problemy, choć użytkownik oba opisze jako „coś z kłódką”.
Jak potwierdzić, że naprawa naprawdę działa?
Po naprawie certyfikatu przetestuj domenę główną, www oraz używane subdomeny. Sprawdź, czy serwer wysyła pełny chain i czy certyfikat ma właściwe SAN-y. Jeżeli certyfikat jest odnawiany automatycznie, uruchom test odnowienia lub sprawdź log ostatniego procesu ACME. Sama data ważności za dwa miesiące nie potwierdza, że następne odnowienie się powiedzie.
Co obserwować po zmianie?
Monitoruj termin ważności niezależnie od automatyki wystawcy. Dodatkowo sprawdź, czy restart/reload Nginx lub Apache po odnowieniu jest częścią procesu. Zdarza się, że nowy certyfikat znajduje się na dysku, ale serwer nadal trzyma w pamięci stary. Przy CDN kontroluj osobno certyfikat edge oraz połączenie do originu.
Kiedy przekazać temat dalej?
Eskaluj, jeśli przeglądarki pokazują różne certyfikaty dla tej samej domeny, błąd dotyczy tylko części sieci albo serwer obsługuje wiele domen i SNI. To często problem infrastruktury lub DNS, którego nie da się rozwiązać z poziomu panelu WordPressa.
Praktyczny scenariusz diagnostyczny
Praktyczny przypadek: przeglądarka zgłasza błąd certyfikatu tylko dla www, podczas gdy domena bez www działa. To nie jest problem WordPressa, lecz pokrycia nazw w certyfikacie lub konfiguracji vhostu. Sprawdź SAN-y certyfikatu, DNS obu hostów i to, który serwer odpowiada dla każdego wariantu. Jeśli używasz CDN, porównaj certyfikat na edge z certyfikatem origin. Następnie ustaw jeden kanoniczny host i bezpieczne przekierowanie z pozostałych wariantów. Po wdrożeniu przetestuj domenę główną, www, HTTP→HTTPS i datę ważności. WordPress może dodatkowo generować złe URL-e, ale najpierw trzeba rozdzielić problem TLS od problemu adresów aplikacji — inaczej łatwo poprawiać niewłaściwą warstwę.
Bezpieczna kolejność działań
- Sprawdź certyfikat i nazwy SAN dla konkretnej domeny.
- Zweryfikuj DNS i właściwy vhost/SNI.
- Sprawdź pełny łańcuch certyfikatów oraz datę ważności.
- Jeśli jest CDN, przetestuj edge i origin osobno.
- Po naprawie TLS sprawdź redirect HTTP→HTTPS i mixed content.
- Włącz monitoring terminu ważności certyfikatu.
Czego nie robić
Nie instaluj „wtyczki SSL” w ciemno, jeśli przeglądarka odrzuca sam certyfikat. Plugin działa dopiero po uruchomieniu PHP, a błąd TLS pojawia się wcześniej. Nie wyłączaj weryfikacji certyfikatu w integracjach tylko po to, aby komunikacja zaczęła działać.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
HeatLogic może sprawdzić certyfikat, DNS, vhost, SNI, reverse proxy i automatyczne odnowienie, a następnie uporządkować warstwę WordPressa tak, aby HTTPS działał spójnie na całej stronie.
Najczęściej zadawane pytania
Czy WordPress wystawia certyfikat SSL?
Nie. Certyfikat jest obsługiwany przez serwer, hosting lub CDN. WordPress korzysta później z działającego HTTPS.
Czy wygaśnięty certyfikat zatrzyma stronę?
Serwer może nadal odpowiadać, ale przeglądarki pokażą poważne ostrzeżenie i użytkownicy mogą nie wejść na witrynę.
Czy certyfikat wildcard obejmuje domenę główną?
Nie zawsze. Wildcard dla `*.example.pl` nie zastępuje automatycznie wpisu dla `example.pl`.
Czy po naprawie SSL trzeba zmieniać bazę WordPressa?
Tylko jeśli aplikacja nadal ma stare adresy HTTP lub złą domenę. Sam błąd certyfikatu nie jest naprawiany w bazie.