Deine Website hat das Schloss im Browser, also „ist sie schon sicher". Das ist der Satz, den wir am häufigsten hören, und der irreführendste. Das Schloss sagt nur, dass ein gültiges Zertifikat für diese Domain existiert: Es sagt nichts darüber, welche Protokollversionen du akzeptierst, welche Cipher du aushandelst, ob die Kette vollständig ist oder wann es abläuft. Deshalb geben Analyse-Tools eine Note, von A+ bis F, und deshalb können zwei Websites mit Schloss an entgegengesetzten Enden stehen. Dieser Guide erklärt, was jeder Teil dieser Note misst, welche Konfiguration 2026 vernünftig ist und wie du deine mit zwei Befehlen prüfst.
Was eine TLS-Note bewertet
Seriöse Tools kombinieren sieben Prüfungen. Die ersten beiden sind K.-o.-Kriterien: Scheitern sie, fällt die Note auf F, ohne den Rest anzusehen.
- Gültiges Zertifikat: von einer anerkannten Stelle ausgestellt, für die richtige Domain, innerhalb der Gültigkeitsdauer.
- Vollständige Kette: Das Zwischenzertifikat, das deines mit der Stammstelle verbindet, wird mitgeschickt.
- Protokollversionen: welche TLS-Versionen du akzeptierst und welche du ablehnst.
- Cipher: welche Algorithmen du anbietest und in welcher Reihenfolge.
- Weiterleitung: ob HTTP auf der ganzen Website zu HTTPS führt.
- HSTS: ob du dem Browser sagst, nie wieder HTTP zu verwenden.
- Bekannte Schwachstellen: unsichere Neuverhandlung, Kompression, die Angriffe mit Eigennamen aus dem letzten Jahrzehnt.
Versionen: nur 1.2 und 1.3
TLS 1.0 und 1.1 sind seit 2020 veraltet, und Browser lehnen sie ab. Akzeptiert dein Server sie noch, sinkt die Note, weil ein Angreifer einen alten Client zwingen kann, sie zu nutzen. TLS 1.2 ist das akzeptable Minimum; TLS 1.3 der aktuelle Standard: weniger Hin und Her beim Verbinden, moderne Cipher verpflichtend und ohne die unsicheren Optionen der Vorgängerversionen. Die richtige Konfiguration heute ist, 1.2 und 1.3 zu akzeptieren und sonst nichts. Bei Vercel, Netlify, Cloudflare oder einem Managed Hosting ist das schon so; verwaltest du dein eigenes nginx oder einen Load Balancer, prüf es.
Cipher: was wirklich zählt
Der Cipher legt fest, wie der Schlüssel ausgetauscht und wie der Verkehr geschützt wird. Zwei Dinge machen den Unterschied. Das erste ist Perfect Forward Secrecy (die Cipher, die mit ECDHE beginnen): Stiehlt jemand in Zukunft deinen privaten Schlüssel, kann er den zuvor aufgezeichneten Verkehr nicht entschlüsseln. Das zweite ist, gebrochene oder schwache Algorithmen zu vermeiden: RC4, 3DES, die alten CBC-Modi und reinen RSA-Schlüsselaustausch. Eine vernünftige Liste für TLS 1.2 reduziert sich auf ECDHE mit AES-GCM oder ChaCha20; in TLS 1.3 erlaubt das Protokoll ohnehin nur moderne Cipher, ein Grund mehr, es zu aktivieren.
Die Zertifikatskette: der unsichtbare Fehler
Dein Zertifikat wird von einem Zwischenzertifikat signiert, und das Zwischenzertifikat von einer Wurzel, die die Geräte schon kennen. Der Server muss dein Zertifikat und das Zwischenzertifikat schicken. Vergisst du das Zwischenzertifikat, lädt Chrome am Desktop es selbst nach, und du siehst keinen Fehler; aber viele Handys, curl, KI-Bots und Zahlungsintegrationen scheitern mit „Zertifikat nicht vertrauenswürdig". Es ist der häufigste Fehler bei handkonfigurierten Servern und der am schwersten zu bemerkende, weil „bei mir funktioniert es". So prüfst du es:
openssl s_client -connect deinedomain.com:443 -servername deinedomain.com </dev/null 2>/dev/null | grep -E "s:|i:|Verify return"Es müssen mindestens zwei Zertifikate in der Kette erscheinen, und die Prüfung muss mit Verify return code: 0 (ok) enden.
Domain und alternative Namen
Das Zertifikat muss genau die Namen abdecken, die du nutzt: deinedomain.com und www.deinedomain.com sind zwei verschiedene Namen. Ein Zertifikat nur für die Root lässt www einen Fehler werfen, und umgekehrt. Aktuelle Zertifikate listen mehrere Namen im SAN-Feld, und Wildcards (*.deinedomain.com) decken Subdomains einer Ebene ab. Prüf auch die vergessenen Subdomains: api, app, staging mit abgelaufenen Zertifikaten sind ein Klassiker.
Ablauf: immer kürzer
Zertifikate von Let's Encrypt gelten 90 Tage, das heute von Browsern erlaubte Maximum sind 398, und die Branche hat vereinbart, es schrittweise auf 47 Tage im Jahr 2029 zu senken. Die Botschaft ist klar: Die Erneuerung muss automatisch laufen. Managed-Plattformen erledigen das selbst; hast du einen eigenen Server, nutz einen ACME-Client mit geplanter Erneuerung und vor allem einen externen Alarm, der dich warnt, wenn weniger als 14 Tage bleiben. Der Ausfall wegen abgelaufenem Zertifikat ist der dümmste und der häufigste.
Weiterleitung und HSTS
Der gesamte HTTP-Verkehr muss mit einem 301 auf HTTPS umleiten, auf allen Routen, nicht nur auf der Startseite. Und sobald alles über HTTPS läuft, sagt der Header Strict-Transport-Security dem Browser, HTTP für die von dir angegebene Zeit nicht mehr zu versuchen, was die kleine Lücke der ersten Anfrage schließt. Mit includeSubDomains und preload kannst du deine Domain in die Liste aufnehmen lassen, die Browser ab Werk mitbringen. Das ist der übliche Unterschied zwischen A und A+. Wie man es konfiguriert, steht in HTTP-Sicherheits-Header.
Mixed Content
Ein Detail, das die Zertifikatsnote nicht berührt, aber das Schloss: Lädt deine HTTPS-Seite ein Bild, ein Skript oder eine Schrift über HTTP, blockiert der Browser es oder markiert die Seite als nicht sicher. Das kommt meist von URLs, die aus einem alten Template kopiert wurden. Such im Quelltext nach http:// und stell auf relative Pfade oder HTTPS um.
Wenn du auf einer Managed-Plattform bist
Vercel, Netlify, Cloudflare Pages, Railway oder Render stellen das Zertifikat aus und erneuern es, erzwingen moderne Versionen und wählen sichere Cipher. Daran musst du nichts anfassen. Was dir bleibt: HSTS hinzufügen, Mixed Content beseitigen, alternative Domains umleiten und die Subdomains im Blick behalten, die woandershin zeigen.
Warum es über die Note hinaus wichtig ist
Schwaches TLS erlaubt das Abfangen von Sitzungen in öffentlichen Netzen, und ein falsch konfiguriertes Zertifikat lässt deine Website auf Geräten scheitern, die du nicht siehst. Zahlungsdienstleister verlangen mindestens TLS 1.2 für PCI DSS. Google nutzt HTTPS als Ranking-Signal, und Browser markieren alles ohne als „nicht sicher". Und ganz irdisch: Ein Zertifikat, das an einem Samstagmorgen abläuft, ist eine Website, die offline ist, bis es jemand merkt.
In dreißig Sekunden prüfen
curl -sIL http://deinedomain.com | grep -iE "^(HTTP|location|strict-transport)"
openssl s_client -connect deinedomain.com:443 -servername deinedomain.com -tls1_1 </dev/null 2>&1 | grep -iE "alert|error" | head -1Der erste muss einen 301 auf https:// und danach den HSTS-Header zeigen. Der zweite versucht, mit TLS 1.1 zu verbinden, und muss scheitern: Verbindet er, akzeptierst du eine veraltete Version.
Scanaris prüft dein TLS bei jedem Scan
Scanaris prüft Protokollversionen, Cipher, vollständige Kette, Zertifikatsnamen, Tage bis zum Ablauf, Weiterleitung und HSTS und warnt dich per E-Mail, bevor das Zertifikat abläuft. Jeder Fund kommt mit einem Fix-Prompt mit der exakten Konfiguration für deinen Server oder deine Plattform. Das sind reine Lesezugriffe: Es verbindet sich mit deiner Website genau wie ein Browser. Um zu sehen, was es alles in dreißig Sekunden prüft, lies wie du in 5 Minuten herausfindest, ob deine Website sicher ist.
Häufige Fragen
Was ist der Unterschied zwischen SSL und TLS?
SSL ist der alte Name des Protokolls, vor Jahren als unsicher ausgemustert. Heute wird TLS verwendet, aber die Leute sagen weiter „SSL-Zertifikat". Praktisch gesehen: Wenn du SSL liest, denk TLS.
Brauche ich ein kostenpflichtiges Zertifikat?
Nein. Kostenlose Zertifikate von Let's Encrypt oder die deiner Plattform verschlüsseln genau gleich. Bezahlte ergänzen Organisationsvalidierung oder Garantien, nicht mehr Sicherheit in der Verbindung.
Warum bekomme ich ein B, wenn mein Zertifikat gültig ist?
Meist, weil du TLS 1.0 oder 1.1 akzeptierst, schwache Cipher anbietest oder den HSTS-Header nicht sendest. Das Zertifikat ist nur eines der sieben Dinge, die geprüft werden.