TLS und SSL-Zertifikat prüfen: Kette, Laufzeit, Protokolle, Cipher-Suites

Die Zertifikatskette

Bevor der Browser eine Seite lädt, prüft er das Zertifikat des Servers. Ausgestellt hat es fast nie die Wurzel einer Zertifizierungsstelle (CA) selbst. Dazwischen steht ein Zwischenzertifikat: Die Wurzel signiert das Zwischenzertifikat, das Zwischenzertifikat signiert Dein Zertifikat. Die Wurzeln kennt der Browser. Das Zwischenzertifikat muss der Server mitschicken.

Bei Let's Encrypt liegt Dein Zertifikat allein in cert.pem, zusammen mit dem Zwischenzertifikat in fullchain.pem. Wer im Webserver die falsche Datei einträgt, liefert eine unvollständige Kette aus und merkt es selbst meist nicht. Chrome und Edge laden das fehlende Stück am Desktop über die Adresse nach, die im Zertifikat steht (Authority Information Access, AIA), und Firefox hat die bekannten Zwischenzertifikate vorab gespeichert. Apps, ältere Android-Geräte, curl und viele Schnittstellen brechen dagegen ab. ZwoWebCheck bewertet eine unvollständige Kette deshalb als hoch, ein selbst signiertes oder nicht vertrauenswürdiges Zertifikat als kritisch.

Name und Wildcard

Ein Zertifikat gilt nur für die Namen in seinem Feld Subject Alternative Name (SAN). Ein Zertifikat für www.beispiel.de passt also nicht zu beispiel.de. Beide Namen gehören hinein, auch wenn einer davon nur weiterleitet, denn die Warnung erscheint vor der Weiterleitung.

Ein Wildcard-Zertifikat für *.beispiel.de deckt genau eine Ebene ab. shop.beispiel.de ist enthalten, test.shop.beispiel.de nicht, und beispiel.de selbst auch nicht.

Laufzeit und Erneuerung

Hinter fast jedem abgelaufenen Zertifikat steckt eine Erneuerung, die jemand von Hand erledigen wollte. Mit ACME, dem Protokoll hinter Let's Encrypt, übernimmt das ein Client wie certbot oder acme.sh. Bei vielen Hostern und Webservern wie Caddy läuft das von Haus aus.

Von Hand wird es bald ohnehin nicht mehr gehen. Mit Beschluss SC-081 hat das CA/Browser Forum die Laufzeit öffentlicher Zertifikate schrittweise begrenzt:

ausgestellt ab	höchstens
15. März 2026	200 Tage
15. März 2027	100 Tage
15. März 2029	47 Tage

Let's Encrypt geht schneller vor und stellt bis 2028 von 90 auf 45 Tage um. Bei den heutigen 90-Tage-Zertifikaten erneuert certbot rund 30 Tage vor Ablauf. Bleiben weniger als drei Wochen, melden wir das als mittel, unter einer Woche als hoch. Dann ist die Automatik vermutlich stehen geblieben. Kürzere Zertifikate erneuern ACME-Clients später, meist wenn noch ein Drittel der Laufzeit übrig ist. Für sie rücken unsere Grenzen deshalb mit: mittel ab einem Viertel der Laufzeit, hoch ab einem Zwölftel.

Schlüssel und Signatur

RSA-Schlüssel brauchen mindestens 2048 Bit, alles darunter ist kritisch. ECDSA mit der Kurve P-256 kommt mit einem viel kürzeren Schlüssel aus, ist etwa so stark wie RSA mit 3072 Bit und macht den Handshake schneller. Für neue Zertifikate ist ECDSA die bessere Wahl. Mit SHA-1 oder MD5 signierte Zertifikate lehnen Browser seit Jahren ab.

Mehrere Server hinter einem Namen

Zeigt Dein Hostname auf mehrere IP-Adressen, stehen dahinter oft zwei Server oder ein Load-Balancer mit eigenem Zertifikat. Bei der Erneuerung bleibt dann gern einer auf dem alten Stand, und nur ein Teil der Besucher sieht eine Warnung. ZwoWebCheck vergleicht deshalb Zertifikat und TLS-Version der ersten beiden IPv4-Adressen.

TLS-Versionen

TLS 1.3 (RFC 8446) ist die aktuelle Version. Der Handshake braucht einen Umlauf weniger. Unsichere Verfahren sind aus dem Standard verschwunden, Forward Secrecy ist immer dabei. TLS 1.2 bleibt mit passenden Cipher-Suites sicher und wird für ältere Clients noch gebraucht. Ein Server, der höchstens TLS 1.2 anbietet, bekommt bei uns trotzdem die Stufe mittel. TLS 1.3 einzuschalten kostet mit aktuellem OpenSSL eine Zeile.

TLS 1.0 und 1.1 hat die IETF mit RFC 8996 im März 2021 abgekündigt, die großen Browser hatten sie schon 2020 abgeschaltet. SSLv3 ist seit dem POODLE-Angriff von 2014 gebrochen (RFC 7568). Nimmt ein Server diese Versionen noch an, hat seine Konfiguration meist seit Jahren niemand angefasst. Wir werten TLS 1.0 und 1.1 als hoch, SSLv3 als kritisch.

Cipher-Suites und Forward Secrecy

Die Cipher-Suite legt fest, wie Client und Server den Schlüssel austauschen und womit sie verschlüsseln. Bei TLS 1.3 ist jede Suite in Ordnung, bei TLS 1.2 kommt es auf die Liste an. Gut sind Suites mit ECDHE-Schlüsseltausch und AEAD-Verschlüsselung, also AES-GCM oder ChaCha20-Poly1305.

ECDHE sorgt für Forward Secrecy. Wer den Verkehr heute mitschneidet und später den privaten Schlüssel des Servers stiehlt, kann die alten Verbindungen damit nicht entschlüsseln. Suites mit reinem RSA-Schlüsseltausch fehlt diese Eigenschaft. Ganz heraus gehören RC4, 3DES (anfällig für SWEET32) sowie alles mit NULL oder EXPORT im Namen.

HTTP/2 handeln Browser im TLS-Handshake per ALPN aus. Es überträgt viele Dateien parallel über eine Verbindung und macht Seiten schneller, ist aber keine Frage der Sicherheit. In nginx genügt ab Version 1.25.1 http2 on;.

Eine solide Konfiguration

Cipher-Listen selbst zusammenzustellen lohnt nicht. Der frühere Mozilla SSL Configuration Generator heißt heute TLSRef Configurator (configurator.tlsref.org), unter der alten Adresse ssl-config.mozilla.org findest Du einen Verweis dorthin. Für eine normale Website passt das Profil „Intermediate“ mit TLS 1.2 und 1.3 und ausschließlich ECDHE-Suites mit AEAD. In nginx sieht der Kern so aus:

ssl_certificate     /etc/letsencrypt/live/beispiel.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/beispiel.de/privkey.pem;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

Die Suites für TLS 1.3 stellt nginx nicht über ssl_ciphers ein, die Voreinstellung von OpenSSL passt. Vor dem Neuladen prüft nginx -t die Syntax. Läuft alles, ist HSTS der nächste Schritt. Mit CAA legst Du fest, welche CAs überhaupt Zertifikate für Deine Domain ausstellen dürfen.

Typische Fehler

• cert.pem statt fullchain.pem im Webserver. Im eigenen Browser fällt das nicht auf, in der App des Kunden schon.
• certbot erneuert brav, aber niemand lädt den Webserver neu, und er liefert weiter das alte Zertifikat aus. Ein Deploy-Hook wie --deploy-hook "systemctl reload nginx" löst das.
• Das neue Zertifikat liegt auf dem Webserver, der Load-Balancer davor zeigt noch das alte.
• Eine Cipher-Liste aus einer Anleitung von 2015, in der noch 3DES oder RC4 steht.

TLS und Zertifikat prüfen

ZwoWebCheck baut zu Deiner Adresse eine gewöhnliche TLS-Verbindung auf und schickt danach ein paar kurze Verbindungsversuche, die nur alte Protokollversionen oder schwache Suites anbieten; mehr bekommt Dein Server von uns nicht zu sehen. Im Bericht stehen Kette, Name, Ablaufdatum, Schlüssel, Protokollversionen und Cipher-Suites, jeweils mit Ampel und Empfehlung.