NET::ERR_CERT_AUTHORITY_INVALID: co oznacza i jak to naprawić

err_cert_authority_invalid oznacza, że Twoja przeglądarka nie potrafi zbudować prawidłowego łańcucha od certyfikatu strony do głównego urzędu certyfikacji, któremu ufa. Komunikat net::err_cert_authority_invalid wskazuje na błąd zaufania, a nie dowodzi, że strona jest złośliwa.

Zacznij od sprawdzenia, czy błąd dotyczy jednej strony, czy wielu niepowiązanych ze sobą witryn. Następnie wybierz odpowiednią ścieżkę poniżej: odwiedzający powinni wyizolować urządzenie lub sieć, właściciele stron sprawdzić wdrożony łańcuch certyfikatów, a programiści skonfigurować jawne zaufanie do swojego lokalnego lub wewnętrznego CA.

Najważniejsze fakty

• err_cert_authority_invalid oznacza, że klient nie może ustanowić łańcucha certyfikatów do zaufanego urzędu.
• Brakujący certyfikat pośredni może uniemożliwić weryfikację łańcucha certyfikatów.
• Wygaśnięcie certyfikatu i niezgodność nazwy hosta to inne problemy niż niezaufany urząd certyfikacji.
• Błąd, który pojawia się tylko za proxy, sam w sobie nie dowodzi przechwytywania TLS.
• Zainstalowanie deweloperskiego CA nie konfiguruje serwera deweloperskiego tak, by używał jego certyfikatu.
• Wyłączenie weryfikacji certyfikatu usuwa podstawową kontrolę tożsamości serwera.

Co oznacza err_cert_authority_invalid?

Przeglądarka otrzymała certyfikat, ale nie mogła ustanowić zaufania do urzędu, który go wystawił. Samo szyfrowanie nie wystarcza, by stwierdzić, że serwer jest zamierzonym miejscem docelowym.

Typowy łańcuch prowadzi od certyfikatu końcowego strony, przez certyfikaty pośrednie, do zaufanego certyfikatu głównego. Serwer dostarcza certyfikat końcowy i niezbędne certyfikaty pośrednie, a klient potrzebuje akceptowalnego punktu zaufania. Niezaufany certyfikat samopodpisany, niedostępny certyfikat pośredni lub nieznany prywatny CA mogą ten proces zerwać.

Chromium rozróżnia błędy urzędu, daty i nazwy hosta w swoich definicjach błędów sieciowych. Zanim zmienisz ustawienia, zdiagnozuj dokładny kod błędu.

Co powoduje err_cert_authority_invalid?

Sprawdź punkt zaufania, łańcuch wysyłany przez serwer i możliwość podmiany certyfikatu. Skorzystaj z tej 3-etapowej kontroli zaufania, aby rozdzielić te przyczyny.

• Czy certyfikat główny jest zaufany? Prywatny CA lub samopodpisany certyfikat deweloperski może być nieznany temu klientowi.
• Czy serwer dostarcza niezbędne certyfikaty pośrednie? Sam prawidłowy certyfikat końcowy może nie wystarczyć. Dokumentacja DigiCert o łańcuchach wyjaśnia rolę certyfikatu pośredniego.
• Czy coś ponownie podpisuje ruch? Autoryzowana usługa inspekcji lub lokalne narzędzie bezpieczeństwa może przedstawiać zastępczy certyfikat, którego CA brakuje w konfiguracji zaufania klienta.

Przechwytywanie to zmiana w samym połączeniu, a nie kolejne ogniwo łańcucha certyfikatów. Te pokrewne błędy wymagają innych napraw, zgodnie z definicjami Chromium:

Jak naprawić błąd jako odwiedzający?

Zanim zmienisz ustawienia zaufania, porównaj połączenia. Jeśli jedna strona nie działa na niezależnych urządzeniach i w różnych sieciach, zgłoś to jej właścicielowi.

• Mimo wszystko sprawdź zegar. Popraw datę, godzinę i strefę czasową, choć problemy z zegarem zwykle dotyczą błędu DATE_INVALID.
• Spróbuj w innej zaufanej sieci. Porównaj domowy internet stacjonarny z danymi komórkowymi. W publicznej sieci Wi-Fi dokończ właściwy proces logowania do tej sieci.
• Spróbuj w oknie prywatnym. Jeśli wynik się zmieni, sprawdź rozszerzenia i konfigurację przeglądarki.
• Zaktualizuj przeglądarkę i system operacyjny. Po obsługiwanych aktualizacjach uruchom ponownie urządzenie i spróbuj jeszcze raz.
• Sprawdź skanowanie HTTPS. Na urządzeniu zarządzanym przez Ciebie tymczasowo przetestuj połączenie z wyłączoną tą funkcją, a potem włącz ją z powrotem. Jeśli to ona wywołała błąd, poszukaj obsługiwanego sposobu naprawy.

Te kroki izolacji są zgodne z wytycznymi Google dotyczącymi błędów certyfikatów. Na sprzęcie zarządzanym zapytaj dział IT, zanim zmienisz oprogramowanie zabezpieczające.

Nie przechodź na strony bankowe, logowania ani płatności, gdy ostrzeżenia o certyfikacie nie zostały wyjaśnione. Szerzej o tym ostrzeżeniu piszemy w naszym poradniku o komunikacie Twoje połączenie nie jest prywatne.

Dlaczego błąd pojawia się na WSZYSTKICH stronach?

Błędy na niepowiązanych witrynach wskazują raczej na wspólny problem urządzenia, magazynu zaufania lub sieci. Trudniej to pogodzić z tym, że każda strona z osobna wdrożyła wadliwy certyfikat.

• Jedna strona, kilka urządzeń: sprawdź łańcuch strony lub wspólną ścieżkę sieciową.
• Wiele stron, jedno urządzenie: sprawdź lokalne zaufanie, oprogramowanie zabezpieczające i ustawienia zarządzane.
• Jedna przeglądarka lub aplikacja: porównaj jej konfigurację certyfikatów z działającym klientem.
• Kilka urządzeń, jedna sieć: sprawdź bramę, captive portal lub usługę inspekcji.
• Działa w innej sieci: porównaj routing, DNS i certyfikaty przedstawiane na każdej ścieżce.

Zsynchronizuj zegar, sprawdź wystawcę i zanotuj, które porównania zmieniły wynik. Nieoczekiwana organizacja widoczna jako wystawca na niepowiązanych domenach to przydatna wskazówka, ale nie wystarczający dowód uzasadnionej inspekcji. Prześlij działowi IT adresy URL, których to dotyczy, dokładne komunikaty błędów i dane wystawcy.

Czyszczenie DNS i reset przeglądarki zostaw na koniec. Wyczyszczenie DNS może pomóc tylko przy nieaktualnym rozwiązaniu nazwy, ale nie zainstaluje brakującego punktu zaufania. Reset nie naprawi łańcucha certyfikatów zdalnego serwera. Jeśli połączenie zawodzi przed wymianą certyfikatów, skorzystaj z osobnego poradnika o braku odpowiedzi proxy.

Jak właściciele stron naprawiają łańcuch certyfikatów?

Udostępniaj poprawny certyfikat końcowy i wymagane certyfikaty pośrednie z każdego punktu końcowego TLS. Niezaufany samopodpisany certyfikat produkcyjny zastąp takim, który jest odpowiedni dla Twoich odwiedzających.

Sprawdź osobno rzeczywistą nazwę hosta, load balancer i serwer źródłowy. DigiCert zaleca instalowanie brakujących certyfikatów pośrednich przy błędach niekompletnego łańcucha.

Zamień poniżej example.com na własną nazwę hosta. OpenSSL dokumentuje te opcje weryfikacji:

openssl s_client -connect example.com:443 \
  -servername example.com -verify_hostname example.com \
  -verify_return_error -showcerts </dev/null

-showcerts wyświetla to, co wysłał serwer, ale nie potwierdza zweryfikowanego łańcucha. -verify_return_error sprawia, że błędy weryfikacji przerywają połączenie, a opcje nazwy hosta wybierają i sprawdzają właściwy host. Wyniki zależą od lokalnej konfiguracji zaufania. Zobacz dokumentację OpenSSL s_client.

Dla istniejącego wdrożenia Let’s Encrypt zarządzanego przez Certbot przetestuj odnowienie za pomocą udokumentowanego suchego przebiegu:

certbot renew --dry-run

Udany test odnowienia Certbot nie dowodzi, że produkcja serwuje odnowione pliki. Po odnowieniu i przeładowaniu sprawdź wdrożony łańcuch oraz monitoruj termin ważności certyfikatu widoczny dla klientów.

Wyjątek Cloudflare: certyfikaty Origin CA nie są zaufane przez przeglądarki. Wyłączenie proxy, wstrzymanie Cloudflare lub bezpośredni dostęp do serwera źródłowego może ujawnić ten błąd. Przywróć zamierzoną konfigurację proxy albo zainstaluj publicznie zaufany certyfikat serwera źródłowego na potrzeby bezpośredniego dostępu. Rozwiązywanie problemów z Origin CA w Cloudflare opisuje to rozróżnienie oraz zgodność z trybem Full (strict).

Jak utworzyć zaufany certyfikat localhost?

Utwórz deweloperskie CA, zaufaj mu na maszynie deweloperskiej i skonfiguruj serwer z certyfikatem obejmującym nazwy, których faktycznie używasz. Samo zaufanie do CA nie konfiguruje HTTPS.

README mkcert opisuje te opcje instalacji. Uruchom tylko tę, która pasuje do Twojego systemu:

# macOS with Homebrew
brew install mkcert

# Windows with Chocolatey
choco install mkcert

# Debian/Ubuntu prerequisite
sudo apt install libnss3-tools
# Then install the appropriate Linux binary from mkcert's official releases.

Po instalacji wygeneruj pliki z jawnie nadanymi nazwami:

mkcert -install
mkcert -cert-file localhost.pem -key-file localhost-key.pem \
  localhost 127.0.0.1 ::1 app.test

Dla app.test dodaj 127.0.0.1 app.test do pliku hosts swojego systemu operacyjnego. Nazwa hosta w adresie URL musi odpowiadać alternatywnej nazwie podmiotu (SAN) w certyfikacie. Nigdy nie udostępniaj rootCA-key.pem i nie trzymaj wygenerowanych kluczy prywatnych w systemie kontroli wersji.

W istniejącym projekcie Next.js Next.js CLI przyjmuje własny certyfikat i klucz deweloperski:

npx next dev --experimental-https \
  --experimental-https-key ./localhost-key.pem \
  --experimental-https-cert ./localhost.pem

W istniejącym projekcie Vite scal to z plikiem vite.config.js. Konfiguracja server.https w Vite przyjmuje opcje serwera HTTPS:

import { defineConfig } from 'vite';
import { readFileSync } from 'node:fs';

export default defineConfig({
  server: {
    https: {
      key: readFileSync('./localhost-key.pem'),
      cert: readFileSync('./localhost.pem'),
    },
  },
});

Klienci mogą wymagać jawnej konfiguracji CA. Te udokumentowane opcje zachowują weryfikację: NODE_EXTRA_CA_CERTS w Node, parametr verify w Requests i opcja –cacert w curl.

# Run in a POSIX shell; replace app.js with your Node entry point.
NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem" node app.js
curl --cacert "$(mkcert -CAROOT)/rootCA.pem" https://localhost:3000/

import subprocess
from pathlib import Path
import requests

ca_dir = subprocess.check_output(['mkcert', '-CAROOT'], text=True).strip()
response = requests.get(
    'https://localhost:3000/',
    verify=str(Path(ca_dir) / 'rootCA.pem'),
    timeout=10,
)
print(response.status_code)

Użyj portu, który faktycznie zgłasza Twój serwer. Nigdy nie używaj verify=False na produkcji: usuwa uwierzytelnianie certyfikatu i stwarza ryzyko przechwycenia ruchu.

Dlaczego ten błąd pojawia się za firmowym proxy lub VPN?

Błąd tylko za proxy sugeruje problem zależny od ścieżki, ale nie dowodzi przechwytywania. DNS, routing i docelowy punkt końcowy również mogą się różnić.

Tunel HTTP CONNECT po ustanowieniu przekazuje bajty dalej, jak określono w RFC 9110. TLS może pozostać między klientem a miejscem docelowym. Pośrednik prowadzący inspekcję natomiast kończy TLS i przedstawia inny certyfikat.

W przypadku autoryzowanej inspekcji uzyskaj certyfikat CA organizacji zweryfikowanymi kanałami IT. Poproś administratorów o potwierdzenie, z którego magazynu korzysta aplikacja zgłaszająca błąd: zaufania przeglądarki, Zaufanych głównych urzędów certyfikacji w Windows czy osobno skonfigurowanego pakietu środowiska uruchomieniowego. Nie zakładaj, że naprawa w przeglądarce naprawi też klienta w Pythonie lub Javie.

Microsoft opisuje dystrybucję certyfikatów przez zasady grupy do wybranego magazynu certyfikatów Windows. Wdrożeniem powinien zarządzać dział IT, a wyłączenia z proxy muszą być zgodne z polityką organizacji.

Informacje o konfiguracji połączenia znajdziesz w artykule jak używać curl z proxy. Różnice w routingu opisujemy w tekście proxy a VPN. DataImpulse zapewnia infrastrukturę proxy, a nie VPN, API do scrapingu ani zarządzany unblocker.

Co pokazał nasz własny test?

15 października 2026 uruchomiliśmy punkty testowe badssl.com przez 5 klientów. Każdy typ błędu dał własny komunikat, dlatego dokładny kod ma znaczenie. To migawka, a nie benchmark.

Metoda i próba: 4 punkty końcowe badssl.com przetestowane z 5 klientami, co daje 20 zapisanych wyników klient-punkt końcowy, a do tego 3 bezpośrednie porównania certyfikatów z porównaniami przez proxy i 1 nieudane zapytanie curl przez proxy. Tabela podsumowuje dwa punkty końcowe z błędami zaufania. Są to zaobserwowane komunikaty, a nie uniwersalne gwarancje dla produktów.

Przez proxy DataImpulse CONNECT odcisk SHA-256 certyfikatu był identyczny jak przy połączeniu bezpośrednim dla untrusted-root.badssl.com i dataimpulse.com: tunel przepuścił oryginalny certyfikat bez zmian, a curl przez proxy zakończył się tym samym błędem niezaufanego certyfikatu głównego co bez proxy.

Dla www.google.com odciski się różniły, a nazwy pospolite wystawców zmieniły się z WR2 na WE2; oba wskazywały Google Trust Services. Duże sieci CDN, takie jak Google, serwują różne certyfikaty z różnych węzłów i regionów, więc porównanie odcisków certyfikatu końcowego ma sens tylko na stronach z jednym certyfikatem. Sama etykieta wystawcy nie uwierzytelnia połączenia, a te obserwacje nie stanowią uniwersalnej gwarancji braku przechwytywania.

Które ustawienia zaufania na platformach mają znaczenie?

Sprawdź konfigurację zaufania używaną przez aplikację, która zgłasza błąd. Certyfikat zainstalowany dla jednego klienta może nie rozwiązać błędu innego klienta.

Czy bezpiecznie jest kontynuować i jak najpierw zweryfikować certyfikat?

Wyjątek rozważ tylko dla kontrolowanego punktu końcowego deweloperskiego, którego tożsamość zweryfikowałeś niezależnie. Niewyjaśnione ostrzeżenie na publicznej stronie to powód, by się zatrzymać.

Chrome opisuje ścieżkę DevTools, Privacy and security, Security, Overview, View certificate do sprawdzania certyfikatów. Skorzystaj z jego wskazówek dotyczących panelu bezpieczeństwa, aby obejrzeć dostępne szczegóły certyfikatu. Jeśli zablokowana strona ich nie udostępnia, poproś właściciela lub dział IT o sprawdzenie połączenia.

Sprawdź nazwę hosta, okres ważności i wystawcę, a następnie porównaj odcisk certyfikatu lub CA zaufanym kanałem. Samo rozpoznanie nazwy wystawcy nie wystarcza.

Najczęściej zadawane pytania

Chcesz porównać połączenia przez proxy i bezpośrednie?

Jeśli Twój przepływ pracy wymaga innej ścieżki sieciowej, poznaj residential proxy DataImpulse. Zachowaj włączoną weryfikację certyfikatu na obu ścieżkach: proxy może pomóc porównać zachowanie połączeń, ale nie naprawi uszkodzonego łańcucha certyfikatów.

Ostatnia aktualizacja: 15 października 2026.