„Ihre Verbindung ist nicht privat“ und „Dies ist keine sichere Verbindung“: was jeder NET::ERR_CERT-Code bedeutet und wie du den SSL-Fehler behebst

Kurz gesagt: „Dies ist keine sichere Verbindung“ in Chrome, „Ihre Verbindung ist nicht privat“ in Edge und „Diese Verbindung ist nicht privat“ in Safari bedeuten dasselbe: Das Zertifikat der Website hat eine Prüfung des Browsers nicht bestanden. Es ist abgelaufen (oder deine Uhr geht falsch), es stammt nicht von einer Zertifizierungsstelle (CA), der der Browser vertraut, oder es wurde für einen anderen Namen ausgestellt. Welcher Fall vorliegt, verrät der Code NET::ERR_CERT_… unter der Meldung. Als Besucher klickst du auf einer Website, auf der du dich anmeldest oder bezahlst, nicht einfach weiter. Als Betreiber ist die Lösung fast immer ein Let’s-Encrypt-Zertifikat, das jeden genutzten Namen abdeckt, mit seiner Kette ausgeliefert und automatisch erneuert wird.

Der Handshake selbst hat funktioniert; der Browser bricht ab, weil er nicht bestätigen kann, wer am anderen Ende sitzt. Ein Zertifikat, das die Prüfung nicht besteht, sieht genau so aus wie ein Angreifer zwischen dir und der Website. Deshalb beginnt Chrome mit dem Satz „Angreifer könnten versuchen, deine Informationen von … zu stehlen“, und Firefox schreibt „Warnung: Mögliches Sicherheitsrisiko erkannt“.

Was ist ein SSL-Fehler (TLS-Fehler)?

SSL ist der alte Name: Browser sprechen seit Jahren nur noch TLS, Fehlermeldungen und Alltagssprache sagen aber weiter SSL. Ein SSL- oder TLS-Fehler heißt, dass der verschlüsselte Verbindungsaufbau zwischen Browser und Server an einer von zwei Stellen gescheitert ist:

• Das Zertifikat besteht eine Prüfung nicht. Der Handshake klappt, aber Name, Aussteller oder Gültigkeit stimmen nicht. Das ist dieser Artikel: Codes, die mit NET::ERR_CERT_ beginnen, und eine Seite, auf der du (meist) trotzdem weiterklicken könntest.
• Der Handshake selbst bricht ab. Server und Browser einigen sich nicht auf Protokoll oder Verschlüsselung, oder auf Port 443 antwortet gar kein TLS. Dann meldet Chrome „Diese Website kann keine sichere Verbindung bereitstellen“, und es gibt keinen Weg vorbei. Das behandeln ERR_SSL_PROTOCOL_ERROR und SSL handshake failed (engl.).

Welchen Code siehst du?

Chrome zeigt den Code unter dem ersten Absatz. Das hier sind die Zertifikatscodes aus net_error_list.h von Chromium, denen du wirklich begegnest, jeweils mit dem Satz, den Chrome unter Erweitert zeigt, sinngemäß wiedergegeben:

Drei verwandte Seiten haben dieselbe Ursache, aber eine eigene Überschrift:

• „Deine Uhr geht nach“ oder „Deine Uhr geht vor“ (in älteren Chrome-Versionen „Ihre Uhr geht nach“ bzw. „vor“; englisch Your clock is behind bzw. Your clock is ahead): ein NET::ERR_CERT_DATE_INVALID, den Chrome auf die Uhr deines Geräts zurückgeführt hat.
• Eine Aufforderung, dich mit dem WLAN zu verbinden (englisch Connect to Wi-Fi): Ein Hotel- oder Flughafennetz hat die Verbindung abgefangen, um seine Anmeldeseite zu zeigen.
• Eine Meldung, dass eine Anwendung Chrome daran hindert, sich sicher mit der Website zu verbinden (englisch An application is stopping Chrome from safely connecting to this site): Antivirus, Firewall oder Filtersoftware prüft HTTPS, aber ihr Root-Zertifikat fehlt. Chrome nennt das Programm beim Namen.

Firefox nutzt für dieselben Fehler eigene Codes: SEC_ERROR_UNKNOWN_ISSUER, MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, SSL_ERROR_BAD_CERT_DOMAIN und SEC_ERROR_EXPIRED_CERTIFICATE. Zwei Dinge sehen ähnlich aus, sind aber andere Fehler. Eine Seite, die lädt, aber in der Adressleiste „Nicht sicher“ zeigt, ist reines HTTP oder gemischter Inhalt, kein Zertifikatsfehler. Und „Diese Website kann keine sichere Verbindung bereitstellen“ bedeutet, dass der Handshake selbst gescheitert ist; das steht in unserer Anleitung zu ERR_SSL_PROTOCOL_ERROR.

Solltest du auf „Weiter zu … (unsicher)“ klicken?

Nicht auf einer Website, auf der du dich anmeldest, bezahlst oder etwas Privates eintippst, und nie in einem öffentlichen WLAN. Die Warnung kann einen falsch eingerichteten Server nicht von einem Angreifer unterscheiden, und du kannst es anhand der Seite auch nicht. Eine Banking-Website mit ungültigem Zertifikat ist ein Grund, den Tab zu schließen und es später aus einem anderen Netz erneut zu versuchen.

Auf vielen großen Websites fehlt der Link sogar ganz. Eine Website mit HSTS hat deinem Browser gesagt, nur ein gültiges Zertifikat zu akzeptieren, also meldet Chrome, dass du die Website gerade nicht aufrufen kannst, weil sie HSTS verwendet, und bietet keinen Weg vorbei. Ein widerrufenes Zertifikat wird genauso behandelt. Das ist Absicht, kein Fehler.

Lösungen für Besucher: wenn nur du den Fehler siehst

Funktioniert die Website auf deinem Handy über mobile Daten, ist mit ihr alles in Ordnung. Prüf dann auf dem Gerät, das scheitert:

• Datum und Uhrzeit. Zertifikate werden gegen deine Uhr geprüft. Eine Uhr, die um Tage falsch geht, oft nach einer leeren CMOS-Batterie oder bei Dual-Boot, bricht HTTPS überall. Schalte die automatische Zeit in den Systemeinstellungen ein; unter Linux sollte timedatectl status die Zeile System clock synchronized: yes zeigen, und sudo timedatectl set-ntp true schaltet die Synchronisierung ein.
• Eine WLAN-Anmeldeseite. Hotels, Züge und Flughäfen fangen deine erste Anfrage ab, um ihre Nutzungsbedingungen zu zeigen. Öffne eine reine HTTP-Website wie http://neverssl.com, um die Anmeldeseite zu bekommen, bestätige sie und versuch es dann erneut.
• HTTPS-Scan im Antivirus, Firmen-Proxys, Jugendschutzfilter, manche VPNs. Sie ersetzen das Zertifikat jeder Website durch ein eigenes. Klick auf einer funktionierenden Website auf das Symbol links neben der Adresse, dann auf Verbindung ist sicher und Zertifikat ist gültig. Ist der Aussteller dein Antivirus, dein Arbeitgeber oder deine Schule statt einer öffentlichen CA, wird jede HTTPS-Verbindung mitgelesen; schalte die Scan-Option für einen Test ab oder frag deine IT-Abteilung.
• Ein altes Gerät. Systeme ohne Updates kennen neuere Root-Zertifikate nicht und scheitern an Websites, deren CA ihnen fremd ist. Aktualisiere Betriebssystem und Browser; auf einem nicht mehr unterstützten System bringt Firefox einen eigenen Zertifikatsspeicher mit.

Cache leeren und SSL-Status löschen in den Windows-Internetoptionen ändern selten etwas: Das Zertifikat wird bei jeder Verbindung neu geprüft. Scheitern viele Websites auf einmal, liegt es an der Uhr oder an einem Programm, das HTTPS abfängt; scheitert eine Website überall, liegt es an der Website.

Für Betreiber: das Zertifikat lesen, das dein Server ausliefert

Schau dir an, was der Server tatsächlich ausliefert, und zwar von außen, nicht die Dateien auf der Platte. Der erste Befehl führt dieselben Prüfungen aus wie ein Browser, einschließlich des Hostnamens; der zweite gibt Namen, Aussteller und Daten aus:

openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com -brief </dev/null 2>&1 | grep -E 'Verification|verify error'

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Ersetze jedes example.com durch den Namen, der scheitert, auch www, falls es dieser ist. Unter macOS installierst du vorher OpenSSL 3 mit Homebrew; dem eingebauten LibreSSL fehlen -brief und -verify_hostname. Eine gesunde Website gibt Verification: OK aus. Die Testhosts von badssl.com führen jeden Fall einzeln vor; mit OpenSSL 3.0 lauten die Meldungen so, daneben der Code, den Chrome für denselben Host zeigt:

Unser SSL-Checker (engl.) führt denselben Handshake von Amsterdam aus durch und meldet Ablaufdatum, Namensübereinstimmung, ob die Kette vertrauenswürdig ist, und die Zertifikate genau so, wie dein Server sie geschickt hat. Hinter Cloudflare sieht er das Zertifikat von Cloudflare, nicht deines.

Ursache 1: ein selbst signiertes oder Platzhalter-Zertifikat

Ein frischer Server beantwortet HTTPS oft mit einem Zertifikat, dem niemand vertraut: dem Snakeoil-Zertifikat aus Debians Paket ssl-cert, das Apaches Site default-ssl nutzt, einem von einem Control Panel erzeugten oder einem von Hand mit openssl req -x509 gebauten. Browser antworten mit NET::ERR_CERT_AUTHORITY_INVALID. Hol dir ein echtes; mit nginx und certbot ist das ein einziger Befehl, sobald die DNS-Einträge auf den Server zeigen und Port 80 offen ist:

sudo apt update && sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot holt das Zertifikat, schreibt die ssl_certificate-Zeilen in den passenden Server-Block und lädt nginx neu. Gib jeden Namen an, den Besucher nutzen, jeweils mit eigenem -d.

Ursache 2: das Zertifikat gilt für einen anderen Namen

NET::ERR_CERT_COMMON_NAME_INVALID heißt, der Name in der Adressleiste steht nicht in der Liste der Subject Alternative Names (SAN) des Zertifikats. Browser ignorieren das alte Feld Common Name, maßgeblich ist allein die SAN-Zeile aus dem Befehl oben. Für wrong.host.badssl.com lautet sie:

subject=CN = *.badssl.com
issuer=C = US, O = Let's Encrypt, CN = YR1
notBefore=Sep 29 20:02:56 2026 GMT
notAfter=Dec 28 20:02:55 2026 GMT
X509v3 Subject Alternative Name:
    DNS:*.badssl.com, DNS:badssl.com

Ein Wildcard-Zertifikat deckt genau eine Ebene ab: *.badssl.com passt auf wrong.badssl.com, aber nicht auf wrong.host.badssl.com. Die üblichen Fälle auf einem selbst betriebenen Server:

• www oder die Apex-Domain fehlt. example.com und www.example.com sind zwei Namen. Ergänze den fehlenden: sudo certbot --nginx -d example.com -d www.example.com --expand.
• Aufruf des Servers per IP. https://203.0.113.10/ scheitert an einem Zertifikat für eine Domain. Nutze den Namen.
• Der falsche Server-Block antwortet. Ein Name ohne passenden server_name in einem 443-Block landet beim Standardserver von nginx und dessen Zertifikat. Prüf, ob die listen-Zeilen für IPv4 und IPv6 beide im richtigen Block stehen.
• Das DNS zeigt woandershin. Ein alter A- oder AAAA-Eintrag schickt manche Besucher zu einem früheren Host, der sein eigenes Zertifikat ausliefert. Vergleiche dig +short example.com A und AAAA mit den Adressen deines Servers.

Ursache 3: das Zertifikat ist abgelaufen

Let’s-Encrypt-Zertifikate gelten 90 Tage, und certbot erneuert sie, wenn noch etwa 30 übrig sind. Ein abgelaufenes Zertifikat heißt also, dass die Erneuerung seit Wochen scheitert, oder dass sie geklappt hat und nginx die neue Datei nie geladen hat. Prüf beides:

# Was certbot auf der Platte hat, mit Ablaufdatum
sudo certbot certificates

# Würde eine Erneuerung jetzt klappen? (nutzt die Staging-CA, ändert nichts)
sudo certbot renew --dry-run

# Ist der Erneuerungs-Timer geplant? (certbot.timer oder snap.certbot.renew.timer)
systemctl list-timers | grep -i certbot

Ist die Datei auf der Platte neuer als das Datum, das der Server ausliefert, lade nginx neu: sudo nginx -t && sudo systemctl reload nginx. Bei Zertifikaten, die mit --nginx installiert wurden, lädt certbot nginx nach der Erneuerung selbst neu; bei --webroot oder --standalone brauchst du einen Deploy-Hook. Ein gescheiterter Probelauf nennt meist einen geschlossenen Port 80 oder einen DNS-Eintrag, der nicht mehr hierher zeigt.

Den Deploy-Hook und die kürzeren Laufzeiten von Let’s Encrypt ab 2027 erklärt unsere Anleitung zu SSL handshake failed (engl.).

Ursache 4: ein Cloudflare-Origin-CA-Zertifikat, direkt aufgerufen

Einem Origin-CA-Zertifikat von Cloudflare vertraut nur Cloudflare. Hinter der orangen Wolke ist das in Ordnung, weil Besucher das Edge-Zertifikat von Cloudflare sehen. Laut der Origin-CA-Dokumentation von Cloudflare bekommen Besucher Fehler wegen eines nicht vertrauenswürdigen Zertifikats, sobald du Cloudflare pausierst oder einen Eintrag auf „DNS only“ stellst. Das ergibt NET::ERR_CERT_AUTHORITY_INVALID, und als Aussteller steht im Zertifikat CloudFlare Origin SSL Certificate Authority (oder sein ECC-Zwilling). Schalte den Proxy wieder ein, oder ersetze das Zertifikat durch eines von Let’s Encrypt, das in beiden Fällen funktioniert.

Ursache 5: das Zwischenzertifikat fehlt

Zeigt nginx auf cert.pem statt auf fullchain.pem, schickt der Server sein eigenes Zertifikat ohne das Zwischenzertifikat, das es mit einem vertrauenswürdigen Root-Zertifikat verbindet. Chrome auf dem Desktop holt das fehlende Stück meist selbst nach, und Firefox bringt bekannte Zwischenzertifikate mit, deshalb sieht die Website in deinem Browser oft gut aus, während curl, Python, Java, Zahlungs-Webhooks und manche Handys mit unable to get local issuer certificate scheitern. Die Lösung ist ein einziges Wort:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;   # nicht cert.pem
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Deine eigenen Admin-Panels

Proxmox, Webmin, Cockpit, Router und NAS-Geräte kommen mit selbst signierten Zertifikaten, NET::ERR_CERT_AUTHORITY_INVALID ist auf ihren Ports also zu erwarten. Statt dir das Durchklicken anzugewöhnen, erreichst du sie besser über einen SSH-Tunnel, oder du stellst sie hinter nginx unter einem echten Namen mit Let’s-Encrypt-Zertifikat, beschränkt auf deine IP.

Für https://localhost in der Entwicklung nimm mkcert: mkcert -install trägt eine lokale CA in die Zertifikatsspeicher von System und Browser ein, und mkcert localhost 127.0.0.1 ::1 stellt ein Zertifikat aus, das dein Dev-Server laden kann. Das Flag allow-insecure-localhost, das ältere Anleitungen empfehlen, gibt es im aktuellen Chrome nicht mehr.

Nach der Behebung

• Der s_client-Befehl von oben gibt für jeden Namen, Apex-Domain und www, Verification: OK aus, von einem Rechner außerhalb des Servers.
• certbot renew --dry-run klappt, und der Timer ist aufgeführt.
• Ports 80 und 443 bleiben offen: Die Erneuerung mit HTTP-Challenge braucht Port 80. Unsere Anleitung zu Port 443 und 80 zeigt, wie du beide von außen testest.

Auf einem Linux VPS von VMHeaven betreibst du certbot und nginx als root, und falls dich eine Änderung aussperrt, erreicht die Browser-VNC-Konsole im Panel den Server trotzdem.

Häufige Fragen