Wie man den NET::ERR_CERT_AUTHORITY_INVALID-Fehler behebt

NET::ERR_CERT_AUTHORITY_INVALID ist ein TLS-Handshake-Fehler auf Browser-Ebene, der auftritt, wenn das vom Webserver präsentierte Zertifikat nicht auf eine Root-Zertifizierungsstelle (CA) zurückgeführt werden kann, der der integrierte Vertrauensspeicher des Browsers vertraut. Der Browser beendet die Verbindung, bevor Daten ausgetauscht werden, und zeigt diesen Fehler an, um den Nutzer vor Man-in-the-Middle-Angriffen (MITM), Datenabfang oder Datenverkehr von einem gefälschten Server zu schützen.

Dies ist keine kosmetische Warnung. Es handelt sich um einen kryptografischen Verifizierungsfehler. Der Browser hat die Zertifikatskette geprüft, versucht, jeden Link bis zu einem vertrauenswürdigen Root zu validieren, und festgestellt, dass die Kette unterbrochen, nicht vorhanden oder kryptografisch ungültig ist. Genau zu verstehen, wo diese Kette bricht, ist der Unterschied zwischen einer Fünf-Minuten-Lösung und stundenlanger Fehldiagnose.

Was diesen Fehler tatsächlich auslöst

Die meisten Dokumentationen listen oberflächliche Ursachen auf. Das eigentliche Bild ist differenzierter, und jede Grundursache erfordert einen anderen Lösungsweg.

Selbstsignierte Zertifikate

Ein selbstsigniertes Zertifikat ist eines, bei dem Aussteller und Subjekt identisch sind – der Server hat sein eigenes Zertifikat signiert, anstatt es von einer vertrauenswürdigen CA signieren zu lassen. Diese sind in lokalen Entwicklungsumgebungen, internen Staging-Servern und privater Infrastruktur üblich. Kein öffentlicher Browser-Vertrauensspeicher erkennt sie, sodass die Kettenvalidierung sofort fehlschlägt.

Wichtiger Hinweis: Selbst wenn Sie ein selbstsigniertes Zertifikat zum OS-Vertrauensspeicher hinzufügen, verwenden einige Browser (insbesondere Chrome auf bestimmten Plattformen) ihren eigenen Zertifikatsspeicher und lehnen es dennoch ab, sofern es nicht explizit konfiguriert wurde.

Abgelaufenes SSL/TLS-Zertifikat

Jedes Zertifikat enthält ein `notBefore`- und `notAfter`-Feld, das in seiner X.509-Struktur kodiert ist. Sobald die Systemuhr den `notAfter`-Zeitstempel überschreitet, ist das Zertifikat kryptografisch ungültig, unabhängig davon, wie es ausgestellt wurde. Browser erzwingen dies strikt.

Sonderfall: Wenn die Uhr Ihres Servers erheblich vorgeht, kann ein technisch noch gültiges Zertifikat dem Server selbst während der TLS-Handshake-Aushandlung als abgelaufen erscheinen, was diesen Fehler serverseitig statt clientseitig verursacht.

Unvollständige Zertifikatskette (fehlende Zwischen-CA)

Dies ist die am häufigsten falsch diagnostizierte Ursache in Produktionsumgebungen. Eine vertrauenswürdige Root-CA signiert keine End-Entity-Zertifikate direkt. Sie signiert Zwischen-CAs, die dann Ihr Zertifikat signieren. Wenn Sie ein SSL-Zertifikat auf einem Server installieren, müssen Sie die vollständige Kette installieren: Ihr End-Entity-Zertifikat plus alle Zwischenzertifikate in der richtigen Reihenfolge verkettet.

Wenn das Zwischenzertifikat in der TLS-Antwort des Servers fehlt, können die meisten Browser die Kette nicht bis zu einem vertrauenswürdigen Root vervollständigen. Firefox ist hier etwas nachsichtiger, da es Zwischenzertifikate aus früheren Sitzungen zwischenspeichert (AIA-Abruf), aber Chrome und Edge schlagen hart fehl.

Überprüfung: Führen Sie `openssl s_client -connect yourdomain.com:443 -showcerts` aus und prüfen Sie, ob die vollständige Kette zurückgegeben wird.

Nicht übereinstimmender Common Name oder SAN des Zertifikats

Wenn ein Zertifikat für `www.example.com` ausgestellt wurde, der Nutzer aber auf `example.com` zugreift (oder eine Subdomain, die nicht von einem Wildcard abgedeckt wird), zeigt der Browser einen verwandten, aber anderen Fehler an. In einigen Konfigurationen manifestiert sich dies jedoch als Fehler wegen ungültiger Autorität statt als Namenskonfliktfehler, insbesondere bei älteren Zertifikatsformaten ohne Subject Alternative Names (SANs).

Clientseitige Zeitabweichung

TLS-Zertifikate sind zeitgebunden. Wenn die Uhr des Client-Rechners auf ein Datum vor dem `notBefore`-Feld des Zertifikats oder nach seinem `notAfter`-Feld eingestellt ist, lehnt der Browser es ab. Dies ist äußerst häufig bei virtuellen Maschinen, neu bereitgestellten Servern oder Rechnern, die längere Zeit ohne NTP-Synchronisierung ausgeschaltet waren.

SSL-Inspektion durch Sicherheitssoftware

Unternehmens-Firewalls, Endpoint-Security-Suiten und einige Antivirenprodukte führen eine SSL/TLS-Inspektion (auch HTTPS-Abfang genannt) durch. Sie beenden die TLS-Verbindung am Sicherheitsgerät, prüfen den Klartext und verschlüsseln ihn dann erneut mit einem dynamisch generierten Zertifikat, das von der eigenen CA des Geräts signiert wurde. Wenn diese Geräte-CA nicht im Vertrauensspeicher des Browsers enthalten ist, löst jede HTTPS-Website diesen Fehler aus.

Veralteter Root-Zertifikatsspeicher

Auf älteren Betriebssystemen (Windows 7 ohne Updates, ältere Linux-Distributionen) enthält das System-Root-CA-Bundle möglicherweise keine neueren Root-Zertifikate. Let’s Encrypts ISRG Root X1 beispielsweise verursachte weitverbreitete Fehler auf Android 7 und älter sowie auf nicht gepatchten Windows-Systemen, als die DST Root CA X3-Kreuzignatur im September 2021 ablief.

Vergleich der Grundursachen

Schritt-für-Schritt-Lösungen

Schritt 1: Systemdatum und -uhrzeit synchronisieren

Dies ist die schnellste Lösung, wenn der Fehler plötzlich auf einem Rechner auftritt, der zuvor funktioniert hat.

Windows:

1. Öffnen Sie Einstellungen > Zeit & Sprache > Datum & Uhrzeit.
2. Aktivieren Sie Uhrzeit automatisch festlegen und Zeitzone automatisch festlegen.
3. Klicken Sie unter „Uhr synchronisieren” auf Jetzt synchronisieren.
4. Wenn die automatische Synchronisierung fehlschlägt, öffnen Sie die Eingabeaufforderung als Administrator und führen Sie aus: `w32tm /resync /force`

macOS:

1. Öffnen Sie Systemeinstellungen > Allgemein > Datum & Uhrzeit.
2. Aktivieren Sie Datum und Uhrzeit automatisch festlegen und wählen Sie einen nahegelegenen NTP-Server (z. B. `time.apple.com`).
3. Wenn das Problem weiterhin besteht, führen Sie im Terminal aus: `sudo sntp -sS time.apple.com`

Linux (Server oder Desktop):

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

Starten Sie nach der Synchronisierung den Browser neu und versuchen Sie es erneut.

Schritt 2: Browser-Cache, Cookies und zwischengespeicherte Zertifikate löschen

Browser speichern HSTS-Richtlinien (HTTP Strict Transport Security) und Zertifikatsdaten zwischen. Ein veralteter Cache-Eintrag kann einen Fehler aufrechterhalten, selbst nachdem das zugrunde liegende Problem behoben wurde.

Google Chrome:

1. Navigieren Sie zu `chrome://settings/clearBrowserData`.
2. Setzen Sie den Zeitraum auf Gesamte Zeit.
3. Aktivieren Sie Cookies und andere Websitedaten und Bilder und Dateien im Cache.
4. Klicken Sie auf Daten löschen.

Zum Löschen des HSTS-spezifischen Caches in Chrome navigieren Sie zu `chrome://net-internals/#hsts`, geben Sie die Domain unter „Domain-Sicherheitsrichtlinien löschen” ein und klicken Sie auf Löschen.

Mozilla Firefox:

1. Öffnen Sie Einstellungen > Datenschutz & Sicherheit.
2. Klicken Sie unter Cookies und Website-Daten auf Daten löschen.
3. Löschen Sie auch Gecachte Webinhalte.

Microsoft Edge:

1. Navigieren Sie zu `edge://settings/clearBrowserData`.
2. Wählen Sie Gesamte Zeit und löschen Sie gecachte Daten und Cookies.

Schritt 3: SSL-Inspektion identifizieren und deaktivieren

Wenn Sie sich in einem Unternehmensnetzwerk befinden oder ein Endpoint-Security-Produkt verwenden, ist die SSL-Inspektion ein Hauptverdächtiger.

1. Klicken Sie auf das Schloss-Symbol (oder Warnsymbol) in der Browser-Adressleiste.
2. Prüfen Sie die Zertifikatsdetails. Wenn der Aussteller Ihr Antivirenanbiet ist (z. B. „Avast Root”, „Kaspersky Anti-Virus”, „ESET SSL Filter CA”) statt einer öffentlichen CA wie DigiCert, Let’s Encrypt oder Sectigo, ist die SSL-Inspektion aktiv.
3. Suchen Sie in Ihren Antiviren- oder Firewall-Einstellungen nach HTTPS-Scanning, SSL-Filterung oder Web Shield und deaktivieren Sie es.
4. Alternativ fügen Sie das Root-CA-Zertifikat des Geräts zum Vertrauensspeicher Ihres Browsers hinzu.

Deaktivieren Sie Ihre Sicherheitssoftware nicht dauerhaft. Aktivieren Sie sie nach dem Testen wieder oder konfigurieren Sie sie so, dass bestimmte vertrauenswürdige Domains ausgeschlossen werden.

Schritt 4: Serverseitige Zertifikatskette überprüfen und reparieren (Serveradministratoren)

Dies ist die richtige Lösung für Produktionswebsites, bei denen Besucher den Fehler sehen.

Kette diagnostizieren:

“`bash

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

“`

Oder verwenden Sie die vollständige Kettenprüfung:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts

“`

Zählen Sie die zurückgegebenen Zertifikate. Sie sollten mindestens zwei sehen (End-Entity + Zwischenzertifikat). Wenn nur eines erscheint, fehlt das Zwischenzertifikat.

Lösung in Apache (`httpd.conf` oder Virtual-Host-Datei):

“`apache

SSLCertificateFile /etc/ssl/certs/yourdomain.crt

SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

“`

Lösung in Nginx (`nginx.conf` oder Serverblock):

Nginx erfordert, dass die vollständige Kette in einer einzigen Datei verkettet wird:

“`bash

cat yourdomain.crt intermediate.crt > fullchain.pem

“`

Dann referenzieren Sie sie:

“`nginx

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

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

“`

Testen Sie nach der Bearbeitung immer die Konfiguration, bevor Sie neu starten:

“`bash

Apache

apachectl configtest

Nginx

nginx -t

“`

Dann laden Sie den Dienst neu:

“`bash

sudo systemctl reload apache2

or

sudo systemctl reload nginx

“`

Wenn Sie eine verwaltete Umgebung betreiben, bietet ein VPS mit cPanel eine GUI-Oberfläche unter SSL/TLS Manager, wo Sie das Zertifikat, den privaten Schlüssel und das CA-Bundle direkt einfügen können, ohne Konfigurationsdateien manuell zu bearbeiten.

Schritt 5: Abgelaufenes Zertifikat erneuern oder ersetzen

Wenn das Zertifikat abgelaufen ist, gibt es keine clientseitige Umgehungslösung. Der Server muss ein gültiges Zertifikat präsentieren.

Für Let’s Encrypt (Certbot):

“`bash

sudo certbot renew –dry-run

sudo certbot renew

sudo systemctl reload nginx # or apache2

“`

Für manuell verwaltete Zertifikate: Beziehen Sie ein neues Zertifikat von Ihrer CA, laden Sie es über Ihr Kontrollpanel hoch und stellen Sie sicher, dass die Kette des neuen Zertifikats vollständig ist. Wenn Sie ein vertrauenswürdiges Zertifikat für eine Produktionsdomain benötigen, beseitigen SSL-Zertifikate von einer anerkannten CA das Problem mit selbstsignierten Zertifikaten vollständig.

Erneuerungen automatisieren: Let’s Encrypt-Zertifikate laufen alle 90 Tage ab. Fügen Sie einen Cron-Job hinzu oder verwenden Sie systemd-Timer, um die Erneuerung zu automatisieren:

“`bash

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

“`

Schritt 6: Selbstsigniertes Zertifikat für den internen Gebrauch vertrauen

Wenn Sie interne Tools, einen Entwicklungsserver oder einen privaten Netzwerkdienst betreiben, bei dem das Ersetzen des Zertifikats nicht möglich ist, können Sie das selbstsignierte Zertifikat zum OS-Vertrauensspeicher hinzufügen.

Windows:

1. Exportieren Sie das Zertifikat aus dem Browser (klicken Sie auf die Warnung > Zertifikat > Details > In Datei kopieren).
2. Öffnen Sie `certmgr.msc`.
3. Navigieren Sie zu Vertrauenswürdige Stammzertifizierungsstellen > Zertifikate.
4. Rechtsklick > Alle Aufgaben > Importieren und importieren Sie das Zertifikat.

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

“`

Wichtig: Chrome unter Linux und Windows verwendet den OS-Vertrauensspeicher für die meisten Zwecke, pflegt aber auch seine eigene NSS-Datenbank. Wenn Chrome das Zertifikat nach der Aktualisierung des OS-Speichers immer noch ablehnt, importieren Sie es direkt über `chrome://settings/certificates`.

Schritt 7: Browser und Betriebssystem aktualisieren

Ein veralteter Browser verfügt möglicherweise nicht über neuere Root-CA-Zertifikate oder unterstützt möglicherweise keine aktuellen TLS-Protokollversionen (TLS 1.2 als Minimum ist jetzt erforderlich; TLS 1.3 wird bevorzugt).

Chrome: Navigieren Sie zu `chrome://settings/help`. Chrome aktualisiert sich automatisch; wenn ein Update aussteht, wird es hier installiert.

Firefox: Navigieren Sie zu Hilfe > Über Firefox. Firefox sucht nach Updates und wendet sie an.

Betriebssystem: Stellen Sie unter Windows sicher, dass Windows Update aktuell ist. Führen Sie auf Linux-Servern aus:

“`bash

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

“`

Dies ist besonders wichtig für Server, die ältere Distributionen betreiben, bei denen das CA-Bundle (Paket `ca-certificates`) nicht aktualisiert wurde, um neuere Root-CAs einzuschließen.

Schritt 8: Netzwerk-Stack zurücksetzen und DNS leeren

Netzwerkkonfigurationsfehler, beschädigte DNS-Caches oder veraltete Winsock-Einträge können gelegentlich zu TLS-Aushandlungsfehlern beitragen.

Windows (Eingabeaufforderung als Administrator ausführen):

“`cmd

netsh int ip reset

netsh winsock reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

“`

Starten Sie den Rechner nach Ausführung dieser Befehle neu.

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

“`

Schritt 9: Warnung umgehen (nur zum Testen)

Dies ist ausschließlich ein Diagnosewerkzeug, keine Lösung. Verwenden Sie es nur, um zu bestätigen, dass der Fehler zertifikatsbezogen und kein Netzwerk- oder Anwendungsproblem ist, oder wenn Sie während der Entwicklung auf einen bekannten sicheren internen Server zugreifen.

Chrome: Klicken Sie auf der Fehlerseite auf Erweitert, dann auf Weiter zu [Domain] (unsicher).

Firefox: Klicken Sie auf Erweitert, dann auf Risiko akzeptieren und fortfahren.

Umgehen Sie diese Warnung niemals auf Websites, die Authentifizierung, Zahlungen oder persönliche Daten verarbeiten. Die Warnung existiert, weil die Verbindung tatsächlich nicht verifiziert ist.

Überprüfung der Lösung

Validieren Sie das Ergebnis nach jeder serverseitigen Änderung mit diesen Tools, bevor Sie das Problem als gelöst erklären:

• SSL Labs SSL Test (`ssllabs.com/ssltest/`): Bietet eine vollständige Kettenanalyse, Protokollunterstützungsbewertung und identifiziert spezifische Konfigurationsschwächen.
• `openssl s_client`: Befehlszeilenverifizierung, die genau zeigt, was der Server während des TLS-Handshakes präsentiert.
• `curl -vI https://yourdomain.com`: Schnelle Prüfung, die TLS-Handshake-Details und das Zertifikatsvalidierungsergebnis anzeigt.
• `whatsmychaincert.com`: Diagnostiziert speziell fehlende Zwischenzertifikate.

Die richtige Hosting-Infrastruktur zur Vermeidung von Wiederholungen wählen

Viele Zertifikatsfehler entstehen durch Infrastrukturbeschränkungen und nicht durch Administratorfehler. Shared-Hosting-Umgebungen schränken manchmal die Konfiguration von Zertifikatsketten ein oder begrenzen den Zugriff auf Webserver-Konfigurationsdateien. Wenn Sie wiederholt auf Ketten- oder Erneuerungsprobleme stoßen, gibt Ihnen die Migration zu einer VPS-Hosting-Umgebung die vollständige Kontrolle über Ihren TLS-Stack – einschließlich der Möglichkeit, Nginx oder Apache direkt zu konfigurieren, Certbot-Erneuerungen zu automatisieren und benutzerdefinierte CA-Bundles zu installieren.

Für hochfrequentierte oder compliance-sensible Workloads, bei denen das Zertifikatsmanagement kritisch ist, eliminieren Dedizierte Server die Mandantenvariablen, die die SSL-Konfiguration erschweren können. Wenn Sie mehrere Domains oder Subdomains verwalten, vereinfacht ein VPS-Kontrollpanel die Zertifikatsbereitstellung für alle über eine einzige Oberfläche.

Entscheidungsmatrix: Welche Lösung auf Ihre Situation zutrifft

Praktische Checkliste der wichtigsten Erkenntnisse

• Bestätigen Sie, ob der Fehler clientseitig (Uhr, Cache, SSL-Inspektion) oder serverseitig (abgelaufenes Zertifikat, fehlendes Zwischenzertifikat) ist, bevor Sie Maßnahmen ergreifen.
• Führen Sie `openssl s_client -connect domain:443 -showcerts` als ersten Diagnoseschritt bei jeder serverseitigen Untersuchung aus.
• Verketten Sie immer die vollständige Zertifikatskette (End-Entity + alle Zwischenzertifikate) in Ihrer Webserver-Konfiguration.
• Automatisieren Sie die Zertifikatserneuerung mit Certbot-Cron-Jobs oder äquivalenten Mitteln – manuelle Erneuerung ist ein garantierter Weg zu zukünftigen Ausfällen.
• Validieren Sie nach jeder Zertifikatsänderung mit SSL Labs, bevor Sie den Vorfall schließen.
• Deaktivieren Sie das SSL-Scanning von Antivirenprogrammen niemals dauerhaft; konfigurieren Sie stattdessen Ausnahmen oder installieren Sie das Proxy-CA-Zertifikat ordnungsgemäß.
• Halten Sie auf Linux-Servern die Pakete `ca-certificates` und `openssl` aktuell, um sicherzustellen, dass der Root-Speicher aktuelle vertrauenswürdige CAs widerspiegelt.
• Verwenden Sie `chrome://net-internals/#hsts`, um HSTS-Cache-Einträge zu löschen, wenn das Zertifikat einer Domain legitim geändert wurde und Chrome die Verbindung immer noch verweigert.

Häufig gestellte Fragen

Was ist der Unterschied zwischen NET::ERR_CERT_AUTHORITY_INVALID und NET::ERR_CERT_COMMON_NAME_INVALID?

`ERR_CERT_AUTHORITY_INVALID` bedeutet, dass der Aussteller des Zertifikats nicht vertrauenswürdig ist – die Kette kann nicht verifiziert werden. `ERR_CERT_COMMON_NAME_INVALID` bedeutet, dass das Zertifikat von einer vertrauenswürdigen CA stammt, aber für eine andere Domain ausgestellt wurde als die, auf die zugegriffen wird. Sie erfordern unterschiedliche Lösungen: Ersteres erfordert ein neues Zertifikat von einer vertrauenswürdigen CA oder eine Kettenreparatur; Letzteres erfordert ein Zertifikat, das mit den korrekten Subject Alternative Names neu ausgestellt wurde.

Kann NET::ERR_CERT_AUTHORITY_INVALID auch bei einem gültigen, kostenpflichtigen SSL-Zertifikat auftreten?

Ja. Ein kostenpflichtiges Zertifikat von einer vertrauenswürdigen CA löst diesen Fehler dennoch aus, wenn das Zwischenzertifikat nicht in der TLS-Antwort des Servers enthalten ist. Der Browser kann fehlende Zwischenzertifikate nicht immer automatisch abrufen (AIA-Abruf ist unzuverlässig), daher muss die Kette explizit auf dem Server konfiguriert werden.

Warum tritt dieser Fehler nur in Chrome, aber nicht in Firefox auf?

Firefox pflegt seinen eigenen Zertifikatsvertrauensspeicher und speichert auch Zwischenzertifikate aus früheren erfolgreichen Verbindungen zwischen (ein Mechanismus namens AIA-Abruf mit Caching). Chrome verlässt sich stärker auf den OS-Vertrauensspeicher und die vom Server präsentierte Kette. Ein fehlendes Zwischenzertifikat, das Firefox aus einer früheren Sitzung gecacht hat, führt bei Chrome dennoch zu einem Fehler.

Ist es sicher, bei der NET::ERR_CERT_AUTHORITY_INVALID-Warnung auf „Trotzdem fortfahren” zu klicken?

Nur in kontrollierten Szenarien: beim Zugriff auf einen bekannten internen Server, eine lokale Entwicklungsumgebung oder einen Staging-Server, den Sie verwalten. Auf jeder öffentlich zugänglichen Website – insbesondere solchen, die Anmeldedaten, Zahlungsinformationen oder persönliche Daten erfordern – ist das Fortfahren tatsächlich gefährlich. Die Verbindung ist aus einer Vertrauensperspektive unverschlüsselt, was bedeutet, dass jeder Abfänger auf dem Netzwerkpfad den Datenverkehr lesen oder ändern kann.

Wie verhindere ich, dass dieser Fehler auf meinem Produktionsserver erneut auftritt?

Automatisieren Sie die Zertifikatserneuerung (Certbot mit einem Cron-Job oder systemd-Timer), überwachen Sie den Zertifikatsablauf mit einem externen Tool (UptimeRobot, Zabbix oder `ssl-cert-check`), stellen Sie immer die vollständige Zertifikatskette bereit und halten Sie die NTP-Synchronisierung Ihres Servers aktiv. Für Umgebungen, in denen die manuelle Verwaltung fehleranfällig ist, sollten Sie eine Hosting-Plattform mit integriertem Zertifikatsmanagement in Betracht ziehen – ein VPS mit cPanel verwaltet AutoSSL-Erneuerungen automatisch für alle gehosteten Domains.