ERR_CERT_AUTHORITY_INVALID: jak naprawić (Chrome, Android)

Czym jest NET::ERR_CERT_AUTHORITY_INVALID?

NET::ERR_CERT_AUTHORITY_INVALID oznacza, że przeglądarka nie ufa temu, kto wystawił certyfikat witryny. Chrome pokazuje „Połączenie nie jest prywatne”, a w sekcji Zaawansowane pisze, że serwer „nie może udowodnić, że należy do domeny example.com”, bo jego certyfikat bezpieczeństwa nie jest zaufany, co „może wynikać z błędnej konfiguracji lub przechwycenia połączenia”. Chromium zapisuje to jako błąd -202 (net_error_list.h).

Połączenie zostało nawiązane, serwer wysłał certyfikat, a przeglądarka nie potrafiła powiązać go z urzędem certyfikacji (CA), któremu ufa. Notatki samego Chromium podają trzy powody: atakujący podmienił certyfikat, witryna używa urzędu CA nieznanego przeglądarce albo certyfikat jest samopodpisany.

Jeśli certyfikat ma kilka problemów, Chrome pokazuje tylko najpoważniejszy, a niezaufany wystawca ma pierwszeństwo przed błędną nazwą lub przeterminowaną datą. Dlatego certyfikat samopodpisany, który dodatkowo wygasł, pokazuje ten kod, a nie ERR_CERT_DATE_INVALID.

Jak ERR_CERT_AUTHORITY_INVALID wygląda w różnych przeglądarkach

Każda przeglądarka formułuje to inaczej. Szukaj takich komunikatów:

Jak działa zaufanie certyfikatu SSL (łańcuch zaufania)

Każdy certyfikat należy do łańcucha zaufania, który kończy się na certyfikacie głównym urzędu certyfikacji, któremu przeglądarka już ufa.

Przy połączeniu serwer wysyła własny certyfikat oraz jeden lub kilka pośrednich. Przeglądarka sprawdza, czy certyfikat witryny został podpisany przez pośredni, a pośredni przez główny z jej listy. Chrome nie korzysta już w tym celu z listy systemu operacyjnego: ma własną, Chrome Root Store, w Windows i macOS od Chrome 108, a w Androidzie od Chrome 115 (nie na iPhonie i iPadzie, gdzie wymagana jest lista Apple). Ta lista zawiera około 100 certyfikatów głównych i aktualizuje się w tle (Chrome Root Store). W Windows i macOS Edge ma listę Microsoftu, Firefox listę Mozilli, a wszystkie ufają też certyfikatom głównym dodanym do komputera przez Ciebie lub Twoją firmę.

Jeśli brakuje któregoś ogniwa albo jest nieznane, pojawia się ten błąd (więcej w artykule czym jest łańcuch certyfikatów SSL). Łańcuch składa się z czterech części:

• Główny urząd CA — samopodpisany i wbudowany w listę certyfikatów głównych przeglądarki
• Pośredni urząd CA — podpisany przez główny; serwer musi go wysłać. Chrome pobiera brakujący z adresu zapisanego w certyfikacie, ale curl, aplikacje i wiele innych klientów tego nie potrafi
• Certyfikat witryny — podpisany przez pośredni, dla nazw z listy alternatywnych nazw podmiotu
• Walidacja — przeglądarka przechodzi od certyfikatu witryny do zaufanego certyfikatu głównego; każdy podpis musi się zgadzać

Co powoduje NET::ERR_CERT_AUTHORITY_INVALID?

Miejsce, w którym widzisz błąd, zawęża przyczynę: jedna witryna oznacza, że problem prawie zawsze tkwi w jej certyfikacie. Każda strona HTTPS oznacza, że problem jest w urządzeniu lub sieci.

Rozwiązania dla odwiedzających (strona klienta)

Jeśli widzisz błąd na stronie, której nie prowadzisz, wypróbuj poniższe kroki po kolei. Nigdy nie wpisuj hasła ani numeru karty na stronie, która pokazuje to ostrzeżenie.

Rozwiązanie 1: zaloguj się do Wi-Fi lub wypróbuj inną sieć

Wi-Fi w hotelach, na lotniskach i w kawiarniach często przechwytuje pierwsze połączenia, aby pokazać stronę logowania, a wtedy strona HTTPS dostaje certyfikat sieci zamiast własnego. Pomoc Chrome mówi, że takie sieci wymagają zalogowania, a otwarcie strony z http:// wyświetla stronę logowania; zamiast tego błędu Chrome może też pokazać stronę „Połączenie z siecią Wi-Fi”. Zaakceptuj logowanie i odśwież stronę.

Sieci firmowe i szkolne mogą też kontrolować HTTPS własnym certyfikatem. Jeśli błąd znika przy danych komórkowych, zapytaj dział IT tej sieci: zarządzane przez nich urządzenia zwykle mają zainstalowany ich certyfikat główny, a Twoje może go nie mieć.

Rozwiązanie 2: sprawdź skanowanie HTTPS w antywirusie

Pakiety antywirusowe, takie jak Kaspersky, Avast, ESET i Bitdefender, mogą skanować HTTPS, odszyfrowując ruch własnym certyfikatem i szyfrując go ponownie. Jeśli przeglądarka nie ufa ich certyfikatowi głównemu albo funkcja przestaje działać po aktualizacji, każda strona HTTPS od razu pokazuje ten błąd.

Aby to sprawdzić, wstrzymaj tylko funkcję skanowania HTTPS lub sieci i odśwież stronę. Jeśli błąd znika, napraw lub zaktualizuj antywirus, żeby ponownie zainstalował swój certyfikat, albo zostaw skanowanie HTTPS wyłączone.

Rozwiązanie 3: zaktualizuj przeglądarkę i system operacyjny

Przeglądarki i systemy operacyjne regularnie aktualizują listy certyfikatów głównych (Chrome przez aktualizacje komponentów w tle), a stare systemy nie mają nowszych. Android starszy niż 7.1.1 nie ufa na przykład ISRG Root X1, więc witryny Let's Encrypt zawodzą tam w przeglądarkach i aplikacjach korzystających z listy systemu.

Zacznij od przeglądarki: Chrome i Edge mają własne listy certyfikatów głównych w Windows i macOS, a Chrome także w Androidzie od wersji 115. Potem zaktualizuj system operacyjny.

Rozwiązanie 4: sprawdź datę i godzinę

Zegar przesunięty o miesiące lub lata sprawia, że certyfikaty wyglądają na jeszcze nieważne lub wygasłe. Chrome zwykle pokazuje wtedy osobne ostrzeżenie („Twój zegar się spóźnia” lub ERR_CERT_DATE_INVALID), ale mocno rozregulowany zegar po wyczerpaniu baterii CMOS albo po przywróceniu maszyny wirtualnej może zepsuć także sprawdzanie zaufania. Wykluczenie tego zajmuje dziesięć sekund.

Windows: Ustawienia → Godzina i język → Data i godzina → włącz Ustaw czas automatycznie. macOS: Ustawienia systemowe → Ogólne → Data i czas → Ustawiaj datę i czas automatycznie. Android: Ustawienia → System → Data i godzina → Ustawiaj godzinę automatycznie (w Androidzie 16 opcja nazywa się Automatyczna data i godzina).

Rozwiązanie 5: spróbuj w trybie incognito, potem uruchom przeglądarkę ponownie

Okno incognito (Ctrl+Shift+N w Chrome i Edge, Ctrl+Shift+P dla okna prywatnego w Firefox) działa bez Twoich rozszerzeń, chyba że zezwolono na nie w tym oknie. Rozszerzenia VPN i proxy mogą kierować ruch przez serwer, który przedstawia własny certyfikat; jeśli witryna działa w trybie incognito, wyłącz rozszerzenia w chrome://extensions i włączaj je z powrotem pojedynczo.

Jeśli witryna dopiero co naprawiła certyfikat, zamknij wszystkie okna przeglądarki i otwórz ją ponownie, aby sprawdziła nowy certyfikat od zera.

Rozwiązanie 6: na Androidzie

Android dodaje kilka własnych sprawdzeń:

• Ustaw datę i godzinę automatycznie: Ustawienia → System → Data i godzina.
• Zaktualizuj Chrome i Android System WebView w Sklepie Play. Aplikacje, które pokazują strony przez WebView, sprawdzają certyfikaty według własnej listy certyfikatów głównych Androida, więc na starej wersji Androida błąd może się tam nadal pojawiać.
• Wyłącz aplikacje VPN, blokujące reklamy lub „bezpiecznego przeglądania”, które filtrują HTTPS; pokazują ikonę klucza lub VPN na pasku stanu.
• Zaloguj się do Wi-Fi: sieci publiczne pokazują błąd, dopóki nie zaakceptujesz ich strony logowania.
• W Androidzie starszym niż 7.1.1 certyfikatu głównego Let's Encrypt nie ma na liście systemu, więc aplikacje i przeglądarki, które na niej polegają, nie zweryfikują tych witryn. Jedynym obejściem jest przeglądarka z własną listą certyfikatów głównych.

Rozwiązania dla właścicieli stron (strona serwera)

Jeśli odwiedzający zgłaszają NET::ERR_CERT_AUTHORITY_INVALID na Twojej stronie, serwowany przez Ciebie certyfikat zwykle nie łączy się z publicznym certyfikatem głównym. Najpierw sprawdź go w SSL Checker, potem napraw to, co znajdzie. Jeśli pokazuje inny certyfikat niż ten, który zainstalowano, sprawdź w DNS Lookup, czy domena wskazuje na właściwy serwer, a w HTTP Header Checker, który serwer odpowiada.

Rozwiązanie 1: zainstaluj certyfikat od zaufanego CA

Certyfikatowi samopodpisanemu ani certyfikatowi z własnego urzędu CA przeglądarki odwiedzających nigdy nie zaufają: podpisujący nie jest na żadnej publicznej liście certyfikatów głównych.

Zainstaluj zamiast tego certyfikat od publicznie zaufanego urzędu CA. Let's Encrypt wydaje bezpłatne, zautomatyzowane certyfikaty, którym ufają wszystkie główne przeglądarki; DigiCert, Sectigo i GlobalSign sprzedają certyfikaty z walidacją organizacji i wsparciem.

# Install Let's Encrypt certificate with Certbot (Nginx)
sudo certbot --nginx -d example.com -d www.example.com

# Install Let's Encrypt certificate with Certbot (Apache)
sudo certbot --apache -d example.com -d www.example.com

# Verify the installed certificate
sudo certbot certificates

Rozwiązanie 2: wysyłaj pełny łańcuch certyfikatów

Twój certyfikat może być całkowicie poprawny, a serwer i tak nie wysyła certyfikatu pośredniego. Chrome często to maskuje, pobierając brakujący certyfikat pośredni samodzielnie, więc strona działa w Chrome, a zawodzi w curl, aplikacjach, wywołaniach zwrotnych płatności i na niektórych telefonach.

Sprawdź witrynę w SSL Checker DNS Robot: pokazuje łańcuch wysyłany przez serwer i to, czy ufają mu Mozilla, Chrome, Apple i Microsoft. Możesz też sprawdzić z terminala:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# letsencrypt.org on 26 Oct 2026, a complete chain:
#  0 s:CN=letsencrypt.org
#    i:C=US, O=Let's Encrypt, CN=YE2
#  1 s:C=US, O=Let's Encrypt, CN=YE2
#    i:C=US, O=ISRG, CN=Root YE
#  2 s:C=US, O=ISRG, CN=Root YE
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#  3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
# Only certificate 0 listed = the intermediate is missing.

# nginx: point ssl_certificate at the full chain, not the leaf alone
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Apache 2.4.8+
SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Rozwiązanie 3: odnów wygasły certyfikat

Wygasły certyfikat od zaufanego urzędu CA pokazuje ERR_CERT_DATE_INVALID, a nie ten błąd. ERR_CERT_AUTHORITY_INVALID zobaczysz tylko wtedy, gdy łańcuch jest także niezaufany, bo Chrome zgłasza poważniejszy problem. W obu przypadkach sprawdź daty i odnów certyfikat:

# Check the certificate's dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
# notBefore=Sep 30 12:00:00 2026 GMT
# notAfter=Dec 29 11:59:59 2026 GMT

# Renew now with Certbot, then reload the web server
sudo certbot renew --force-renewal
sudo systemctl reload nginx    # or apache2

Rozwiązanie 4: obejmij każdą nazwę, której używają odwiedzający

Zaufany certyfikat, który nie zawiera nazwy z paska adresu, pokazuje zamiast tego ERR_CERT_COMMON_NAME_INVALID. Zamienia się w ten błąd dopiero wtedy, gdy certyfikat jest także niezaufany, więc napraw najpierw zaufanie, potem nazwy.

Przeglądarki sprawdzają tylko listę alternatywnych nazw podmiotu (Subject Alternative Name), a nie dawną nazwę Common Name. Wildcard (*.example.com) obejmuje jeden poziom subdomen, ale nie samo example.com, więc przy zamawianiu wpisz obie nazwy. SSL Checker pokazuje pełną listę nazw certyfikatu.

Rozwiązanie 5: prywatny lub firmowy urząd CA

Strony wewnętrzne często celowo używają firmowego urzędu CA. Działa to tylko na urządzeniach, na których zainstalowano firmowy certyfikat główny, a Chrome i Edge ufają certyfikatowi głównemu dodanemu do Windows lub macOS (Chrome Root Store FAQ). Wdróż go przez zasady grupy lub narzędzie do zarządzania urządzeniami albo dodaj ręcznie:

# Windows (Command Prompt as Administrator): trust for all users
certutil -addstore -f Root company-root.crt

# macOS: trust in the System keychain
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain company-root.crt

ERR_CERT_AUTHORITY_INVALID na localhost (programiści)

Lokalny serwer HTTPS z certyfikatem samopodpisanym pokazuje ten błąd z założenia. Zamiast klikać dalej, spraw, by certyfikat był zaufany na Twoim komputerze:

• mkcert — mkcert -install tworzy lokalny urząd CA i dodaje go do magazynu zaufania systemu (oraz Firefoksa, gdy zainstalowano certutil z NSS); potem mkcert localhost 127.0.0.1 ::1 tworzy certyfikat, któremu ufają Chrome, Edge i Firefox
• Next.js — next dev --experimental-https tworzy za Ciebie lokalnie zaufany certyfikat przez mkcert
• Vite — @vitejs/plugin-basic-ssl tworzy certyfikat niezaufany, więc nadal zobaczysz ten błąd; wskaż w server.https pliki mkcert
• Stare porady, które już nie działają — przełącznik chrome://flags/#allow-insecure-localhost wygasł po Chrome 130 i nie ma go już w chrome://flags

# Install mkcert (macOS)
brew install mkcert
mkcert -install

# Generate localhost certificate
mkcert localhost 127.0.0.1 ::1
# Creates: localhost+2.pem and localhost+2-key.pem

# Use with Node.js
const https = require('https');
const fs = require('fs');
https.createServer({
  cert: fs.readFileSync('localhost+2.pem'),
  key: fs.readFileSync('localhost+2-key.pem')
}, app).listen(3000);

Powiązane błędy certyfikatów SSL

NET::ERR_CERT_AUTHORITY_INVALID to jeden z kilku błędów certyfikatu stojących za stroną „Połączenie nie jest prywatne” w Chrome. Każdy kod wskazuje inne sprawdzenie: