Błędy certyfikatu SSL: co oznaczają i jak je naprawić

Wygasły certyfikat, brak certyfikatu pośredniego, niezgodna nazwa i stary TLS, czyli najczęstsze ostrzeżenia przeglądarki i ich przyczyny po stronie serwera.

„Twoje połączenie nie jest prywatne” to komunikat, który skutecznie odstrasza odwiedzających. Przeglądarka pokazuje go, gdy nie może potwierdzić, że rozmawia z właściwym serwerem. Dobra wiadomość: przyczyn jest tylko kilka i prawie zawsze da się je naprawić po stronie serwera w kilka minut.

Co sprawdza przeglądarka

Przy każdym połączeniu HTTPS przeglądarka weryfikuje cztery rzeczy:

Łańcuch zaufania. Certyfikat musi być podpisany przez urząd certyfikacji (CA), któremu ufa system lub przeglądarka, zwykle przez certyfikat pośredni.
Nazwa. Domena z paska adresu musi być wpisana w certyfikacie (w polu SAN).
Daty. Certyfikat musi być ważny dzisiaj, czyli już i jeszcze.
Protokół. Serwer musi obsługiwać wersję TLS i szyfry, które przeglądarka akceptuje.

Każdy z błędów poniżej to niespełnienie jednego z tych warunków.

Najczęstsze błędy

Komunikat (Chrome)	Przyczyna	Naprawa
`NET::ERR_CERT_DATE_INVALID`	certyfikat wygasł (albo zegar na komputerze odwiedzającego jest źle ustawiony)	odnów certyfikat i ustaw automatyczne odnawianie
`NET::ERR_CERT_COMMON_NAME_INVALID`	nazwy z paska adresu nie ma w certyfikacie, np. jest `example.com`, a brakuje `www.example.com`	wystaw certyfikat obejmujący wszystkie używane nazwy
`NET::ERR_CERT_AUTHORITY_INVALID`	certyfikat samopodpisany albo serwer nie wysyła certyfikatu pośredniego	użyj certyfikatu z zaufanego CA i skonfiguruj pełny łańcuch
`ERR_SSL_VERSION_OR_CIPHER_MISMATCH`	serwer obsługuje tylko stare wersje TLS lub szyfry	włącz TLS 1.2 i TLS 1.3
kłódka z ostrzeżeniem, „połączenie nie jest w pełni bezpieczne”	mieszana treść: strona po HTTPS ładuje obrazki lub skrypty po HTTP	zmień adresy zasobów na `https://` lub względne

Brakujący certyfikat pośredni

To najbardziej podstępny błąd, bo „u mnie działa”. Chrome i Firefox na komputerze potrafią same dociągnąć brakujący certyfikat pośredni albo mają go w pamięci podręcznej, więc strona otwiera się normalnie. Za to Android, curl, aplikacje mobilne, integracje API i niektóre programy pocztowe zgłaszają błąd zaufania.

Rozwiązanie: serwer musi wysyłać certyfikat domeny razem z certyfikatem pośrednim. Przy Let’s Encrypt i certbocie oznacza to plik fullchain.pem, a nie cert.pem:

# nginx
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

W Apache (od wersji 2.4.8) wskaż ten sam fullchain.pem w SSLCertificateFile. Przy certyfikatach kupionych u innych dostawców doklej certyfikat pośredni (tzw. bundle) za certyfikatem domeny w jednym pliku.

Nazwy w certyfikacie i wildcard

Certyfikat obejmuje dokładnie te nazwy, które ma wpisane. Kilka rzeczy, które często zaskakują:

example.com i www.example.com to dwie różne nazwy i obie muszą być w certyfikacie,
wildcard *.example.com obejmuje www.example.com i sklep.example.com, ale nie samo example.com ani a.b.example.com,
certyfikat wystawiony na adres IP to rzadkość. Na stronę wchodzi się po nazwie domeny.

Wygaśnięcie i automatyczne odnawianie

Certyfikaty Let’s Encrypt są ważne 90 dni, a certbot próbuje je odnowić około 30 dni przed końcem. Gdy odnowienie się nie uda, nikt nie wyśle już przypomnienia, bo Let’s Encrypt w 2025 roku przestał wysyłać e-maile o wygasaniu. Dlatego warto sprawdzić, czy odnawianie naprawdę działa:

systemctl list-timers | grep certbot   # czy zadanie jest zaplanowane
certbot renew --dry-run                # próbne odnowienie

Częsta pułapka: certyfikat odnawia się poprawnie, ale serwer WWW nadal serwuje stary, bo nikt go nie przeładował. Dodaj do certbota hook, np. --deploy-hook "systemctl reload nginx".

Automatyzacja przestaje być opcją także przy płatnych certyfikatach. Zgodnie z decyzją CA/Browser Forum od marca 2026 roku certyfikat może być ważny najwyżej 200 dni, od 2027 roku 100 dni, a od 2029 roku tylko 47 dni. Ręczne odnawianie raz w roku odchodzi w przeszłość.

Gdy winny jest DNS

Czasem certyfikat jest w porządku, tylko domena prowadzi nie tam, gdzie trzeba. Sprawdź w DNS lookup:

rekord AAAA wskazujący stary serwer. Odwiedzający z IPv6 trafiają wtedy na inną maszynę ze starym certyfikatem, a Ty u siebie po IPv4 widzisz wszystko poprawnie,
rekord CAA, który pozwala wystawiać certyfikaty tylko wybranym urzędom. Jeśli zmieniasz dostawcę certyfikatu, dopisz go do CAA, inaczej wystawienie się nie uda,
świeża zmiana rekordów, która jeszcze się nie rozpropagowała. Część odwiedzających widzi stary serwer do czasu wygaśnięcia TTL.

Jak sprawdzić

Narzędzie Sprawdzanie SSL/TLS łączy się z serwerem tak jak przeglądarka i pokazuje certyfikat, cały łańcuch, datę wygaśnięcia oraz obsługiwane wersje protokołu. Z linii poleceń to samo zrobisz poleceniem:

openssl s_client -connect example.com:443 -servername example.com

Parametr -servername jest ważny: na jednym adresie IP często działa wiele stron, a bez niego serwer może zwrócić certyfikat zupełnie innej domeny.

Nie proś odwiedzających, żeby „kliknęli Zaawansowane i przeszli dalej”. To uczy ich ignorowania ostrzeżeń, a przy włączonym HSTS przeglądarka i tak na to nie pozwoli. Napraw certyfikat.