ERR_CERT_AUTHORITY_INVALID beheben: Chrome, Edge, Android

Was ist NET::ERR_CERT_AUTHORITY_INVALID?

NET::ERR_CERT_AUTHORITY_INVALID bedeutet, dass Ihr Browser dem Aussteller des Website-Zertifikats nicht vertraut. Chrome zeigt „Dies ist keine sichere Verbindung“, und unter Erweitert steht, der Server habe „nicht beweisen“ können, „dass er example.com ist“, weil sein Sicherheitszertifikat nicht als vertrauenswürdig eingestuft wird; mögliche Gründe seien „eine fehlerhafte Konfiguration oder ein Angreifer, der deine Verbindung abfängt“. Chromium führt den Fehler als -202 (net_error_list.h).

Die Verbindung wurde aufgebaut, der Server hat sein Zertifikat geschickt, und der Browser konnte es keiner Zertifizierungsstelle (CA) zuordnen, der er vertraut. Chromiums eigene Hinweise nennen drei Gründe: Ein Angreifer hat das Zertifikat ausgetauscht, die Website nutzt eine CA, die der Browser nicht kennt, oder das Zertifikat ist selbstsigniert.

Hat ein Zertifikat mehrere Probleme, zeigt Chrome nur das schwerwiegendste, und ein nicht vertrauenswürdiger Aussteller wiegt schwerer als ein falscher Name oder ein abgelaufenes Datum. Ein selbstsigniertes Zertifikat, das auch abgelaufen ist, zeigt daher diesen Code und nicht ERR_CERT_DATE_INVALID.

Wie ERR_CERT_AUTHORITY_INVALID in verschiedenen Browsern aussieht

Jeder Browser formuliert es anders. Achten Sie auf Folgendes:

Wie SSL-Zertifikatsvertrauen funktioniert (Vertrauenskette)

Jedes Zertifikat hängt an einer Vertrauenskette, die bei einer Root-Zertifizierungsstelle endet, der der Browser bereits vertraut.

Beim Verbindungsaufbau schickt der Server sein eigenes Zertifikat plus ein oder mehrere Zwischenzertifikate. Der Browser prüft, ob das Zertifikat der Website vom Zwischenzertifikat signiert wurde und dieses von einem Root auf seiner Liste. Chrome nutzt dafür nicht mehr die Liste Ihres Betriebssystems: Es bringt seine eigene mit, den Chrome Root Store, unter Windows und macOS seit Chrome 108 und unter Android seit Chrome 115 (nicht auf iPhone und iPad, wo Apples Liste vorgeschrieben ist). Diese Liste umfasst rund 100 Roots und wird im Hintergrund aktualisiert (Chrome Root Store). Unter Windows und macOS bringt Edge die Liste von Microsoft mit, Firefox die von Mozilla, und alle vertrauen auch Roots, die Sie oder Ihre Firma dem Computer hinzufügen.

Fehlt ein Glied oder ist es unbekannt, erscheint dieser Fehler (mehr dazu in Was ist eine SSL-Zertifikatskette). Die Kette hat vier Teile:

• Root-CA — selbstsigniert und fest in der Root-Liste des Browsers enthalten
• Zwischen-CA (Intermediate) — vom Root signiert; der Server muss sie mitsenden. Chrome lädt ein fehlendes Zwischenzertifikat von der im Zertifikat angegebenen Adresse nach, curl, Apps und viele andere Clients können das nicht
• Website-Zertifikat — vom Zwischenzertifikat signiert, für die Namen in seiner Subject-Alternative-Name-Liste
• Validierung — der Browser geht vom Website-Zertifikat aufwärts bis zu einem vertrauenswürdigen Root; jede Signatur muss stimmen

Was verursacht NET::ERR_CERT_AUTHORITY_INVALID?

Wo der Fehler auftritt, grenzt die Ursache ein: Eine einzelne Website bedeutet fast immer, dass das Zertifikat dieser Website schuld ist. Jede HTTPS-Seite bedeutet, dass es an Ihrem Gerät oder Netzwerk liegt.

Lösungen für Website-Besucher (Client-Seite)

Sehen Sie den Fehler auf einer Website, die nicht Ihre ist, probieren Sie diese Schritte der Reihe nach. Geben Sie auf einer Seite mit dieser Warnung niemals ein Passwort oder eine Kartennummer ein.

Lösung 1: Im WLAN anmelden oder ein anderes Netzwerk testen

WLANs in Hotels, Flughäfen und Cafés leiten Ihre ersten Verbindungen oft um, um eine Anmeldeseite anzuzeigen, und eine HTTPS-Seite erhält dann das Zertifikat des Netzwerks statt ihres eigenen. Die Chrome-Hilfe sagt, dass solche Netzwerke eine Anmeldung verlangen und dass der Aufruf einer http://-Seite die Anmeldeseite öffnet; Chrome zeigt statt dieses Fehlers mitunter auch eine Seite zum Verbinden mit dem WLAN. Bestätigen Sie die Anmeldung und laden Sie die Seite neu.

Auch Firmen- und Schulnetzwerke können HTTPS mit einem eigenen Zertifikat prüfen. Verschwindet der Fehler über Mobilfunk, fragen Sie die IT des Netzwerks: Verwaltete Geräte haben deren Root normalerweise installiert, Ihres womöglich nicht.

Lösung 2: HTTPS-Prüfung des Virenscanners kontrollieren

Virenscanner wie Kaspersky, Avast, ESET und Bitdefender können HTTPS prüfen, indem sie es mit einem eigenen Zertifikat entschlüsseln und wieder verschlüsseln. Vertraut Ihr Browser deren Root-Zertifikat nicht oder bricht die Funktion nach einem Update, zeigt sofort jede HTTPS-Seite diesen Fehler.

Zum Testen pausieren Sie nur die HTTPS- oder Web-Prüfung und laden neu. Verschwindet der Fehler, reparieren oder aktualisieren Sie den Virenscanner, damit er sein Zertifikat neu installiert, oder lassen Sie die HTTPS-Prüfung ausgeschaltet.

Lösung 3: Browser und Betriebssystem aktualisieren

Browser und Betriebssysteme aktualisieren ihre Root-Listen regelmäßig (Chrome über Komponenten-Updates im Hintergrund), und alte Systeme kennen neuere Roots nicht. Android-Versionen vor 7.1.1 vertrauen zum Beispiel ISRG Root X1 nicht, sodass Let's-Encrypt-Seiten in Browsern und Apps scheitern, die sich auf die Systemliste stützen.

Aktualisieren Sie zuerst den Browser: Chrome und Edge bringen unter Windows und macOS eigene Root-Listen mit, Chrome auch unter Android ab Version 115. Danach folgt das Betriebssystem.

Lösung 4: Datum und Uhrzeit prüfen

Eine Uhr, die Monate oder Jahre danebenliegt, lässt Zertifikate noch nicht gültig oder abgelaufen erscheinen. Chrome zeigt dafür meist eine eigene Warnung („Deine Uhr geht nach“ oder ERR_CERT_DATE_INVALID), doch eine stark falsche Uhr nach einer leeren CMOS-Batterie oder einer wiederhergestellten virtuellen Maschine kann auch die Vertrauensprüfung stören. Das auszuschließen dauert zehn Sekunden.

Windows: Einstellungen → Zeit & Sprache → Datum & Uhrzeit → Uhrzeit automatisch festlegen einschalten. macOS: Systemeinstellungen → Allgemein → Datum & Uhrzeit → Datum und Uhrzeit automatisch einstellen. Android: Einstellungen → System → Datum & Uhrzeit → Zeit automatisch einstellen (unter Android 16: Datum und Uhrzeit automatisch einstellen).

Lösung 5: Inkognitofenster testen, dann den Browser neu starten

Ein Inkognitofenster (Strg+Umschalt+N in Chrome und Edge, Strg+Umschalt+P für ein privates Fenster in Firefox) läuft ohne Ihre Erweiterungen, sofern Sie sie nicht erlaubt haben. VPN- und Proxy-Erweiterungen können Ihren Datenverkehr über einen Server leiten, der ein eigenes Zertifikat vorzeigt; funktioniert die Seite im Inkognitofenster, schalten Sie die Erweiterungen unter chrome://extensions aus und nacheinander wieder ein.

Hat die Website gerade ihr Zertifikat korrigiert, schließen Sie alle Browserfenster und öffnen den Browser neu, damit er das neue Zertifikat von Grund auf prüft.

Lösung 6: Unter Android

Android bringt ein paar eigene Prüfungen mit:

• Datum und Uhrzeit automatisch einstellen: Einstellungen → System → Datum & Uhrzeit.
• Chrome und Android System WebView aktualisieren, über den Play Store. Apps, die Webseiten über WebView anzeigen, prüfen Zertifikate gegen die Root-Liste von Android selbst, eine alte Android-Version kann dort also weiterhin scheitern.
• VPN-, Werbeblocker- oder „Sicheres Surfen“-Apps ausschalten, die HTTPS filtern; sie zeigen ein Schlüssel- oder VPN-Symbol in der Statusleiste.
• Im WLAN anmelden: Öffentliche Netzwerke zeigen den Fehler, bis Sie ihre Anmeldeseite bestätigen.
• Unter Android vor 7.1.1 fehlt das Let's-Encrypt-Root in der Systemliste, sodass Apps und Browser, die sich darauf stützen, diese Seiten nicht verifizieren können. Ein Browser mit eigener Root-Liste ist die einzige Abhilfe.

Lösungen für Website-Betreiber (Server-Seite)

Melden Besucher NET::ERR_CERT_AUTHORITY_INVALID auf Ihrer Website, führt das ausgelieferte Zertifikat meist nicht zu einem öffentlichen Root. Prüfen Sie es zuerst mit dem SSL Checker und beheben Sie, was er findet. Zeigt er ein anderes Zertifikat als das installierte, bestätigen Sie mit dem DNS Lookup, dass die Domain auf den erwarteten Server zeigt, und mit dem HTTP Header Checker, welcher Server antwortet.

Lösung 1: Zertifikat von einer vertrauenswürdigen CA installieren

Ein selbstsigniertes Zertifikat oder eines Ihrer eigenen CA wird von den Browsern der Besucher nie als vertrauenswürdig akzeptiert: Der Aussteller steht auf keiner öffentlichen Root-Liste.

Installieren Sie stattdessen ein Zertifikat einer öffentlich vertrauenswürdigen CA. Let's Encrypt stellt kostenlose, automatisierte Zertifikate aus, denen alle großen Browser vertrauen; DigiCert, Sectigo und GlobalSign verkaufen Zertifikate mit Organisationsprüfung und Support.

# 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

Lösung 2: Die vollständige Zertifikatskette senden

Ihr Zertifikat kann völlig gültig sein, während der Server vergisst, das Zwischenzertifikat mitzuschicken. Chrome überspielt das oft, indem es das fehlende Zwischenzertifikat selbst nachlädt, sodass die Seite in Chrome läuft und in curl, Apps, Zahlungs-Callbacks und manchen Smartphones scheitert.

Prüfen Sie die Seite mit dem SSL Checker von DNS Robot: Er zeigt die Kette, die Ihr Server sendet, und ob Mozilla, Chrome, Apple und Microsoft ihr jeweils vertrauen. Oder prüfen Sie im Terminal:

# 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

Lösung 3: Abgelaufenes Zertifikat erneuern

Ein abgelaufenes Zertifikat einer vertrauenswürdigen CA zeigt ERR_CERT_DATE_INVALID, nicht diesen Fehler. ERR_CERT_AUTHORITY_INVALID sehen Sie nur, wenn auch die Kette nicht vertrauenswürdig ist, weil Chrome das schwerwiegendere Problem meldet. So oder so: Prüfen Sie die Daten und erneuern Sie:

# 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

Lösung 4: Jeden Namen abdecken, den Besucher nutzen

Ein vertrauenswürdiges Zertifikat, das den Namen in der Adresszeile nicht enthält, zeigt stattdessen ERR_CERT_COMMON_NAME_INVALID. Zu diesem Fehler wird es erst, wenn das Zertifikat zusätzlich nicht vertrauenswürdig ist; beheben Sie also zuerst das Vertrauen, dann die Namen.

Browser prüfen nur die Subject Alternative Name-Liste, nicht den alten Common Name. Ein Wildcard (*.example.com) deckt eine Ebene von Subdomains ab, aber nicht example.com selbst; führen Sie beim Beantragen also beide auf. Der SSL Checker zeigt die vollständige Namensliste eines Zertifikats.

Lösung 5: Private oder Firmen-CA verwenden

Interne Seiten nutzen oft absichtlich eine Firmen-CA. Das funktioniert nur auf Geräten, auf denen das Root-Zertifikat der Firma installiert ist, und Chrome und Edge vertrauen einem Root, das zu Windows oder macOS hinzugefügt wurde (Chrome Root Store FAQ). Verteilen Sie es per Gruppenrichtlinie oder Ihrem Geräteverwaltungstool oder fügen Sie es von Hand hinzu:

# 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 auf Localhost (Entwickler)

Ein lokaler HTTPS-Server mit selbstsigniertem Zertifikat zeigt diesen Fehler zwangsläufig. Machen Sie das Zertifikat auf Ihrem eigenen Rechner vertrauenswürdig, statt die Warnung wegzuklicken:

• mkcert — mkcert -install erstellt eine lokale CA und fügt sie dem Trust Store Ihres Systems hinzu (und dem von Firefox, sobald certutil aus NSS installiert ist); danach erzeugt mkcert localhost 127.0.0.1 ::1 ein Zertifikat, dem Chrome, Edge und Firefox vertrauen
• Next.js — next dev --experimental-https erstellt für Sie mit mkcert ein lokal vertrauenswürdiges Zertifikat
• Vite — @vitejs/plugin-basic-ssl erzeugt ein nicht vertrauenswürdiges Zertifikat, Sie sehen den Fehler also weiterhin; richten Sie server.https stattdessen auf die Dateien von mkcert
• Alte Tipps, die nicht mehr funktionieren — der Schalter chrome://flags/#allow-insecure-localhost ist nach Chrome 130 abgelaufen und steht nicht mehr in 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);

Verwandte SSL-Zertifikatsfehler

NET::ERR_CERT_AUTHORITY_INVALID ist einer von mehreren Zertifikatsfehlern hinter der Chrome-Seite „Dies ist keine sichere Verbindung“. Jeder Code verweist auf eine andere Prüfung: