Ein SSL-Zertifikatsfehler bedeutet, dass der Browser keine sichere Verbindung aufbauen konnte, der er vertraut. Er bricht deshalb ab und zeigt statt Ihrer Website eine Warnung. Die häufigsten Ursachen sind ein abgelaufenes Zertifikat (NET::ERR_CERT_DATE_INVALID), ein Zertifikat, das den Domainnamen nicht abdeckt (ERR_CERT_COMMON_NAME_INVALID), ein Zertifikat, dem der Browser nicht vertraut (ERR_CERT_AUTHORITY_INVALID), sowie ein Server, der eine unvollständige Zertifikatskette sendet oder veraltete TLS-Einstellungen nutzt. Fast alle lassen sich auf dem Server beheben, und der häufigste Fehler – der Ablauf – ist vollständig vermeidbar.
Dieser Leitfaden geht die Fehler durch, die Besucher tatsächlich sehen, erklärt die Ursachen und zeigt, wie Sie sie beheben – mit Befehlen, mit denen Sie Ihre eigene Website prüfen können.
Warum Browser die Seite blockieren
Wenn ein Browser sich über HTTPS verbindet, legt der Server ein Zertifikat vor. Bevor der Browser irgendetwas sendet, prüft er drei Dinge: ob das Zertifikat innerhalb seines Gültigkeitszeitraums liegt, ob es für genau den Hostnamen in der Adressleiste ausgestellt wurde und ob es sich auf eine Zertifizierungsstelle zurückführen lässt, der der Browser vertraut. Schlägt eine dieser Prüfungen fehl, zeigt der Browser eine ganzseitige Warnung wie „Dies ist keine sichere Verbindung“. Die meisten Besucher springen an dieser Stelle ab. API-Clients und Apps zeigen gar keine Warnung, sondern verweigern die Verbindung – und Ihre Integration bricht.
Browser benennen dieselben Probleme unterschiedlich. So entsprechen sich die häufigsten Fehler:
ProblemChrome und EdgeFirefoxAbgelaufen oder noch nicht gültigNET::ERR_CERT_DATE_INVALIDSEC_ERROR_EXPIRED_CERTIFICATEFalscher HostnameNET::ERR_CERT_COMMON_NAME_INVALIDSSL_ERROR_BAD_CERT_DOMAINNicht vertrauenswürdiger Aussteller oder selbstsigniertNET::ERR_CERT_AUTHORITY_INVALIDSEC_ERROR_UNKNOWN_ISSUERProtokoll- oder Cipher-ProblemERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCHSSL_ERROR_NO_CYPHER_OVERLAP
Safari zeigt bei den meisten davon „Diese Verbindung ist nicht privat“, die Details finden Sie unter „Details einblenden“.
Sehen Sie sich zuerst das Zertifikat selbst an
Bevor Sie etwas ändern, prüfen Sie, was der Server tatsächlich sendet. Dieser Befehl zeigt die Gültigkeitsdaten des Zertifikats, den Subject und die Hostnamen, die es abdeckt:
echo | openssl s_client -connect northwind.shop:443 -servername northwind.shop 2>/dev/null \
| openssl x509 -noout -dates -subject -issuer -ext subjectAltName
Das Flag -servername ist wichtig. Server, die mehrere Websites hosten, wählen das Zertifikat anhand des Namens, den der Client anfragt – ohne das Flag sehen Sie womöglich das falsche. Um die gesamte Kette zu sehen, die der Server sendet, ergänzen Sie den ersten Befehl um -showcerts.
NET::ERR_CERT_DATE_INVALID
Das Zertifikat liegt außerhalb seines Gültigkeitszeitraums. Fast immer heißt das: Es ist abgelaufen. Seltener geht die Uhr auf dem Computer des Besuchers falsch, wodurch ein gültiges Zertifikat abgelaufen oder noch nicht gültig erscheint.
Typische Ursachen auf dem Server:
Die automatische Verlängerung funktioniert nicht mehr – nach einem Serverumzug, einem Wechsel des Webservers oder einer DNS-Änderung, die die Domain-Validierung unterbrochen hat.
Das Zertifikat wurde verlängert, aber der Webserver nie neu geladen, sodass er weiterhin das alte aus dem Speicher ausliefert.
Das Zertifikat wurde vor einem Jahr von Hand für eine Subdomain ausgestellt, an die niemand mehr denkt.
Ein Load Balancer, CDN oder zweiter Server hat noch das alte Zertifikat, während der Hauptserver schon das neue hat.
Lösung: Verlängern Sie das Zertifikat, installieren Sie es überall, wo es ausgeliefert wird, und laden Sie den Dienst neu. Mit Certbot zeigt Ihnen ein Probelauf, ob die Verlängerung funktioniert, bevor es darauf ankommt:
sudo certbot renew –dry-run
sudo systemctl reload nginx
Prüfen Sie das ausgelieferte Zertifikat danach erneut mit dem openssl-Befehl oben. Besucher sehen nicht die Datei auf der Festplatte, sondern das ausgelieferte Zertifikat.
Meldet nur ein einzelner Besucher den Fehler und das Zertifikat ist gültig, bitten Sie ihn, Datum und Uhrzeit auf seinem Gerät zu prüfen.
NET::ERR_CERT_COMMON_NAME_INVALID
Das Zertifikat ist gültig, aber nicht für diesen Hostnamen. Browser vergleichen die Adressleiste mit den Namen im Feld Subject Alternative Name des Zertifikats.
Häufige Ursachen:
Das Zertifikat deckt northwind.shop ab, aber nicht www.northwind.shop – oder umgekehrt.
Ein Wildcard-Zertifikat für *.northwind.shop wird auf shop.eu.northwind.shop verwendet. Ein Wildcard-Zertifikat deckt nur eine Ebene ab.
Eine neue Subdomain zeigt auf einen Server, der ein Standardzertifikat für eine andere Website ausliefert.
Ein DNS-Eintrag zeigt auf den falschen Server, etwa einen alten Host oder ein CDN ohne Zertifikat für Ihre Domain.
Lösung: Stellen Sie ein Zertifikat aus, das jeden Hostnamen enthält, den Sie ausliefern, oder ein eigenes pro Hostname, und prüfen Sie, ob jeder Server-Block bzw. jeder Virtual Host das richtige verwendet. Soll der Hostname gar nicht ausgeliefert werden, entfernen Sie seinen DNS-Eintrag.
NET::ERR_CERT_AUTHORITY_INVALID
Der Browser vertraut dem Aussteller des Zertifikats nicht. Ursachen:
Ein selbstsigniertes Zertifikat, oft ein Überbleibsel aus der Staging-Umgebung oder aus der Standardinstallation eines Control Panels.
Ein Zertifikat einer privaten oder internen Zertifizierungsstelle auf einer öffentlichen Website.
Eine unvollständige Kette bei manchen Clients, siehe unten.
Etwas zwischen Besucher und Server fängt die Verbindung ab, etwa ein Firmen-Proxy oder eine Antivirensoftware. In diesem Fall sehen nur einige Besucher den Fehler.
Lösung: Ersetzen Sie selbstsignierte und interne Zertifikate auf öffentlichen Websites durch eines von einer öffentlich vertrauenswürdigen Zertifizierungsstelle. Kostenlose Zertifikate von Let’s Encrypt und ähnlichen Diensten werden von allen gängigen Browsern akzeptiert.
Unvollständige Zertifikatskette
Ihr Zertifikat ist von einem Zwischenzertifikat signiert, das wiederum von einem Root-Zertifikat signiert ist, dem der Browser vertraut. Der Server muss Ihr Zertifikat und das Zwischenzertifikat senden. Sendet er nur Ihr Zertifikat, hängt das Ergebnis vom Client ab: Manche Desktop-Browser laden das fehlende Zwischenzertifikat selbst nach und zeigen keinen Fehler, während andere Browser, mobile Apps, curl und API-Clients scheitern. Deshalb zeigt sich dieses Problem oft als „bei mir geht’s, aber die Webhooks des Zahlungsanbieters schlagen fehl“.
curl meldet es so:
curl: (60) SSL certificate problem: unable to get local issuer certificate
Lösung: Konfigurieren Sie den Server mit der Datei der vollständigen Kette. Mit Certbot unter nginx heißt das fullchain.pem, nicht cert.pem:
ssl_certificate /etc/letsencrypt/live/northwind.shop/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/northwind.shop/privkey.pem;
ERR_SSL_PROTOCOL_ERROR und Cipher-Konflikte
Diese Fehler bedeuten, dass sich Browser und Server nicht auf eine sichere Kommunikation einigen konnten – noch bevor überhaupt ein Zertifikat geprüft wurde. Mögliche Ursachen sind ein Server, der nur alte Protokollversionen wie TLS 1.0 und 1.1 anbietet, die aktuelle Browser nicht mehr akzeptieren, ein falsch konfigurierter Port, der auf 443 einfaches HTTP spricht, eine fehlerhafte TLS-Konfiguration nach einem Upgrade oder eine Firewall bzw. ein Proxy, der den Handshake stört.
Lösung: Aktivieren Sie TLS 1.2 und TLS 1.3, verwenden Sie die modernen Cipher-Standards Ihres Webservers oder eines vertrauenswürdigen Konfigurationsgenerators und prüfen Sie, ob Port 443 tatsächlich TLS ausliefert. Eine bestimmte Protokollversion können Sie mit openssl testen:
openssl s_client -connect northwind.shop:443 -servername northwind.shop -tls1_2
Mixed Content
Mixed Content ist kein Zertifikatsfehler, wird von Besuchern aber oft so wahrgenommen. Die Seite lädt über HTTPS, aber einige Ressourcen wie Skripte, Bilder, Stylesheets oder iframes werden über einfaches HTTP angefordert. Browser blockieren unsichere Skripte und Frames vollständig, was Layout oder Funktionen beeinträchtigen kann, und zeigen die Seite unter Umständen ohne das übliche Sicherheitssymbol an.
Lösung: Ändern Sie fest eingetragene http://-URLs in Ihren Templates, Ihrer Datenbank und Ihren Einstellungen in https:// oder relative URLs. Bei WordPress stammt Mixed Content oft von alten URLs, die nach der Umstellung auf HTTPS noch im Beitragsinhalt stehen. Als Sicherheitsnetz weist der Header Content-Security-Policy: upgrade-insecure-requests Browser an, diese Ressourcen stattdessen über HTTPS anzufordern.
Damit Sie Mixed Content finden, bevor Ihre Besucher es tun, durchsucht das Broken-Link-Monitoring von Uptimecheck Ihre Website und ihre Sitemap jeden Tag und meldet Mixed Content und defekte Links Seite für Seite.
Zertifikatsfehler vermeiden
Die meisten Zertifikatsfehler sind Konfigurationsfehler, die Sie einmal beheben. Beim Ablauf ist das anders: Er kommt jedes Mal wieder, wenn ein Zertifikat das Ende seiner Laufzeit erreicht, und schlägt gern dann zu, wenn die Person, die die Verlängerung eingerichtet hat, längst nicht mehr da ist. Vorbeugung ist Routine, keine einmalige Reparatur:
Führen Sie eine Übersicht. Listen Sie jeden Hostnamen auf, der HTTPS ausliefert, einschließlich APIs, Admin-Bereichen, Staging und Kunden-Websites.
Automatisieren Sie die Verlängerung, wo immer es geht, und wissen Sie, wo sie noch manuell läuft.
Prüfen Sie das ausgelieferte Zertifikat nach jeder Änderung. Serverumzüge, neue Load Balancer und DNS-Änderungen sind genau die Momente, in denen Verlängerungen brechen.
Überwachen Sie die Ablaufdaten, damit Sie Wochen vor dem Ablauf eines Zertifikats erinnert werden – solange noch Zeit ist, eine fehlschlagende Verlängerung in Ruhe zu reparieren.
Behalten Sie auch die Domain und ihre Einträge im Blick. Eine abgelaufene Domain oder ein geänderter DNS-Eintrag unterbricht die Validierung und damit auch die Website.
Das SSL-Monitoring von Uptimecheck verfolgt das Ablaufdatum des Zertifikats, das auf jeder Domain und Subdomain ausgeliefert wird, die Sie über HTTPS überwachen, und schickt Erinnerungen an Ihre Alarmkanäle, bevor es abläuft. Es ist in jedem Tarif enthalten. Kombinieren Sie es mit dem Monitoring des Domain-Ablaufs und dem DNS-Monitoring, denn ein Zertifikat ist nur so zuverlässig wie die Domain und die Einträge dahinter. Unser Leitfaden zum Monitoring des SSL-Zertifikatsablaufs enthält eine vollständige Checkliste für die Verlängerung, und wenn der Browser Ihre Website nicht einmal findet, lesen Sie unseren Beitrag zu DNS_PROBE_FINISHED_NXDOMAIN.
Zusammenfassung
Jeder SSL-Fehler bedeutet, dass der Browser einer Verbindung nicht vertraut: weil das Zertifikat abgelaufen ist, für einen anderen Namen ausgestellt wurde, von jemandem signiert ist, den er nicht kennt, ohne seine Kette gesendet wird oder über ein Protokoll angeboten wird, das er nicht mehr akzeptiert. Prüfen Sie das ausgelieferte Zertifikat mit openssl, korrigieren Sie die Konfiguration, laden Sie den Server neu und prüfen Sie erneut. Und machen Sie den Ablauf dann zu einer Erinnerung statt zu einem Vorfall.
Uptimecheck erinnert Sie, bevor Zertifikate und Domains ablaufen, und alarmiert Sie, wenn Ihre Website nicht mehr antwortet. Testen Sie es 14 Tage kostenlos, ohne Kreditkarte.