NET::ERR_CERT_AUTHORITY_INVALID: Zertifizierungsstelle nicht vertrauenswürdig

So sieht die Meldung aus

Your connection is not private
Attackers might be trying to steal your information from cloud.example.com
NET::ERR_CERT_AUTHORITY_INVALID

Häufige Ursachen

• Das Zertifikat ist selbstsigniert, z. B. ein Standardzertifikat von einem Gerät, Router oder einer frischen Installation.
• Es stammt von einer internen CA, deren Root-Zertifikat auf dem Client nicht installiert ist.
• Der Server sendet nur das Endzertifikat ohne Zwischenzertifikat, und der Client kann es nicht nachladen.
• Ein Proxy, Virenscanner oder eine Firewall signiert HTTPS-Verkehr mit einem eigenen Root neu, den der Browser nicht kennt.
• Der falsche virtuelle Host antwortet, daher kommt ein Standardzertifikat statt deines.

Prüfen

1. Wer hat das Zertifikat ausgestellt, und für wen?
   echo | openssl s_client -connect cloud.example.com:443 -servername cloud.example.com 2>/dev/null | openssl x509 -noout -subject -issuerKopieren
2. Wie sieht die Kette aus?
   echo | openssl s_client -connect cloud.example.com:443 -servername cloud.example.com -showcerts 2>/dev/null | grep -E '^ *[0-9] s:|^ *i:'Kopieren
3. Was sagt die curl-Prüfung?
   curl -vI https://cloud.example.com 2>&1 | grep -iE 'issuer|verify|SSL certificate'Kopieren
4. Wählt der SNI-Name das richtige Zertifikat?
   echo | openssl s_client -connect cloud.example.com:443 -servername wrong.example.com 2>/dev/null | openssl x509 -noout -subjectKopieren

Lösung

• Sind Subject und Issuer gleich, ist das Zertifikat selbstsigniert. Für einen öffentlichen Host durch eines einer öffentlichen CA wie Let's Encrypt ersetzen.
• Bei einer internen CA das Root auf den Clients installieren. Unter Debian und Ubuntu: die .crt nach /usr/local/share/ca-certificates/ kopieren und sudo update-ca-certificates ausführen. Browser und Handys brauchen das Root im eigenen Speicher.
• Die volle Kette ausliefern: In nginx sollte ssl_certificate auf fullchain.pem zeigen, nicht auf cert.pem.
• Signiert ein Proxy den Verkehr neu, dessen Root auf dem Gerät vertrauen oder die Seite von der Prüfung ausnehmen.
• Prüfen, dass der richtige server_name das richtige Zertifikat hat, dann den Webserver neu laden.

Häufige Fragen

Ist es sicher, die Warnung wegzuklicken?

Nur bei einem Host, den du selbst betreibst und erkennst, in einem Netz, dem du vertraust. Sonst soll die Warnung einen Man-in-the-Middle verhindern, also nicht akzeptieren.

Warum klappt es in einem Browser und im anderen nicht?

Browser und Betriebssysteme haben eigene Vertrauensspeicher, und manche laden fehlende Zwischenzertifikate nach, andere nicht. Ein fehlendes Zwischenzertifikat ist eine häufige Ursache, wenn nur manche Clients scheitern.