Przeglądarka może odrzucić HTTPS nawet wtedy, gdy certyfikat jest ważny czasowo i został wystawiony przez zaufane CA. Wystarczy, że nie obejmuje nazwy hosta, którą użytkownik otworzył, albo serwer przedstawia certyfikat należący do innej witryny.
Po migracji często wychodzi to przy różnicy między domeną główną i www, zmianie vhosta, konfiguracji reverse proxy albo sytuacji, w której część ruchu trafia jeszcze na poprzedni serwer.
Przy błędzie certyfikatu najpierw sprawdź, jaki certyfikat serwer naprawdę przedstawia dla konkretnego hosta. Dopiero potem diagnozuj WordPressa, DNS albo CDN.
Certyfikat musi obejmować właściwą nazwę i być ważny
SAN i nazwa hosta
Współczesna weryfikacja nazwy hosta opiera się na wpisach dNSName w rozszerzeniu Subject Alternative Name (SAN). Common Name może nadal być widoczny w certyfikacie, ale nie powinien być używany jako źródło nazwy hosta przy takiej weryfikacji.
W SAN mogą znajdować się na przykład:
example.pl,www.example.pl,shop.example.pl.
Certyfikat dla example.pl nie obejmuje automatycznie www.example.pl. Jeżeli przeglądarka łączy się z nazwą, której nie ma w odpowiednim dNSName, połączenie może zostać odrzucone jako hostname mismatch.
Wildcard obejmuje tylko określony zakres nazw
Certyfikat *.example.pl może obejmować np. www.example.pl i shop.example.pl, ale nie obejmuje samego example.pl ani nazw wielopoziomowych typu panel.shop.example.pl.
Jeśli potrzebne są także te hosty, trzeba uwzględnić je osobno w SAN albo zastosować odpowiednio dobrane certyfikaty. Wildcard jest traktowany jako cała najbardziej lewa etykieta nazwy, więc nie zastępuje dowolnej liczby poziomów subdomen.
Okres ważności i łańcuch certyfikatów
Hostname mismatch i certyfikat po terminie to dwa różne błędy. Certyfikat może obejmować właściwą nazwę, ale zostać odrzucony, jeśli jego okres ważności się skończył albo jeszcze się nie rozpoczął.
Przy kontroli sprawdź osobno:
- nazwy SAN,
notBefore,notAfter,- wystawcę,
- czy serwer przedstawia pełny właściwy łańcuch.
| Objaw | Co sprawdzić najpierw |
|---|---|
Działa example.pl, ale nie www.example.pl | Czy oba hosty znajdują się w SAN |
| Przeglądarka pokazuje certyfikat zupełnie innej domeny | Vhost, SNI, IP docelowy i konfigurację serwera |
| Problem pojawił się po migracji | DNS, nowy serwer, certyfikat i moment przełączenia ruchu |
| Za Cloudflare działa inaczej niż bez proxy | Certyfikat edge, origin certificate i tryb SSL/TLS |
Jeżeli widzisz certyfikat innej domeny, sprawdź vhost i SNI
Na jednym adresie IP może działać wiele stron HTTPS. Serwer wykorzystuje nazwę przesłaną przez klienta w mechanizmie SNI, aby wybrać właściwy virtual host i odpowiedni certyfikat.
Jeżeli konfiguracja vhosta jest błędna, serwer może zwrócić certyfikat domyślnej lub zupełnie innej witryny. Wtedy problem nie polega na tym, że certyfikat „jest zepsuty” — serwer po prostu prezentuje niewłaściwy certyfikat dla danego hosta.
To szczególnie częsty trop, gdy:
- kilka domen korzysta z tego samego IP,
- nowa domena została dodana do hostingu, ale nie do właściwego vhosta,
- certyfikat został wystawiony, lecz nie przypięto go do docelowej konfiguracji,
- po migracji część konfiguracji nadal wskazuje stary host.
SNI pozwala serwerowi prezentować różne certyfikaty zależnie od nazwy hosta, mimo wspólnego adresu IP.
Po migracji sprawdź, czy ruch naprawdę trafia do nowego serwera
Można poprawnie zainstalować nowy certyfikat, a mimo to część użytkowników nadal będzie widzieć certyfikat poprzedniego hostingu. Wystarczy, że ich resolver DNS nadal kieruje domenę na stary adres IP.
Dlatego po zmianie hostingu warto porównać:
- aktualny rekord
AiAAAA, - adres IP serwera, który odpowiada na HTTPS,
- certyfikat prezentowany przez stary i nowy origin,
- czy
wwwi domena główna trafiają w to samo miejsce.
Jeżeli nowy serwer ma poprawny certyfikat, a stary nadal przedstawia inny, rozbieżność może być widoczna tylko dla części użytkowników do czasu wygaśnięcia cache DNS.
Przy problemach z rozwiązywaniem nazw warto najpierw sprawdzić diagnostykę NXDOMAIN i DNS, zamiast ponownie wystawiać certyfikat bez potwierdzenia, do którego serwera trafia ruch.
Cloudflare dodaje drugą warstwę certyfikatów
Przy aktywnym proxy Cloudflare użytkownik nie łączy się bezpośrednio z originem. Powstają dwa osobne połączenia TLS:
- użytkownik ↔ Cloudflare,
- Cloudflare ↔ origin.
To oznacza, że certyfikat widoczny w przeglądarce i certyfikat zainstalowany na serwerze źródłowym mogą być różne.
W trybie Full (strict) Cloudflare weryfikuje certyfikat originu. Błąd 526 może pojawić się m.in. przy certyfikacie wygasłym, niezaufanym, niedopasowanym do hosta albo przy nieprawidłowym łańcuchu certyfikatów.
Cloudflare Origin CA jest przeznaczony do połączenia Cloudflare → origin. Taki certyfikat nie musi być zaufany bezpośrednio przez przeglądarkę. Dlatego po wyłączeniu proxy lub bezpośrednim wejściu na origin przeglądarka może zgłosić błąd certyfikatu mimo poprawnego działania w Full (strict).
Przy diagnozie trzeba więc najpierw odpowiedzieć na pytanie: problem występuje między użytkownikiem a Cloudflare czy między Cloudflare a originem?
Nie naprawiaj błędu przez wyłączenie HTTPS
Jeżeli strona działa po HTTP, a HTTPS pokazuje błąd certyfikatu, cofnięcie całej witryny do HTTP usuwa tylko objaw. Nie rozwiązuje złej konfiguracji certyfikatu, DNS albo vhosta.
Podobnie nie warto dodawać kolejnych przekierowań HTTPS, dopóki nie wiadomo, czy docelowy host ma już prawidłowo działający TLS.
Jeżeli równocześnie pojawia się pętla przekierowań, najpierw sprawdź poradnik ERR_TOO_MANY_REDIRECTS w WordPressie. Przy Mixed Content problem jest już inny — TLS działa, ale część zasobów nadal ładuje się po HTTP.
Bezpieczna procedura diagnozy błędu certyfikatu
- Zapisz dokładny hostname. Domena główna, www czy subdomena?
- Sprawdź, jaki certyfikat jest faktycznie prezentowany.
- Porównaj hostname z listą SAN.
- Sprawdź okres ważności i łańcuch certyfikatów.
- Jeżeli certyfikat należy do innej domeny, sprawdź vhost, SNI i docelowy IP.
- Po migracji porównaj odpowiedź starego i nowego originu.
- Jeżeli używasz Cloudflare, rozdziel certyfikat edge od certyfikatu originu.
- Jeżeli origin używa Cloudflare Origin CA, nie oceniaj go jak publicznego certyfikatu dla bezpośredniego wejścia z przeglądarki.
- Nie wyłączaj HTTPS ani nie dodawaj redirectów, zanim nie ustalisz źródła błędu.
Przy zgłoszeniu do hostingu warto podać dokładny hostname, adres IP serwera, nazwę prezentowanego certyfikatu i komunikat przeglądarki. To znacznie bardziej użyteczne niż samo „SSL nie działa”.
Najważniejsze wnioski
- ważny certyfikat nadal może być odrzucony, jeśli nie obejmuje otwieranej nazwy hosta;
- weryfikacja nazwy hosta opiera się na
dNSNamew SAN, a nie na Common Name; *.example.plnie obejmuje samegoexample.plani wielopoziomowej nazwy typua.b.example.pl;- certyfikat innej domeny zwykle kieruje uwagę na vhost, SNI albo niewłaściwy origin;
- po migracji część użytkowników może nadal trafiać na poprzedni serwer;
- Cloudflare może używać innego certyfikatu na edge i innego na originie;
- Cloudflare Origin CA nie musi być zaufany bezpośrednio przez przeglądarkę;
- w Full (strict) problem z certyfikatem originu może skutkować błędem 526;
- hostname mismatch, wygaśnięcie certyfikatu i redirect loop to różne problemy;
- naprawa powinna zaczynać się od ustalenia, jaki certyfikat jest rzeczywiście prezentowany dla konkretnej nazwy.
Źródła
- RFC 9525 — Service Identity in TLS — weryfikacja nazw przez
dNSNamew SAN, Common Name i wildcardy. - Let’s Encrypt — Glossary — SAN, SNI i podstawowe pojęcia TLS.
- Cloudflare — Full (strict) — wymagania wobec certyfikatu originu.
- Cloudflare — Error 526 — przyczyny błędu walidacji certyfikatu originu.
- Cloudflare — Origin CA troubleshooting — zachowanie Origin CA przy bezpośrednim dostępie do originu.