Jak naprawić błąd NET::ERR_CERT_AUTHORITY_INVALID

NET::ERR_CERT_AUTHORITY_INVALID to błąd uzgadniania TLS na poziomie przeglądarki, który występuje, gdy certyfikat przedstawiony przez serwer WWW nie może być powiązany z głównym urzędem certyfikacji (CA) zaufanym przez wbudowany magazyn zaufania przeglądarki. Przeglądarka przerywa połączenie przed wymianą jakichkolwiek danych, wyświetlając ten błąd, aby zapobiec narażeniu na ataki man-in-the-middle (MITM), przechwyceniu danych lub ruchowi z fałszywego serwera.

To nie jest kosmetyczne ostrzeżenie. Jest to poważny błąd weryfikacji kryptograficznej. Przeglądarka sprawdziła łańcuch certyfikatów, próbowała zweryfikować każde ogniwo aż do zaufanego korzenia i stwierdziła, że łańcuch jest przerwany, nieobecny lub kryptograficznie nieprawidłowy. Dokładne zrozumienie, gdzie ten łańcuch się urywa, to różnica między pięciominutową naprawą a godzinami błędnej diagnozy.

Co tak naprawdę wywołuje ten błąd

Większość dokumentacji wymienia przyczyny powierzchowne. Rzeczywisty obraz jest bardziej złożony, a każda przyczyna źródłowa wymaga innej ścieżki naprawy.

Certyfikaty z podpisem własnym

Certyfikat z podpisem własnym to taki, w którym wystawca i podmiot są identyczni — serwer podpisał własny certyfikat zamiast zlecić to zaufanemu CA. Są one standardem w lokalnych środowiskach deweloperskich, wewnętrznych serwerach testowych i prywatnej infrastrukturze. Żaden publiczny magazyn zaufania przeglądarki ich nie rozpoznaje, więc weryfikacja łańcucha natychmiast kończy się niepowodzeniem.

Ważna uwaga: Nawet jeśli dodasz certyfikat z podpisem własnym do magazynu zaufania systemu operacyjnego, niektóre przeglądarki (zwłaszcza Chrome na określonych platformach) używają własnego magazynu certyfikatów i nadal go odrzucą, chyba że zostanie to jawnie skonfigurowane.

Wygasły certyfikat SSL/TLS

Każdy certyfikat zawiera pola `notBefore` i `notAfter` zakodowane w strukturze X.509. Gdy zegar systemowy przekroczy znacznik czasu `notAfter`, certyfikat jest kryptograficznie nieważny niezależnie od sposobu jego wystawienia. Przeglądarki egzekwują to rygorystycznie.

Przypadek brzegowy: Jeśli zegar serwera znacznie wybiega do przodu, certyfikat, który jest technicznie nadal ważny, może wydawać się wygasły dla samego serwera podczas negocjacji uzgadniania TLS, powodując ten błąd po stronie serwera, a nie klienta.

Niekompletny łańcuch certyfikatów (brakujący pośredni CA)

Jest to najczęściej błędnie diagnozowana przyczyna w środowiskach produkcyjnych. Zaufany główny CA nie podpisuje bezpośrednio certyfikatów końcowych. Podpisuje pośrednie CA, które następnie podpisują Twój certyfikat. Podczas instalowania certyfikatu SSL na serwerze musisz zainstalować pełny łańcuch: certyfikat końcowy plus wszystkie certyfikaty pośrednie połączone w odpowiedniej kolejności.

Jeśli pośredni certyfikat nie jest obecny w odpowiedzi TLS serwera, większość przeglądarek nie może ukończyć weryfikacji łańcucha do zaufanego korzenia. Firefox jest tu nieco bardziej wyrozumiały, ponieważ buforuje certyfikaty pośrednie z poprzednich sesji (pobieranie AIA), ale Chrome i Edge zakończą połączenie błędem.

Jak zweryfikować: Uruchom `openssl s_client -connect yourdomain.com:443 -showcerts` i sprawdź, czy zwracany jest pełny łańcuch.

Niezgodność Common Name lub SAN certyfikatu

Jeśli certyfikat został wystawiony dla `www.example.com`, ale użytkownik uzyskuje dostęp do `example.com` (lub subdomeny nieobjętej przez wildcard), przeglądarka zgłosi powiązany, ale odrębny błąd. Jednak w niektórych konfiguracjach objawia się to jako błąd nieprawidłowego urzędu, a nie błąd niezgodności nazwy, szczególnie w przypadku starszych formatów certyfikatów pozbawionych Subject Alternative Names (SAN).

Przesunięcie zegara po stronie klienta

Certyfikaty TLS są ograniczone czasowo. Jeśli zegar komputera klienta jest ustawiony na datę przed polem `notBefore` certyfikatu lub po jego polu `notAfter`, przeglądarka go odrzuci. Jest to niezwykle powszechne na maszynach wirtualnych, świeżo wdrożonych serwerach lub maszynach, które były wyłączone przez dłuższy czas bez synchronizacji NTP.

Inspekcja SSL przez oprogramowanie zabezpieczające

Firmowe zapory sieciowe, pakiety zabezpieczeń punktów końcowych i niektóre produkty antywirusowe wykonują inspekcję SSL/TLS (zwaną również przechwytywaniem HTTPS). Kończą połączenie TLS na urządzeniu zabezpieczającym, sprawdzają tekst jawny, a następnie ponownie go szyfrują przy użyciu dynamicznie generowanego certyfikatu podpisanego przez własny CA urządzenia. Jeśli ten CA urządzenia nie znajduje się w magazynie zaufania przeglądarki, każda witryna HTTPS wywoła ten błąd.

Przestarzały magazyn certyfikatów głównych

W starszych systemach operacyjnych (Windows 7 bez aktualizacji, starsze dystrybucje Linux) pakiet głównych CA systemu może nie zawierać nowszych certyfikatów głównych. Na przykład ISRG Root X1 Let’s Encrypt spowodował powszechne błędy na Androidzie 7 i starszych oraz na niezałatanych systemach Windows, gdy wygasł podpis krzyżowy DST Root CA X3 we wrześniu 2021 roku.

Porównanie przyczyn źródłowych

Naprawy krok po kroku

Krok 1: Synchronizacja daty i godziny systemowej

Jest to najszybsza naprawa, gdy błąd pojawia się nagle na komputerze, który wcześniej działał prawidłowo.

Windows:

1. Otwórz Ustawienia > Czas i język > Data i godzina.
2. Włącz Ustaw czas automatycznie i Ustaw strefę czasową automatycznie.
3. Kliknij Synchronizuj teraz w sekcji „Synchronizuj zegar”.
4. Jeśli automatyczna synchronizacja nie powiedzie się, otwórz Wiersz polecenia jako Administrator i uruchom: `w32tm /resync /force`

macOS:

1. Otwórz Ustawienia systemowe > Ogólne > Data i godzina.
2. Włącz Ustaw datę i godzinę automatycznie i wybierz pobliski serwer NTP (np. `time.apple.com`).
3. Jeśli problem nadal występuje, uruchom w Terminalu: `sudo sntp -sS time.apple.com`

Linux (serwer lub komputer stacjonarny):

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

Po synchronizacji uruchom ponownie przeglądarkę i spróbuj ponownie.

Krok 2: Wyczyszczenie pamięci podręcznej przeglądarki, plików cookie i buforowanych certyfikatów

Przeglądarki buforują zasady HSTS (HTTP Strict Transport Security) i dane certyfikatów. Nieaktualna pozycja w pamięci podręcznej może podtrzymywać błąd nawet po rozwiązaniu podstawowego problemu.

Google Chrome:

1. Przejdź do `chrome://settings/clearBrowserData`.
2. Ustaw zakres czasu na Cały czas.
3. Zaznacz Pliki cookie i inne dane witryn oraz Obrazy i pliki w pamięci podręcznej.
4. Kliknij Wyczyść dane.

Aby wyczyścić pamięć podręczną specyficzną dla HSTS w Chrome, przejdź do `chrome://net-internals/#hsts`, wprowadź domenę w sekcji „Usuń zasady bezpieczeństwa domeny” i kliknij Usuń.

Mozilla Firefox:

1. Otwórz Ustawienia > Prywatność i bezpieczeństwo.
2. W sekcji Pliki cookie i dane witryn kliknij Wyczyść dane.
3. Wyczyść również Buforowaną zawartość sieci Web.

Microsoft Edge:

1. Przejdź do `edge://settings/clearBrowserData`.
2. Wybierz Cały czas i wyczyść buforowane dane oraz pliki cookie.

Krok 3: Identyfikacja i wyłączenie inspekcji SSL

Jeśli korzystasz z sieci firmowej lub używasz produktu zabezpieczającego punkty końcowe, inspekcja SSL jest głównym podejrzanym.

1. Kliknij ikonę kłódki (lub ikonę ostrzeżenia) na pasku adresu przeglądarki.
2. Sprawdź szczegóły certyfikatu. Jeśli wystawcą jest Twój dostawca oprogramowania antywirusowego (np. „Avast Root”, „Kaspersky Anti-Virus”, „ESET SSL Filter CA”), a nie publiczny CA jak DigiCert, Let’s Encrypt lub Sectigo, inspekcja SSL jest aktywna.
3. W ustawieniach programu antywirusowego lub zapory sieciowej znajdź opcję Skanowanie HTTPS, Filtrowanie SSL lub Web Shield i wyłącz ją.
4. Alternatywnie dodaj certyfikat główny CA urządzenia do magazynu zaufania przeglądarki.

Nie wyłączaj trwale oprogramowania zabezpieczającego. Włącz je ponownie po testowaniu lub skonfiguruj tak, aby wykluczało określone zaufane domeny.

Krok 4: Weryfikacja i naprawa łańcucha certyfikatów po stronie serwera (administratorzy serwerów)

Jest to właściwa naprawa dla witryn produkcyjnych, gdzie odwiedzający widzą błąd.

Diagnozowanie łańcucha:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Issuer:|Subject:"

“`

Lub użyj pełnej inspekcji łańcucha:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts

“`

Policz zwrócone certyfikaty. Powinieneś zobaczyć co najmniej dwa (certyfikat końcowy + pośredni). Jeśli pojawia się tylko jeden, brakuje certyfikatu pośredniego.

Naprawa w Apache (`httpd.conf` lub plik wirtualnego hosta):

“`apache

SSLCertificateFile /etc/ssl/certs/yourdomain.crt

SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

“`

Naprawa w Nginx (`nginx.conf` lub blok serwera):

Nginx wymaga połączenia pełnego łańcucha w jeden plik:

“`bash

cat yourdomain.crt intermediate.crt > fullchain.pem

“`

Następnie odwołaj się do niego:

“`nginx

ssl_certificate /etc/ssl/certs/fullchain.pem;

ssl_certificate_key /etc/ssl/private/yourdomain.key;

“`

Po edycji zawsze testuj konfigurację przed ponownym uruchomieniem:

“`bash

Apache

apachectl configtest

Nginx

nginx -t

“`

Następnie przeładuj usługę:

“`bash

sudo systemctl reload apache2

or

sudo systemctl reload nginx

“`

Jeśli korzystasz ze środowiska zarządzanego, VPS z cPanel zapewnia interfejs GUI w sekcji Menedżer SSL/TLS, gdzie możesz wkleić certyfikat, klucz prywatny i pakiet CA bezpośrednio bez ręcznego modyfikowania plików konfiguracyjnych.

Krok 5: Odnowienie lub zastąpienie wygasłego certyfikatu

Jeśli certyfikat wygasł, nie ma obejścia po stronie klienta. Serwer musi przedstawić ważny certyfikat.

Dla Let’s Encrypt (Certbot):

“`bash

sudo certbot renew –dry-run

sudo certbot renew

sudo systemctl reload nginx # or apache2

“`

Dla ręcznie zarządzanych certyfikatów: Uzyskaj nowy certyfikat od swojego CA, prześlij go za pośrednictwem panelu sterowania i upewnij się, że łańcuch nowego certyfikatu jest kompletny. Jeśli potrzebujesz zaufanego certyfikatu dla domeny produkcyjnej, certyfikaty SSL od uznanego CA całkowicie eliminują problem certyfikatów z podpisem własnym.

Automatyzacja odnowień: Certyfikaty Let’s Encrypt wygasają co 90 dni. Dodaj zadanie cron lub użyj timerów systemd, aby zautomatyzować odnowienie:

“`bash

0 3 * * * /usr/bin/certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Krok 6: Zaufanie certyfikatowi z podpisem własnym do użytku wewnętrznego

Jeśli korzystasz z wewnętrznych narzędzi, serwera deweloperskiego lub prywatnej usługi sieciowej, gdzie zastąpienie certyfikatu nie jest możliwe, możesz dodać certyfikat z podpisem własnym do magazynu zaufania systemu operacyjnego.

Windows:

1. Wyeksportuj certyfikat z przeglądarki (kliknij ostrzeżenie > Certyfikat > Szczegóły > Kopiuj do pliku).
2. Otwórz `certmgr.msc`.
3. Przejdź do Zaufane główne urzędy certyfikacji > Certyfikaty.
4. Kliknij prawym przyciskiem myszy > Wszystkie zadania > Importuj i zaimportuj certyfikat.

macOS:

“`bash

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.crt

“`

Linux (Debian/Ubuntu):

“`bash

sudo cp cert.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

“`

Ważne: Chrome na Linux i Windows używa magazynu zaufania systemu operacyjnego do większości celów, ale utrzymuje również własną bazę danych NSS. Jeśli Chrome nadal odrzuca certyfikat po zaktualizowaniu magazynu systemu operacyjnego, zaimportuj go bezpośrednio przez `chrome://settings/certificates`.

Krok 7: Aktualizacja przeglądarki i systemu operacyjnego

Przestarzała przeglądarka może nie posiadać nowszych certyfikatów głównych CA lub może nie obsługiwać aktualnych wersji protokołu TLS (wymagane jest minimum TLS 1.2; preferowane jest TLS 1.3).

Chrome: Przejdź do `chrome://settings/help`. Chrome aktualizuje się automatycznie; jeśli aktualizacja jest oczekująca, zostanie zainstalowana tutaj.

Firefox: Przejdź do Pomoc > O programie Firefox. Firefox sprawdzi i zastosuje aktualizacje.

System operacyjny: W systemie Windows upewnij się, że Windows Update jest aktualny. Na serwerach Linux uruchom:

“`bash

sudo apt update && sudo apt upgrade ca-certificates openssl

“`

Jest to szczególnie ważne dla serwerów z starszymi dystrybucjami, gdzie pakiet CA (`ca-certificates`) nie został zaktualizowany o nowsze główne CA.

Krok 8: Resetowanie stosu sieciowego i czyszczenie DNS

Błędne konfiguracje na poziomie sieci, uszkodzone pamięci podręczne DNS lub nieaktualne wpisy Winsock mogą czasami przyczyniać się do błędów negocjacji TLS.

Windows (uruchom Wiersz polecenia jako Administrator):

“`cmd

netsh int ip reset

netsh winsock reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

“`

Uruchom ponownie komputer po wykonaniu tych poleceń.

macOS:

“`bash

sudo dscacheutil -flushcache

sudo killall -HUP mDNSResponder

“`

Linux:

“`bash

sudo systemd-resolve –flush-caches

or for systems using nscd:

sudo service nscd restart

“`

Krok 9: Pominięcie ostrzeżenia (tylko do testów)

Jest to wyłącznie narzędzie diagnostyczne, a nie rozwiązanie. Używaj go tylko w celu potwierdzenia, że błąd jest związany z certyfikatem, a nie z siecią lub aplikacją, lub podczas uzyskiwania dostępu do znanego bezpiecznego serwera wewnętrznego w trakcie programowania.

Chrome: Kliknij Zaawansowane na stronie błędu, a następnie Przejdź do [domeny] (niebezpieczne).

Firefox: Kliknij Zaawansowane, a następnie Zaakceptuj ryzyko i kontynuuj.

Nigdy nie pomijaj tego ostrzeżenia na witrynach obsługujących uwierzytelnianie, płatności lub dane osobowe. Ostrzeżenie istnieje, ponieważ połączenie jest naprawdę niezweryfikowane.

Weryfikacja naprawy

Po zastosowaniu jakiejkolwiek zmiany po stronie serwera zweryfikuj wynik za pomocą tych narzędzi przed ogłoszeniem rozwiązania problemu:

• SSL Labs SSL Test (`ssllabs.com/ssltest/`): Zapewnia pełną analizę łańcucha, ocenę obsługi protokołu i identyfikuje konkretne słabości konfiguracji.
• `openssl s_client`: Weryfikacja wiersza poleceń pokazująca dokładnie to, co serwer prezentuje podczas uzgadniania TLS.
• `curl -vI https://yourdomain.com`: Szybkie sprawdzenie pokazujące szczegóły uzgadniania TLS i wynik weryfikacji certyfikatu.
• `whatsmychaincert.com`: Specjalnie diagnozuje brakujące certyfikaty pośrednie.

Wybór odpowiedniej infrastruktury hostingowej, aby zapobiec ponownemu wystąpieniu problemu

Wiele błędów certyfikatów wynika z ograniczeń infrastruktury, a nie błędów administratora. Środowiska hostingu współdzielonego czasami ograniczają sposób konfigurowania łańcuchów certyfikatów lub ograniczają dostęp do plików konfiguracyjnych serwera WWW. Jeśli wielokrotnie napotykasz problemy z łańcuchem lub odnowieniem, migracja do środowiska Hostingu VPS daje pełną kontrolę nad stosem TLS — w tym możliwość bezpośredniej konfiguracji Nginx lub Apache, automatyzacji odnowień Certbot i instalowania niestandardowych pakietów CA.

W przypadku obciążeń o dużym ruchu lub wymagających zgodności, gdzie zarządzanie certyfikatami jest krytyczne, Serwery dedykowane eliminują zmienne środowisk wielodostępnych, które mogą komplikować konfigurację SSL. Jeśli zarządzasz wieloma domenami lub subdomenami, Panel sterowania VPS upraszcza wdrażanie certyfikatów dla wszystkich z nich z jednego interfejsu.

Macierz decyzyjna: Która naprawa dotyczy Twojej sytuacji

Praktyczna lista kontrolna kluczowych wniosków

• Przed podjęciem jakichkolwiek działań potwierdź, czy błąd jest po stronie klienta (zegar, pamięć podręczna, inspekcja SSL) czy po stronie serwera (wygasły certyfikat, brakujący certyfikat pośredni).
• Uruchom `openssl s_client -connect domain:443 -showcerts` jako pierwszy krok diagnostyczny w każdym dochodzeniu po stronie serwera.
• Zawsze łącz pełny łańcuch certyfikatów (certyfikat końcowy + wszystkie certyfikaty pośrednie) w konfiguracji serwera WWW.
• Automatyzuj odnowienie certyfikatów za pomocą zadań cron Certbot lub odpowiednika — ręczne odnawianie to gwarantowana droga do przyszłych awarii.
• Po każdej zmianie certyfikatu zweryfikuj wynik za pomocą SSL Labs przed zamknięciem incydentu.
• Nigdy trwale nie wyłączaj skanowania SSL przez oprogramowanie antywirusowe; zamiast tego skonfiguruj wykluczenia lub prawidłowo zainstaluj certyfikat CA proxy.
• Na serwerach Linux aktualizuj pakiety `ca-certificates` i `openssl`, aby magazyn główny odzwierciedlał aktualne zaufane CA.
• Używaj `chrome://net-internals/#hsts` do czyszczenia wpisów pamięci podręcznej HSTS, gdy certyfikat domeny został legalnie zmieniony, a Chrome nadal odmawia połączenia.

Często zadawane pytania

Jaka jest różnica między NET::ERR_CERT_AUTHORITY_INVALID a NET::ERR_CERT_COMMON_NAME_INVALID?

`ERR_CERT_AUTHORITY_INVALID` oznacza, że wystawca certyfikatu nie jest zaufany — łańcuch nie może być zweryfikowany. `ERR_CERT_COMMON_NAME_INVALID` oznacza, że certyfikat pochodzi od zaufanego CA, ale został wystawiony dla innej domeny niż ta, do której uzyskiwany jest dostęp. Wymagają różnych napraw: pierwsza wymaga nowego certyfikatu od zaufanego CA lub naprawy łańcucha; druga wymaga certyfikatu ponownie wystawionego z poprawnymi Subject Alternative Names.

Czy NET::ERR_CERT_AUTHORITY_INVALID może pojawić się nawet przy ważnym, płatnym certyfikacie SSL?

Tak. Płatny certyfikat od zaufanego CA nadal wywoła ten błąd, jeśli certyfikat pośredni nie jest zawarty w odpowiedzi TLS serwera. Przeglądarka nie zawsze może automatycznie pobrać brakujące certyfikaty pośrednie (pobieranie AIA jest zawodne), więc łańcuch musi być jawnie skonfigurowany na serwerze.

Dlaczego ten błąd pojawia się tylko w Chrome, ale nie w Firefox?

Firefox utrzymuje własny magazyn zaufania certyfikatów i buforuje również certyfikaty pośrednie z poprzednich udanych połączeń (mechanizm zwany pobieraniem AIA z buforowaniem). Chrome opiera się bardziej rygorystycznie na magazynie zaufania systemu operacyjnego i łańcuchu przedstawionym przez serwer. Brakujący certyfikat pośredni, który Firefox zbuforował z poprzedniej sesji, nadal spowoduje błąd w Chrome.

Czy bezpieczne jest kliknięcie „Kontynuuj mimo to” przy ostrzeżeniu NET::ERR_CERT_AUTHORITY_INVALID?

Tylko w kontrolowanych scenariuszach: dostęp do znanego serwera wewnętrznego, lokalnego środowiska deweloperskiego lub serwera testowego, którym administrujesz. Na każdej publicznej witrynie — zwłaszcza wymagającej danych logowania, informacji o płatnościach lub danych osobowych — kontynuowanie jest naprawdę niebezpieczne. Połączenie jest niezaszyfrowane z perspektywy zaufania, co oznacza, że każdy przechwytujący na ścieżce sieciowej może odczytać lub zmodyfikować ruch.

Jak zapobiec ponownemu wystąpieniu tego błędu na moim serwerze produkcyjnym?

Automatyzuj odnowienie certyfikatów (Certbot z zadaniem cron lub timerem systemd), monitoruj wygaśnięcie certyfikatów za pomocą zewnętrznego narzędzia (UptimeRobot, Zabbix lub `ssl-cert-check`), zawsze wdrażaj pełny łańcuch certyfikatów i utrzymuj aktywną synchronizację NTP serwera. W środowiskach, gdzie ręczne zarządzanie jest podatne na błędy, rozważ platformę hostingową ze zintegrowanym zarządzaniem certyfikatami — VPS z cPanel obsługuje automatyczne odnowienia AutoSSL dla wszystkich hostowanych domen.