„Ihre Verbindung ist nicht privat“: die Zertifikatswarnung

Was der Fehler bedeutet

Der Browser hat sich mit dem Server verbunden, der Server hat sein Zertifikat vorgezeigt, und der Browser hat ihm das Vertrauen verweigert. Chrome zeigt „Ihre Verbindung ist nicht privat“ mit einem Fehlercode darunter; Firefox „Warnung: Mögliches Sicherheitsrisiko erkannt“; Safari „Diese Verbindung ist nicht privat“. Die Website ist nicht gehackt und dein Rechner nicht infiziert; das Zertifikat, das der Server schickt, besteht die Prüfungen nicht, die ein Browser macht.

Der Fehlercode sagt dir, welche Prüfung gescheitert ist:

• NET::ERR_CERT_DATE_INVALID: Das Zertifikat ist abgelaufen, oder sein Startdatum liegt in der Zukunft (oder die Uhr des Besuchers geht falsch).
• NET::ERR_CERT_COMMON_NAME_INVALID: Das Zertifikat gilt für einen anderen Namen, zum Beispiel für www.example.com, aber nicht für example.com.
• NET::ERR_CERT_AUTHORITY_INVALID: Der Browser kann das Zertifikat nicht auf eine vertrauenswürdige Stelle zurückführen: selbst signiert, unbekannter Aussteller oder ein fehlendes Zwischenzertifikat.
• NET::ERR_CERT_REVOKED: Der Aussteller hat das Zertifikat zurückgezogen.
• SSL_ERROR_BAD_CERT_DOMAIN und SEC_ERROR_EXPIRED_CERTIFICATE sind die Firefox-Varianten des Namens- und des Datumsfehlers.

Häufige Ursachen

1. Das Zertifikat ist abgelaufen. Zertifikate von Let's Encrypt gelten 90 Tage; die automatische Erneuerung ist wochenlang gescheitert, und niemand hat es gemerkt, bis der Tag kam. Gekaufte Zertifikate laufen nach einem Jahr ab, und die Erinnerungsmail ging an eine alte Adresse.
2. Erneuert, aber nicht neu geladen. certbot hat das neue Zertifikat auf die Platte geschrieben, der Webserver liefert aber noch das alte aus dem Speicher, weil der Reload-Hook fehlt.
3. Falscher Name. Das Zertifikat deckt example.com ab, Besucher kommen aber über www.example.com, oder eine neue Subdomain wurde ohne Zertifikat angelegt.
4. Fehlendes Zwischenzertifikat. Der Server schickt nur sein eigenes Zertifikat, nicht die Kette. Desktop-Browser füllen die Lücke oft aus dem Cache; Smartphones und Apps scheitern.
5. Ein Uhrzeitproblem. Auf dem Rechner des Besuchers lässt ein falsches Datum jedes Zertifikat abgelaufen oder noch nicht gültig erscheinen. Auf dem Server bricht eine falsche Uhr die Erneuerung.
6. Ein CDN oder Proxy davor mit eigenem Zertifikat, das abgelaufen ist oder den Namen nicht abdeckt, während der Ursprungsserver in Ordnung ist.

Wenn du Besucher bist

Prüf zuerst Datum und Uhrzeit deines Rechners; eine leere Pufferbatterie oder eine abgeschaltete Zeitsynchronisation lässt jede Website scheitern. Dann probier ein anderes Netz. Erscheint die Warnung nur bei einer Website und auf jedem Gerät, ist das Zertifikat der Website das Problem, und der Betreiber muss es beheben. „Weiter zu … (unsicher)“ zu klicken ist bei einer Website, die du kennst, in Ordnung, nicht bei irgendetwas mit Login oder Zahlung.

Wenn es deine Website ist: zuerst prüfen

Lass den SSL Checker laufen. Er zeigt Ablaufdatum, die Namen, für die das Zertifikat gilt, und ob die Kette vollständig ist, von außen, ohne Browser-Cache. Dann auf deinem eigenen Server:

# was schickt der Server wirklich?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# was liegt auf der Platte?
sudo certbot certificates

# geht die Serveruhr richtig?
timedatectl

Sind die Daten auf der Platte neuer als die, die der Server schickt, hast du Fall 2: erneuert, aber nicht neu geladen.

Lösungen auf deinem eigenen Server

1. Mit certbot erneuern

sudo certbot renew
# oder, wenn renew „not yet due“ sagt, der Server aber ein altes Zertifikat liefert:
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # oder apache2

Scheitert die Erneuerung, steht der Grund in der Ausgabe. Die üblichen: Port 80 ist gesperrt oder wird irgendwohin umgeleitet, wo certbot es nicht erwartet (die HTTP-01-Challenge braucht /.well-known/acme-challenge/ über schlichtes HTTP erreichbar), der DNS-Eintrag zeigt auf einen anderen Server, oder nach vielen Fehlversuchen greift eine Ratenbegrenzung. Behebe die Ursache und lass sudo certbot renew --dry-run laufen, bis es durchgeht.

2. Den Reload automatisch machen

# Debian/Ubuntu: certbot richtet einen Timer ein; prüf ihn
systemctl list-timers | grep certbot

# Deploy-Hook, damit der Webserver das neue Zertifikat übernimmt
echo 'systemctl reload nginx' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh

3. Den fehlenden Namen ergänzen

sudo certbot --nginx -d example.com -d www.example.com -d shop.example.com --expand

Mit --expand wird das bestehende Zertifikat durch eines ersetzt, das alle aufgeführten Namen abdeckt.

4. Die Kette reparieren

Mit certbot zeigt der Webserver auf fullchain.pem, nie auf cert.pem:

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

Apache: SSLCertificateFile mit fullchain.pem. Bei einem gekauften Zertifikat lädst du das Zwischenzertifikat („CA-Bundle“) beim Aussteller herunter und hängst es an die Zertifikatsdatei an. Mit sudo nginx -t testen, neu laden, dann die Kette mit dem SSL Checker prüfen.

5. Die Uhr stellen

sudo timedatectl set-ntp true
timedatectl

Ein Server, dessen Uhr mehr als ein paar Minuten abweicht, scheitert bei der Zertifikatsprüfung in beide Richtungen.

6. Shared Hosting oder Baukasten

Die meisten Hoster stellen Let's-Encrypt-Zertifikate im Kundenbereich aus und erneuern sie dort („SSL/TLS“, „Sicherheit“, „Let's Encrypt“). Öffne ihn, prüf, ob das Zertifikat example.com und www.example.com abdeckt, und klick auf Erneuern oder Neu ausstellen. Zeigt das Panel ein gültiges Zertifikat, während Browser widersprechen, hat der Hoster ein Reload- oder Kettenproblem auf seiner Seite.

Wenn es ein Problem deines Hosters ist

Guten Tag, seit etwa 06:00 Uhr (UTC) zeigen Browser für meine Website example.com „Ihre Verbindung ist nicht privat“ (NET::ERR_CERT_DATE_INVALID). Der Kundenbereich zeigt ein gültiges Zertifikat, der Webserver scheint also ein altes auszuliefern. Könnten Sie das Zertifikat auf dem Server neu laden und die automatische Erneuerung für meine Domain prüfen?

Damit es nicht wieder passiert

Ein abgelaufenes Zertifikat ist der eine Ausfall mit bekanntem Datum. Die SSL-Überwachung warnt dich vor dem Ablauf und noch einmal, wenn Kette oder Name nicht stimmen; 5 Prüfungen sind kostenlos. Auf deinem eigenen Server erneuert der Schnelleingriff das Zertifikat, wo certbot eingerichtet ist, und lädt den Webserver neu, zum Festpreis; der Intensiveingriff richtet die Erneuerung ein, wo es noch keine gibt.