Anmelden

SSL-Zertifikatsfehler verstehen und beheben

Warum ein gültig aussehendes Zertifikat trotzdem abgewiesen wird

Ihre Website zeigt ein grünes Schloss. Ein Bezahldienst weist sie trotzdem ab. Das kommt häufiger vor, als man denkt – und es liegt fast immer an einem von sechs Fehlern.

SSL steht für Secure Sockets Layer, die Technik hinter dem Schloss-Symbol. Ein Zertifikat kann im Browser tadellos aussehen und beim strengen Gegenüber durchfallen – wie ein Reisepass, den der Hotelempfang anstandslos akzeptiert, die Grenzkontrolle aber zurückweist.

Metallkette mit einem offenen, unterbrochenen Glied – Sinnbild für eine zerrissene Vertrauenskette

Dieser Ratgeber nimmt sich die sechs häufigsten Fehler einzeln vor. Geht es Ihnen um die Ersteinrichtung von HTTPS – Installation, Weiterleitung, Mixed Content –, dann hilft Ihnen der Ratgeber HTTPS einrichten weiter. Hier geht es um die Fehler danach.

Gut zu wissen: Unser Audit bricht bei einem solchen Fehler nicht ab. Es prüft Ihre Seite vollständig und nennt den genauen Typ. Sie sehen also nicht nur, dass etwas klemmt, sondern was.

Häufige Fragen zu SSL-Zertifikatsfehler

Mein Zertifikat ist im Browser grün – warum meldet das Audit trotzdem einen Fehler?

Browser sind nachsichtig und laden fehlende Zwischenzertifikate oft selbst nach. Strenge Clients wie Bezahldienste oder Mailserver tun das nicht und lehnen ab. Unser Audit prüft so streng wie diese Dienste und sieht deshalb Fehler, die der Browser kaschiert. Meist ist die Kette unvollständig: Installieren Sie die Full-Chain-Datei statt nur des Serverzertifikats.

Wie behebe ich eine unvollständige Zertifikatskette?

Installieren Sie auf dem Server die vollständige Kette samt Zwischenzertifikaten, in der richtigen Reihenfolge: erst das Serverzertifikat, dann die Zwischenzertifikate. Bei Let's Encrypt ist das die Datei fullchain.pem, nicht cert.pem. In Apache über SSLCertificateFile, in Nginx über ssl_certificate. Nach dem Neuladen steht die Kette.

Was kostet ein vertrauenswürdiges SSL-Zertifikat?

Für die meisten Seiten nichts. Let's Encrypt stellt kostenlose, voll anerkannte Zertifikate aus und verlängert sie automatisch. Die meisten Hosting-Anbieter binden den Dienst mit einem Klick ein. Kostenpflichtige Varianten lohnen sich nur in Sonderfällen, etwa bei erweiterten Prüfstufen.

Was ist eine Zertifikatskette?

Ein Zertifikat steht nie allein. Es hängt in einer Kette: Ihr Nachweis wird von einem Zwischenzertifikat beglaubigt, dieses von einem Stammzertifikat – der obersten Stelle, der Browser und Betriebssysteme ab Werk vertrauen.

Die Reihenfolge zählt: Serverzertifikat, dann Zwischenzertifikat, dann Root. Nur wenn ein Client diese Kette lückenlos bis zur obersten Stelle verfolgen kann, vertraut er der Seite. Fehlt ein Glied, reißt die Kette. Dann nützt auch der beste eigene Nachweis nichts.

Browser sind nachsichtig. Chrome und Firefox laden fehlende Zwischenzertifikate oft selbst nach und zeigen das grüne Schloss trotzdem. Strenge Clients tun das nicht – Bezahldienste, Mailserver, Schnittstellen, ältere Geräte. Sie lehnen ab. Deshalb fällt so ein Fehler vielen erst auf, wenn plötzlich ein Dienst klemmt.

Unvollständige Zertifikatskette

In unseren Audits taucht dieser Fall am häufigsten auf. Der Server schickt nur den eigenen Nachweis, nicht die Zwischenzertifikate – die Kette zur obersten Stelle ist unterbrochen.

Im Browser läuft alles. Prüfdienste, Zahlungsanbieter und Mailserver dagegen melden einen Fehler. Die technische Meldung lautet meist unable to get local issuer certificate – dem Gegenüber fehlt also ein Glied.

Die Lösung ist ein Einzeiler in der Konfiguration. Installieren Sie auf dem Server die komplette Kette – die Full-Chain-Datei. Sie trägt Ihr Zertifikat plus alle Zwischenzertifikate in der richtigen Reihenfolge. Nicht nur das Serverzertifikat allein.

# Let's Encrypt liefert die fertige Kette gleich mit:
#   fullchain.pem  = Zertifikat + Zwischenzertifikate  (diese Datei nehmen!)
#   cert.pem       = nur das eigene Zertifikat        (NICHT allein verwenden)

# Apache
SSLCertificateFile      /pfad/fullchain.pem
SSLCertificateKeyFile   /pfad/privkey.pem

# Nginx
ssl_certificate         /pfad/fullchain.pem;
ssl_certificate_key     /pfad/privkey.pem;

Danach den Webserver neu laden. Ein erneutes Audit zeigt sofort, ob die Kette jetzt steht.

Selbstsigniertes Zertifikat

Hier hat das Zertifikat sich selbst ausgestellt, statt von einer anerkannten Stelle beglaubigt zu werden. Auf einem internen Testsystem ist das völlig in Ordnung. Öffentlich nicht.

Der Browser reagiert deutlich: eine ganzseitige Warnung, technisch self signed certificate. Der Grund ist einfach. Niemand außer dem Zertifikat selbst bürgt für seine Echtheit. Und Selbstauskunft zählt im Web nicht.

Tauschen Sie es gegen ein Zertifikat einer anerkannten Zertifizierungsstelle. Für die meisten Seiten ist das kostenlos und automatisiert – über Let's Encrypt.

# Certbot (Let's Encrypt) installiert und verlängert automatisch:
sudo certbot --apache    # oder: --nginx

Bei Managed Hosting geht es oft noch einfacher: ein Klick im Kundenbereich. Im Zweifel fragen Sie Ihren Anbieter.

Nicht vertrauenswürdige Zertifizierungsstelle

Die Kette ist vollständig, endet aber bei einer Stelle, der Browser und Betriebssysteme nicht vertrauen. Typisch bei firmeneigenen oder regionalen Ausstellern, deren Stammzertifikat in den gängigen Vertrauensspeichern fehlt.

Anders als beim selbstsignierten Fall liegt das Problem nicht bei Ihrem Zertifikat, sondern ganz oben in der Kette. Die technische Meldung: self signed certificate in certificate chain.

Setzen Sie auf einen öffentlich anerkannten Aussteller. Interne Zertifizierungsstellen ergeben nur dort Sinn, wo Sie das Stammzertifikat selbst auf alle Geräte verteilen können – im Firmennetz etwa. Fremde Geräte kennen Ihre Hausmarke nicht.

Falscher Domainname im Zertifikat

Technisch ist alles in Ordnung – nur der Name stimmt nicht. Das Zertifikat wurde für example.org ausgestellt, ausgeliefert wird es unter www.example.org oder einer Subdomain.

Der Browser meldet „Zertifikat für einen anderen Namen", technisch Hostname mismatch. Hier kennt er keine Gnade, und das aus gutem Grund: Ein Name, der nicht passt, könnte genauso gut von einem Angreifer stammen.

Maßgeblich ist das Namensfeld im Zertifikat. Früher war das der Common Name (CN), heute der Subject Alternative Name (SAN) – die Liste aller Domains, für die das Zertifikat gilt. Lassen Sie ein Zertifikat ausstellen, dessen SAN exakt jede Adresse enthält, unter der die Seite läuft. Mehrere Namen passen in ein Zertifikat: example.org und www.example.org gemeinsam, oder ein Wildcard-Zertifikat (*.example.org) für beliebige Subdomains. Ob HTTP sauber auf HTTPS umleitet, ist übrigens eine eigene Baustelle – mehr dazu in HTTPS einrichten.

Abgelaufenes Zertifikat

Jedes Zertifikat hat ein Ablaufdatum, moderne oft nur 90 Tage. Wird nicht rechtzeitig verlängert, gilt die Seite ab dem Stichtag als unsicher – schlagartig.

Gestern lief alles, heute kommt bei jedem Besucher eine Warnung: certificate has expired. Ein Datum, mehr braucht es nicht.

Verlängern Sie das Zertifikat. Und wichtiger noch: Schalten Sie die automatische Verlängerung ein, damit dieser Tag nie wiederkommt.

# Verlängerung testen (Let's Encrypt / Certbot):
sudo certbot renew --dry-run
# Danach läuft die Erneuerung unbeaufsichtigt per System-Timer.

Kostenpflichtiges Zertifikat ohne automatische Verlängerung? Dann hilft eine Erinnerung mehrere Wochen vor Ablauf. Ein Ablaufdatum verzeiht keine Vergesslichkeit.

Zertifikat ungültig oder nicht prüfbar

Bleibt der Sammelfall für alles Übrige. Hier ließ sich die Gültigkeit nicht eindeutig klären – etwa durch einen unvollständigen Verbindungsaufbau, eine veraltete Verschlüsselung oder ein widerrufenes Zertifikat.

Ein Sonderfall lohnt die Erwähnung: der Widerruf. Wird ein Zertifikat vorzeitig zurückgezogen – etwa weil der private Schlüssel in falsche Hände geriet –, melden Clients das über Prüfdienste wie OCSP. Das Papier ist dann zeitlich noch gültig, aber für ungültig erklärt.

Gehen Sie der Sache systematisch nach. Passt das Zertifikat zur hinterlegten Schlüsseldatei? Wurde es widerrufen? Läuft die Verbindung über eine aktuelle Verschlüsselung in Version 1.2 oder 1.3? Das zuständige Protokoll heißt Transport Layer Security, kurz der Nachfolger von Secure Sockets Layer. Ein Testdienst oder ein erneutes exatics-Audit zeigt Ihnen die konkrete Ursache.

Was prüft exatics?

Unser Audit baut eine echte verschlüsselte Verbindung zu Ihrer Seite auf und prüft so streng wie ein Bezahldienst – nicht so nachsichtig wie ein Browser. Findet es einen Defekt, läuft die Analyse trotzdem durch und nennt den Typ.

Geprüft wird:

  • Ist die Kette vollständig und in der richtigen Reihenfolge bis zur obersten Stelle?
  • Stammt das Zertifikat von einem öffentlich anerkannten Aussteller?
  • Deckt der Name (SAN) exakt die aufgerufene Adresse ab?
  • Ist das Zertifikat zeitlich gültig, und wie lange noch?
  • Läuft die Verbindung über eine aktuelle TLS-Version?

Zu jedem Befund bekommen Sie eine konkrete Anweisung – verständlich für Betreiber, mit den Details für Entwickler. Schwarz auf weiß.

Jetzt Ihr SSL-Zertifikat prüfen

Weiterführende Artikel

Vertiefende Fragen zu SSL-Zertifikatsfehler

Warum laufen moderne Zertifikate nur 90 Tage?

Kürzere Laufzeiten erhöhen die Sicherheit: Ein gestohlener Schlüssel ist schneller aus dem Verkehr, und die automatische Verlängerung wird zur Norm. Let's Encrypt setzt deshalb auf 90 Tage. Entscheidend ist, dass die Erneuerung läuft – testen Sie sie mit certbot renew --dry-run.

Was bedeutet ein widerrufenes Zertifikat?

Ein Aussteller kann ein Zertifikat vor dem Ablaufdatum zurückziehen, etwa wenn der private Schlüssel kompromittiert wurde. Clients prüfen den Status über Dienste wie OCSP. Ein widerrufenes Zertifikat ist zeitlich noch gültig, gilt aber als ungültig. Die Lösung ist ein frisch ausgestelltes; das alte lässt sich nicht reaktivieren.

Wann ist ein selbstsigniertes Zertifikat in Ordnung?

Nur dort, wo Sie das Stammzertifikat auf alle zugreifenden Geräte selbst verteilen – auf Testsystemen oder im abgeschlossenen Firmennetz. Für jede öffentlich erreichbare Seite ist ein selbstsigniertes oder von einer unbekannten Stelle ausgestelltes Zertifikat ungeeignet, weil fremde Geräte ihm nicht vertrauen.