ERR_CERT_AUTHORITY_INVALID: Ursachen und wie Sie den Fehler beheben

ERR_CERT_AUTHORITY_INVALID bedeutet, dass der Browser keine Vertrauenskette von dem Zertifikat, das Ihr Server ausgeliefert hat, zu einer Stammzertifizierungsstelle aufbauen konnte, der er bereits vertraut. Chrome zeigt den Fehler als NET::ERR_CERT_AUTHORITY_INVALID unter dem Bildschirm "Ihre Verbindung ist nicht privat". Er weist fast nie darauf hin, dass Ihr Zertifikat abgelaufen ist, sondern fast immer auf eines von zwei Dingen: Ihr Server sendet sein Zwischenzertifikat nicht, oder das Zertifikat stammt gar nicht von einer öffentlich vertrauenswürdigen CA. Die Behebung dauert Minuten, sobald Sie wissen, auf welcher Seite der Fehler liegt.

Was der Fehler tatsächlich bedeutet

Jedes TLS-Zertifikat wird validiert, indem eine Kette abgelaufen wird. Der Browser erhält das Serverzertifikat (das Endzertifikat), liest aus, welche CA es signiert hat, und sucht diese CA. Ist die signierende CA ein Zwischenzertifikat, benötigt der Browser auch dieses, um zu prüfen, wer dieses signiert hat, und so geht es weiter, bis er ein Stammzertifikat erreicht, das bereits in seinem Vertrauensspeicher installiert ist.

Fehlt ein Glied dieser Kette, ist es nicht von einer vertrauenswürdigen Stelle signiert oder stammt es von einer CA, die der Browser entfernt hat, lässt sich die Kette nicht schließen und die Verbindung wird mit ERR_CERT_AUTHORITY_INVALID abgelehnt.

Chrome liefert mit dem Chrome Root Store seine eigene Vertrauensliste aus, statt sich allein auf das Betriebssystem zu verlassen. Firefox macht dasselbe. Safari und Edge stützen sich auf den Speicher des Betriebssystems. Dieser Unterschied erklärt, warum eine Website in einem Browser scheitern und im anderen auf demselben Rechner laden kann, und er ist eines der nützlichsten Diagnosesignale, die Sie haben.

Die sieben Ursachen, und wo der Fehler liegt

Ursache 1 und 2 machen die überwältigende Mehrheit der realen Meldungen aus. Wenn die Website Ihnen gehört, fangen Sie dort an.

Die 30-Sekunden-Diagnose

Bevor Sie irgendetwas ändern: Klären Sie, ob das Problem auf dem Server oder auf dem Rechner des Besuchers liegt.

1. Öffnen Sie die Website über Mobilfunk, auf einem Telefon, das sie nie besucht hat. Scheitert sie dort, funktioniert aber auf Ihrem Rechner, fehlt ein Zwischenzertifikat. Desktop-Browser speichern bereits gesehene Zwischenzertifikate zwischen und reparieren eine kaputte Kette still, weshalb dieser Fehler so lange unentdeckt überlebt.
2. Probieren Sie einen zweiten Browser auf demselben Rechner. Scheitert es nur in Chrome, deutet das darauf hin, dass der Chrome Root Store die CA ablehnt. Scheitert alles auf einem Rechner, deutet das auf Aufbruch oder ein veraltetes Gerät hin.
3. Klicken Sie auf die Warnung, dann auf "Erweitert", und lesen Sie den Aussteller. Ist der Aussteller Ihr Virenscanner, ein Firewall-Anbieter oder der Name Ihres Arbeitgebers, wird der Verkehr aufgebrochen und neu signiert. Das ist Ursache 4, und Ihre Website trifft daran keine Schuld.
4. Prüfen Sie die Kette auf der Kommandozeile mit OpenSSL:

openssl s_client -connect beispiel.de:443 -servername beispiel.de -showcerts

Sie sollten mindestens zwei Zertifikate in der Ausgabe sehen: Ihr Endzertifikat und danach ein oder mehrere Zwischenzertifikate. Kommt nur ein Zertifikat zurück, fehlt das Zwischenzertifikat und Sie haben den Fehler gefunden.

Lösung 1: Die vollständige Zertifikatskette installieren

Das ist mit Abstand die häufigste serverseitige Ursache. Ihre CA stellt Ihnen ein Endzertifikat und ein oder mehrere Zwischenzertifikate aus, und Ihr Server muss sie alle senden. Verweisen Sie Ihren Webserver auf die vollständige Kette statt nur auf das Endzertifikat.

Wenn Sie Let's Encrypt nutzen, ist die Lösung meist ein einziges Wort: Verwenden Sie fullchain.pem, niemals cert.pem. Let's Encrypt weist darauf hin, dass jedes ausgestellte Zertifikat ein Zwischenzertifikat besitzt, das direkt von der am weitesten verbreiteten Wurzel signiert ist, und dass mehrere aktive Zwischenzertifikate im Lauf der Zeit rotieren. Eine bestimmte Zwischenzertifikatsdatei fest zu verdrahten ist deshalb fragil (Let's Encrypt, Chains of Trust). Laden Sie den Server nach der Änderung neu; eine Konfigurationsänderung bewirkt nichts, solange der Prozess sie nicht einliest.

Lösung 2: Ein selbstsigniertes Zertifikat ersetzen

Ein selbstsigniertes Zertifikat signiert sich selbst. Keine öffentliche CA bürgt dafür, also kann kein Browser ihm ohne manuellen Eingriff jemals vertrauen. Das ist korrektes Verhalten, kein Fehler.

Für alles öffentlich Erreichbare: Holen Sie sich ein kostenloses Zertifikat von einer öffentlich vertrauenswürdigen CA und automatisieren Sie die Erneuerung. Für wirklich interne Werkzeuge: Fügen Sie entweder Ihre interne Wurzel den Vertrauensspeichern der betroffenen Geräte hinzu, oder stellen Sie über eine interne CA aus, die Ihr Gerätemanagement ohnehin verteilt. Gewöhnen Sie Ihr Team nicht daran, die Warnung wegzuklicken; genau auf diese Gewohnheit setzen Phishing-Betreiber.

Lösung 3: Aufbruch und veraltete Geräte ausschließen

Ist der in der Warnung angezeigte Aussteller ein Virenscanner, deaktivieren Sie dessen HTTPS- oder SSL-Prüfung vorübergehend und laden Sie neu. Viele Sicherheitspakete schieben eine eigene Wurzel ein, um verschlüsselten Verkehr zu inspizieren, und eine defekte oder abgelaufene Inspektionswurzel legt alle HTTPS-Seiten gleichzeitig lahm.

Auf einem veralteten Gerät: Installieren Sie ausstehende Betriebssystem-Updates. Wurzelspeicher kommen mit Systemupdates, und einem Gerät, das mehrere Jahre zurückliegt, fehlen neuere Wurzeln vollständig. Prüfen Sie zuletzt die Uhr: Ein völlig falsches Systemdatum kann eine gültige Wurzel als noch nicht gültig erscheinen lassen, was sich als Aussteller- statt als Datumsfehler zeigt.

Lösung 4: Prüfen, ob Ihrer CA noch vertraut wird

Wurzelprogramme entfernen CAs, die ihre Anforderungen nicht erfüllen, und diese Entfernungen sind reale Ereignisse mit realen Fristen. Das Chrome Root Program verlangt, dass neu ausgestellte öffentliche TLS-Zertifikate ab dem 15. Juni 2026 ausschließlich die erweiterte Schlüsselverwendung serverAuth tragen; Zertifikate, die zusätzlich clientAuth tragen, werden von Chrome nicht mehr als vertrauenswürdig eingestuft, und CA-Betreiber, deren Hierarchien das nicht erfüllen, müssen umbauen oder den Speicher verlassen (Chrome Root Program Policy).

Scheitert eine Website plötzlich in Chrome, während ältere Clients sie weiterhin akzeptieren, ist ein Vertrauensentzug eine realistische Erklärung. Abhilfe schafft eine Neuausstellung bei einer konformen CA.

Warum dieser Fehler bald häufiger wird

Die Laufzeiten von Zertifikaten brechen ein. Nach dem im April 2025 angenommenen Beschluss SC-081v3 des CA/Browser Forum sinkt die maximale Gültigkeitsdauer am 15. März 2026 von 398 auf 200 Tage, 2027 auf 100 Tage und 2029 auf 47 Tage (CA/Browser Forum, Ballot SC-081v3).

Maximale Laufzeit von TLS-Zertifikaten gemäß Beschluss SC-081v3 des CA/Browser Forum. Quelle: CA/Browser Forum, April 2025.

Mehr Erneuerungen bedeuten mehr Gelegenheiten, bei denen ein Automatisierungsskript ein Endzertifikat ohne sein Zwischenzertifikat ausrollt. Jede Erneuerung ist heute ein Deployment, und jedes Deployment kann die Kette zerreißen. Teams, die einmal jährlich von Hand erneuert und danach nie wieder daran gedacht haben, werden 2026 zum ersten Mal auf diesen Fehler stoßen.

Die Behebung überprüfen

Vertrauen Sie nach der Änderung nicht Ihrem eigenen Browser. Er hat das Zwischenzertifikat zwischengespeichert und zeigt Ihnen ein grünes Schloss über einer Kette, die für alle anderen weiterhin scheitert. Prüfen Sie von einem sauberen Aussichtspunkt aus: einem externen Scanner, einem Telefon im Mobilfunknetz oder einem frischen Browserprofil. Bestätigen Sie, dass Endzertifikat und sämtliche Zwischenzertifikate ausgeliefert werden und kein Zwischenzertifikat selbst abgelaufen ist.

Verwandte Leitfäden

• "Ihre Verbindung ist nicht privat": Was der Fehler bedeutet und wie Sie ihn beheben behandelt den übergeordneten Warnbildschirm, unter dem dieser Fehler erscheint.
• ERR_SSL_PROTOCOL_ERROR: Was der Fehler bedeutet und wie Sie ihn beheben behandelt Handshake-Fehler, die ähnlich aussehen, aber andere Ursachen haben.
• SSL/TLS-Zertifikatssicherheit: Vollständiger Leitfaden zur A+-Bewertung führt durch Kette, Protokolle und Cipher-Konfiguration von Anfang bis Ende.

Häufige Fragen

Ist ERR_CERT_AUTHORITY_INVALID für Besucher gefährlich? Es kann sein. Der Browser teilt Ihnen mit, dass er nicht überprüfen kann, mit wem er spricht, und genau diesen Zustand erzeugt ein Man-in-the-Middle-Angriff. Auf einer Website, die Sie nicht kontrollieren, nehmen Sie die Warnung ernst und fahren Sie nicht fort.

Warum funktioniert die Website auf meinem Rechner, aber nicht bei meinen Kunden? Desktop-Browser speichern Zwischenzertifikate früherer Besuche zwischen und können eine kaputte Kette aus dem Gedächtnis vervollständigen. Geräte, die das Zwischenzertifikat nie gesehen haben, können das nicht. Diese Asymmetrie ist die klassische Signatur eines fehlenden Zwischenzertifikats.

Hilft es, den Browser-Cache zu leeren? Selten, und nur wenn der Fehler auf dem Gerät liegt. Ist die Kette auf dem Server kaputt, ändert Cache-Leeren für niemanden etwas.

Worin unterscheidet er sich von ERR_CERT_COMMON_NAME_INVALID? AUTHORITY_INVALID bedeutet, dass dem Aussteller nicht vertraut werden kann. COMMON_NAME_INVALID bedeutet, dass dem Aussteller vertraut wird, das Zertifikat aber für einen anderen Hostnamen ausgestellt wurde als den aufgerufenen.

Kann ich die Warnung einfach wegklicken? Auf Ihrem eigenen Staging-Server ja. Auf jeder Website mit echten Daten nein. Wegklicken schaltet genau den Schutz ab, der Ihnen mitteilen würde, dass die Verbindung manipuliert wurde.

Prüfen Sie Ihre Kette, bevor Ihre Besucher es tun

Ein fehlendes Zwischenzertifikat ist vom eigenen Schreibtisch aus unsichtbar und für jeden neuen Besucher offensichtlich. Starten Sie einen kostenlosen FortifyNet-Scan und sehen Sie Ihre vollständige Zertifikatskette, Protokollunterstützung, Security-Header, DNS und E-Mail-Authentifizierung in etwa 60 Sekunden. Ohne Anmeldung.

---

Quellen: CA/Browser Forum, Ballot SC-081v3; Chrome Root Program Policy; Let's Encrypt, Chains of Trust.