Błąd certyfikatu SSL oznacza, że przeglądarka nie mogła nawiązać bezpiecznego połączenia, któremu ufa, więc zatrzymuje się i zamiast Twojej strony wyświetla ostrzeżenie. Najczęstsze przyczyny to wygasły certyfikat (NET::ERR_CERT_DATE_INVALID), certyfikat, który nie obejmuje nazwy domeny (ERR_CERT_COMMON_NAME_INVALID), certyfikat, któremu przeglądarka nie ufa (ERR_CERT_AUTHORITY_INVALID), oraz serwer, który wysyła niekompletny łańcuch certyfikatów lub używa przestarzałych ustawień TLS. Niemal wszystkie naprawia się po stronie serwera, a najczęstszemu z nich – wygaśnięciu – można całkowicie zapobiec.
Ten poradnik omawia błędy, które naprawdę widzą odwiedzający, ich przyczyny i sposoby naprawy, wraz z poleceniami, którymi sprawdzisz własną stronę.
Dlaczego przeglądarki blokują stronę
Gdy przeglądarka łączy się przez HTTPS, serwer przedstawia certyfikat. Zanim przeglądarka cokolwiek wyśle, sprawdza trzy rzeczy: czy certyfikat jest w okresie ważności, czy został wystawiony dokładnie dla nazwy hosta z paska adresu i czy prowadzi łańcuchem do urzędu certyfikacji, któremu przeglądarka ufa. Jeśli którykolwiek test nie przejdzie, przeglądarka wyświetla pełnoekranowe ostrzeżenie, np. „Połączenie nie jest prywatne”. Większość odwiedzających w tym momencie rezygnuje. Klienci API i aplikacje w ogóle nie pokazują ostrzeżenia – po prostu odrzucają połączenie, a Twoja integracja przestaje działać.
Przeglądarki nazywają te same problemy różnie. Tak wyglądają najczęstsze błędy w poszczególnych przeglądarkach:
ProblemChrome i EdgeFirefoxWygasł lub jeszcze nie jest ważnyNET::ERR_CERT_DATE_INVALIDSEC_ERROR_EXPIRED_CERTIFICATENiewłaściwa nazwa hostaNET::ERR_CERT_COMMON_NAME_INVALIDSSL_ERROR_BAD_CERT_DOMAINNiezaufany wystawca lub certyfikat samopodpisanyNET::ERR_CERT_AUTHORITY_INVALIDSEC_ERROR_UNKNOWN_ISSUERProblem z protokołem lub szyfremERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCHSSL_ERROR_NO_CYPHER_OVERLAP
Safari w większości tych przypadków pokazuje komunikat „To połączenie nie jest prywatne”, a szczegóły kryją się pod „Pokaż szczegóły”.
Najpierw sam obejrzyj certyfikat
Zanim cokolwiek naprawisz, sprawdź, co serwer faktycznie wysyła. To polecenie pokazuje daty ważności certyfikatu, podmiot i nazwy hostów, które obejmuje:
echo | openssl s_client -connect northwind.shop:443 -servername northwind.shop 2>/dev/null \
| openssl x509 -noout -dates -subject -issuer -ext subjectAltName
Flaga -servername ma znaczenie. Serwery obsługujące kilka stron wybierają certyfikat na podstawie nazwy, o którą prosi klient, a bez niej możesz zobaczyć niewłaściwy. Aby zobaczyć cały łańcuch wysyłany przez serwer, dodaj -showcerts do pierwszego polecenia.
NET::ERR_CERT_DATE_INVALID
Certyfikat jest poza okresem ważności. Niemal zawsze oznacza to, że wygasł. Rzadziej winny jest zegar na komputerze odwiedzającego, przez który ważny certyfikat wygląda na wygasły lub jeszcze nieważny.
Typowe przyczyny po stronie serwera:
Automatyczne odnawianie przestało działać po przeprowadzce serwera, zmianie serwera WWW lub zmianie DNS, która zepsuła walidację domeny.
Certyfikat został odnowiony, ale serwer WWW nie został przeładowany, więc nadal serwuje stary z pamięci.
Certyfikat wystawiono ręcznie rok temu dla subdomeny, o której wszyscy zapomnieli.
Load balancer, CDN lub drugi serwer wciąż ma stary certyfikat, podczas gdy główny serwer ma już nowy.
Rozwiązanie: odnów certyfikat, zainstaluj go wszędzie tam, gdzie jest serwowany, i przeładuj usługę. W Certbocie próbne uruchomienie (dry run) powie Ci, czy odnawianie działa, zanim będzie to miało znaczenie:
sudo certbot renew –dry-run
sudo systemctl reload nginx
Następnie ponownie sprawdź serwowany certyfikat powyższym poleceniem openssl. Odwiedzający nie widzą pliku na dysku, tylko certyfikat, który serwer faktycznie wysyła.
Jeśli błąd zgłasza tylko jeden odwiedzający, a certyfikat jest ważny, poproś go o sprawdzenie daty i godziny na urządzeniu.
NET::ERR_CERT_COMMON_NAME_INVALID
Certyfikat jest ważny, ale nie dla tej nazwy hosta. Przeglądarki porównują adres z paska z nazwami wymienionymi w polu Subject Alternative Name certyfikatu.
Najczęstsze przyczyny:
Certyfikat obejmuje northwind.shop, ale nie www.northwind.shop, lub odwrotnie.
Certyfikat wildcard dla *.northwind.shop jest używany na shop.eu.northwind.shop. Wildcard obejmuje tylko jeden poziom.
Nową subdomenę skierowano na serwer, który serwuje domyślny certyfikat innej strony.
Rekord DNS wskazuje na niewłaściwy serwer, np. starego dostawcę hostingu lub CDN, który nie ma certyfikatu dla Twojej domeny.
Rozwiązanie: wystaw certyfikat obejmujący wszystkie obsługiwane nazwy hostów albo osobny dla każdej z nich i sprawdź, czy każdy blok server lub virtual host używa właściwego. Jeśli dana nazwa hosta w ogóle nie powinna być obsługiwana, usuń jej rekord DNS.
NET::ERR_CERT_AUTHORITY_INVALID
Przeglądarka nie ufa podmiotowi, który podpisał certyfikat. Przyczyny:
Certyfikat samopodpisany, często pozostałość po środowisku staging lub domyślnej instalacji panelu administracyjnego.
Certyfikat z prywatnego lub wewnętrznego urzędu certyfikacji użyty na publicznej stronie.
Niekompletny łańcuch u niektórych klientów – patrz niżej.
Coś między odwiedzającym a serwerem przechwytuje połączenie, np. firmowe proxy lub program antywirusowy. Wtedy błąd widzi tylko część odwiedzających.
Rozwiązanie: na publicznych stronach zastąp certyfikaty samopodpisane i wewnętrzne certyfikatem od publicznie zaufanego urzędu certyfikacji. Darmowym certyfikatom od Let’s Encrypt i podobnych usług ufają wszystkie popularne przeglądarki.
Niekompletny łańcuch certyfikatów
Twój certyfikat jest podpisany przez certyfikat pośredni, a ten przez certyfikat główny, któremu przeglądarka ufa. Serwer musi wysyłać Twój certyfikat i certyfikat pośredni. Jeśli wysyła tylko Twój, wynik zależy od klienta: niektóre przeglądarki desktopowe same pobierają brakujący certyfikat pośredni i nie pokazują błędu, a inne przeglądarki, aplikacje mobilne, curl i klienci API zawodzą. Dlatego ten problem często objawia się jako „u mnie działa, ale webhooki operatora płatności nie dochodzą”.
curl zgłasza go tak:
curl: (60) SSL certificate problem: unable to get local issuer certificate
Rozwiązanie: skonfiguruj serwer z plikiem pełnego łańcucha. W przypadku Certbota i nginx oznacza to fullchain.pem, a nie cert.pem:
ssl_certificate /etc/letsencrypt/live/northwind.shop/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/northwind.shop/privkey.pem;
ERR_SSL_PROTOCOL_ERROR i niezgodność szyfrów
Te błędy oznaczają, że przeglądarka i serwer nie zdołały uzgodnić sposobu bezpiecznej komunikacji, zanim w ogóle doszło do sprawdzenia certyfikatu. Przyczyną może być serwer oferujący tylko stare wersje protokołu, takie jak TLS 1.0 i 1.1, których obecne przeglądarki już nie akceptują, źle skonfigurowany port, który na 443 mówi zwykłym HTTP, zepsuta konfiguracja TLS po aktualizacji albo firewall lub proxy zakłócające handshake.
Rozwiązanie: włącz TLS 1.2 i TLS 1.3, używaj nowoczesnych domyślnych szyfrów swojego serwera WWW lub zaufanego generatora konfiguracji i sprawdź, czy port 443 faktycznie obsługuje TLS. Konkretną wersję protokołu przetestujesz za pomocą openssl:
openssl s_client -connect northwind.shop:443 -servername northwind.shop -tls1_2
Mieszana zawartość (mixed content)
Mieszana zawartość nie jest błędem certyfikatu, ale odwiedzający często tak ją odbierają. Strona ładuje się przez HTTPS, ale część zasobów, takich jak skrypty, obrazy, arkusze stylów czy ramki iframe, jest pobierana przez zwykłe HTTP. Przeglądarki od razu blokują niezabezpieczone skrypty i ramki, co może zepsuć układ lub działanie strony, i mogą wyświetlić stronę bez zwykłego wskaźnika bezpiecznego połączenia.
Rozwiązanie: zmień zakodowane na sztywno adresy http:// w szablonach, bazie danych i ustawieniach na https:// lub adresy względne. W WordPressie mieszana zawartość często pochodzi ze starych adresów zapisanych w treści wpisów po przejściu na HTTPS. Jako zabezpieczenie nagłówek Content-Security-Policy: upgrade-insecure-requests każe przeglądarkom pobierać te zasoby przez HTTPS.
Aby znaleźć mieszaną zawartość, zanim zrobią to odwiedzający, monitorowanie niedziałających linków w Uptimecheck codziennie przeszukuje Twoją stronę i jej mapę witryny, a następnie zgłasza mieszaną zawartość i niedziałające linki strona po stronie.
Jak zapobiegać błędom certyfikatów
Większość błędów certyfikatów to pomyłki w konfiguracji, które naprawiasz raz. Z wygaśnięciem jest inaczej: wraca za każdym razem, gdy certyfikat dobiega końca ważności, i zwykle uderza wtedy, gdy osoba, która ustawiła odnawianie, już dawno zajmuje się czymś innym. Zapobieganie to rutyna, a nie jednorazowa poprawka:
Prowadź spis. Wypisz każdą nazwę hosta obsługującą HTTPS, w tym API, panele administracyjne, staging i strony klientów.
Automatyzuj odnawianie wszędzie, gdzie się da, i wiedz, gdzie wciąż odbywa się ręcznie.
Po każdej zmianie sprawdzaj serwowany certyfikat. To przy przeprowadzkach serwerów, nowych load balancerach i zmianach DNS psuje się odnawianie.
Monitoruj daty wygaśnięcia, by dostać przypomnienie na kilka tygodni przed końcem ważności certyfikatu, gdy jest jeszcze czas spokojnie naprawić nieudane odnowienie.
Pilnuj też domeny i jej rekordów. Wygasła domena lub zmieniony rekord DNS psują walidację, a wraz z nią stronę.
Monitorowanie SSL w Uptimecheck śledzi datę wygaśnięcia certyfikatu serwowanego na każdej domenie i subdomenie, którą monitorujesz przez HTTPS, i wysyła przypomnienia na Twoje kanały alertów, zanim certyfikat wygaśnie. Jest dostępne w każdym planie. Połącz je z monitorowaniem wygaśnięcia domen i monitorowaniem DNS, bo certyfikat jest tak niezawodny jak domena i rekordy, na których się opiera. Nasz poradnik o monitorowaniu wygaśnięcia certyfikatów SSL zawiera pełną listę kontrolną odnawiania, a jeśli przeglądarka w ogóle nie może znaleźć Twojej strony, przeczytaj o błędzie DNS_PROBE_FINISHED_NXDOMAIN.
Podsumowanie
Każdy błąd SSL to przeglądarka, która odmawia zaufania połączeniu: bo certyfikat jest nieaktualny, wystawiony dla innej nazwy, podpisany przez nieznany jej podmiot, wysłany bez łańcucha albo oferowany przez protokół, którego już nie akceptuje. Sprawdź serwowany certyfikat za pomocą openssl, popraw konfigurację, przeładuj serwer i sprawdź ponownie. A potem zamień wygaśnięcie z incydentu w przypomnienie.
Uptimecheck przypomina Ci o zbliżającym się wygaśnięciu certyfikatów i domen oraz alarmuje, gdy Twoja strona przestaje odpowiadać. Wypróbuj za darmo przez 14 dni, bez karty kredytowej.