TLS und Zertifikate: HTTPS sicher betreiben

Was TLS schützt und wo der Schutz endet

TLS schützt übertragene Anwendungsdaten vor Mitlesen und Veränderung und ermöglicht die Authentisierung der Gegenstelle. Im üblichen HTTPS-Fall weist der Server seine Identität über ein Zertifikat nach. Ein Nutzerkonto authentisiert TLS damit noch nicht. Auch eine Phishingseite kann ein gültiges Zertifikat für ihren eigenen Domainnamen haben. Sicherheitslücken in der Anwendung, kompromittierte Endgeräte und Daten nach der Entschlüsselung bleiben eigene Aufgaben. RFC 9325, Sicherheitsdienste.

Die Verbindung endet am TLS-Endpunkt. Steht davor ein CDN oder Reverse Proxy, schützt das Browser-HTTPS zunächst den Weg dorthin. Der weitere Weg zum Ursprungsserver braucht eine eigene geeignete Absicherung einschließlich Zertifikatsprüfung. Ein grüner Browserbefund am CDN bestätigt diese interne Strecke nicht. Verantwortlichkeiten und Prüfstellen beschreibt Implementierung und Architektur.

TLS 1.2 und TLS 1.3 richtig einordnen

TLS 1.3 ist die bevorzugte Grundlage für moderne HTTPS-Angebote. Seit Juli 2026 ersetzt RFC 9846 die ursprüngliche Spezifikation RFC 8446. Das ist eine rückwärtskompatible Aktualisierung von TLS 1.3 mit präzisierten und verschärften Anforderungen, keine neue Versionsnummer. TLS 1.0 und 1.1 dürfen nach RFC 8996 nicht mehr ausgehandelt werden. Geeignet konfigurierte TLS-1.2-Unterstützung kann für benötigte Clients weiterhin relevant sein. RFC 9846 §1.2, RFC 8996, RFC 9325.

Die Roundtrips sind keine garantierte Seitenladezeit und zählen einen vorangehenden TCP-Verbindungsaufbau nicht mit. Wiederaufnahme, HelloRetryRequest und andere Transportvarianten verändern den Ablauf.

Forward Secrecy bedeutet, dass eine spätere Kompromittierung langfristiger Schlüssel frühere Sitzungsdaten nicht ohne Weiteres entschlüsselbar macht. Dazu müssen die tatsächlich gewählten Verfahren und die Behandlung ephemerer Schlüssel passen. TLS 1.3 erlaubt auch PSK-only ohne frischen asymmetrischen Austausch. 0-RTT-Daten haben keine allgemeine Replay-Garantie zwischen Verbindungen: Eine frühe Anfrage kann wiederholt eintreffen. Aktivieren Sie frühe Daten nur mit einem ausdrücklichen Anwendungskonzept; Buchungen, Zahlungen und sonstige Zustandsänderungen dürfen nicht allein wegen eines schnellen Handshakes wiederholbar werden. RFC 9846 §§2.2–2.3 und 8.

Beispiele der TLS-1.3-Basisspezifikation sind TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 und TLS_CHACHA20_POLY1305_SHA256. Daneben stehen TLS_AES_128_CCM_SHA256 und TLS_AES_128_CCM_8_SHA256; die letzte Variante hat einen verkürzten Authentisierungstag und eigene Einsatzgrenzen. Diese Liste ist keine Empfehlung, alle Varianten einzuschalten, keine vollständige künftige Registry und keine universelle Rangfolge nach Mobilgerät oder Server. Nutzen Sie gepflegte Profile des tatsächlichen TLS-Stacks und gleichen Sie sie mit Ihren Anforderungen ab. RFC 9846, Cipher Suites.

Auch eine Prüfplattform hat einen eigenen Bewertungsmaßstab: Der gelesene SSL-Labs-Rating-Guide begrenzt die Note ohne TLS 1.3 auf A−. Daraus folgt weder eine gesetzliche TLS-1.3-Pflicht noch automatisch ein A+ nach dem Einschalten. Qualys SSL Labs, Rating Guide 2009r.

Namen, Gültigkeit und Vertrauenskette getrennt prüfen

Ein Zertifikat verbindet einen öffentlichen Schlüssel mit bestimmten Identitäten und Bedingungen. Für HTTPS sind insbesondere diese Prüfungen nötig:

RFC 9525 sieht die Serveridentität im SAN vor; ein Common Name allein genügt diesem aktuellen Namensmodell nicht. *.example.com kann genau eine linke Namensebene wie shop.example.com abdecken, aber weder example.com noch a.b.example.com. Ein DNS-SAN für einen Namen ersetzt keinen IP-SAN beim direkten IP-Aufruf. RFC 9525 §§6–7 und Anhang A.

Üblicherweise liefert der Server sein Blattzertifikat und die benötigten Zwischenzertifikate. Der Client baut daraus mit seinem Vertrauensbestand einen Pfad auf. Der Vertrauensanker wird nicht allein dadurch vertrauenswürdig, dass der Server ihn mitsendet. Unterschiedliche Root Stores, Zwischenspeicher, Softwarestände und Unternehmensregeln können unterschiedliche Ergebnisse erzeugen. Die Mozilla-Richtlinie beschreibt ihren eigenen Vertrauensbestand und dessen Geltungsbereich. RFC 5280 §6, Mozilla Root Store Policy.

Server Name Indication (SNI) hilft einem Server mit mehreren Websites, für den angefragten Namen das passende Zertifikat auszuwählen. Wer nur zur IP verbindet und den Namen nicht korrekt mitsendet beziehungsweise prüft, kann versehentlich das Standardzertifikat untersuchen. SNI-Auswahl und anschließende Namensprüfung erfüllen unterschiedliche Aufgaben.

Zertifikate auswählen und Erneuerung absichern

Für neu ausgestellte öffentlich vertrauenswürdige TLS-Subscriber-Zertifikate gelten folgende CA/B-Höchstlaufzeiten. Gemeint ist die gesamte Zertifikatslaufzeit, nicht die beim Scan verbleibende Restzeit und nicht jede private Unternehmens-PKI.

Die CA/B-Regeln empfehlen jeweils etwas kürzere Laufzeiten als das absolute Maximum. Einzelne Validierungsverfahren und Anbieter können strengere Grenzen setzen. Bereits ausgestellte Zertifikate werden durch die Stichtage nicht rückwirkend verkürzt; Erneuerungen sind neue Ausstellungen. Die Wiederverwendung von Identitätsdaten und die Zertifikatsgültigkeit sind getrennte Regeln. CA/B Baseline Requirements §§4.2.1 und 6.3.2.

ACME automatisiert unter anderem Domainkontrollnachweise und die Ausstellung. Die Laufzeitregel schreibt aber nicht allgemein ACME als einziges Verfahren vor. Wählen Sie eine Automatisierung, die zu CA, Hosting und Berechtigungen passt. DNS-basierte Validierung kann weitreichende DNS-Zugänge benötigen; begrenzen Sie diese nach Möglichkeit auf die erforderlichen Aufgaben. HTTP-basierte Validierung muss den richtigen Endpunkt trotz Redirects, CDN und Zugriffsschutz erreichen. RFC 8555.

Ein verlässlicher Ablauf umfasst mehr als einen erfolgreichen Ausstellungsauftrag:

1. Alle Zertifikate und TLS-Endpunkte inventarisieren, einschließlich CDN, Origin, Subdomains und alternativer Namen.
2. Ausstellung und Erneuerung rechtzeitig vor Ablauf ausführen; Fehler an eine verantwortliche Stelle melden.
3. Neues Zertifikat, privaten Schlüssel und Kette kontrolliert bereitstellen und den betroffenen Dienst korrekt neu laden.
4. Von außen prüfen, welches Zertifikat tatsächlich ausgeliefert wird; bei mehreren Knoten die Verteilung berücksichtigen.
5. Restlaufzeit und fehlgeschlagene Erneuerungen unabhängig überwachen. Bei Schlüsselverlust oder Kompromittierung Austausch und Widerruf mit der CA durchführen.

Kurze Laufzeit reduziert bestimmte Expositionszeiträume, ersetzt aber diese Kontrolle nicht. Ein Zertifikat mit sechs Stunden Restlaufzeit kann normal oder akut gefährdet sein – entscheidend ist, ob der nächste erfolgreiche Wechsel nachgewiesen und rechtzeitig möglich ist.

Bei ECDSA oder RSA sind Serverschlüssel, CA-Signatur und ausgehandelter Schlüsselaustausch zu unterscheiden. Ein RSA-Blattzertifikat kann etwa von einer ECDSA-CA signiert sein. ECDSA P-256 bietet kompakte Schlüssel und ist eine verbreitete Option für aktuelle Clients. RSA ist nicht auf Windows XP beschränkt. Entscheiden Sie anhand von Clientanforderungen, Sicherheitsniveau, CA und TLS-Implementierung.

Ein pauschaler Vergleich „ECDSA 256 Bit gegen RSA 2048 Bit gleich sicher“ wäre falsch: NIST ordnet RSA-2048 ungefähr 112 Bit klassischer Sicherheitsstärke zu, RSA-3072 und ECC mit 256 Bit ungefähr 128 Bit. Diese Einordnung ist keine Quantenresistenz. Auch „64 Byte ECDSA-Signatur“ beschreibt ein Rohformat, nicht pauschal die DER-kodierte TLS-/X.509-Signatur; deren Länge variiert. Die gesamte Zertifikatsgröße hängt außerdem von Namen, Erweiterungen und der Ausstellerkette ab. Geschwindigkeit und CPU-Kosten müssen für die konkrete Implementierung betrachtet werden. NIST SP 800-57 Teil 1 Rev. 5, Tabelle 2, RFC 9846 §4.3.3.

Widerruf und Certificate Transparency

Eine CA kann ein Zertifikat vor Ablauf widerrufen. Welche Widerrufsinformation ein Client verwendet und wie er bei Fehlern reagiert, hängt von seiner Implementierung und Konfiguration ab. OCSP Stapling übermittelt eine signierte Statusantwort im TLS-Handshake und kann einen eigenen Abruf des Clients vermeiden. Das setzt eine passende CA- und Clientunterstützung sowie eine frische, gültige Antwort voraus. Ein vorhandener Staple beweist nicht ohne Prüfung dessen Gültigkeit; sein Fehlen ist auch nicht für jede CA ein Mangel.

Let's Encrypt hat die OCSP-Responder zum 6. August 2025 eingestellt und verwendet CRLs für Widerrufsinformationen. Übernehmen Sie deshalb keine pauschale OCSP-Pflicht aus älteren Konfigurationsbeispielen. Für andere CAs prüfen Sie deren aktuellen Dienst und die Anforderungen Ihrer Clients. Let's Encrypt, OCSP-Umstellung.

Certificate Transparency (CT) macht Zertifikatsausstellungen über Protokolldienste überprüfbar und unterstützt das Erkennen unerwarteter Zertifikate. Ein Signed Certificate Timestamp (SCT) ist zunächst eine signierte Zusage eines Logs. Vorhandene SCT-Strukturen beweisen weder die geprüfte Signatur noch die tatsächliche Aufnahme oder die Erfüllung jeder Browserregel. Chrome betrachtet unter anderem SCT-Zahl, unterschiedliche Betreiber und den Status der Logs; Übertragungswege und Versionsgrenzen sind ebenfalls relevant. Chrome CT Policy.

Post-Quanten-Verfahren und technische Vorgaben

Hybride Schlüsseleinigung kombiniert ein klassisches mit einem post-quanten-kryptografischen Verfahren. Dafür müssen Client, Server und die ausgehandelte Gruppe zusammenpassen. Das schützt einen anderen Teil der Verbindung als die Zertifikatssignatur. TLS 1.3 allein ist kein PQC-Nachweis. In der lokalen Probe lief TLS 1.3 sowohl mit X25519 als auch mit P-256; beide Beobachtungen waren klassische Schlüsseleinigung.

Verbreitungszahlen brauchen einen Nenner: Cloudflare meldete für Anfang Dezember 2025 einen Anteil von 52 Prozent post-quanten-verschlüsseltem, von Menschen erzeugtem Webverkehr in seiner Beobachtungsbasis. Das ist eine datierte Betreiberbeobachtung, kein Beleg für denselben Anteil am gesamten HTTPS-Verkehr oder für die Konfiguration Ihrer Website. Cloudflare Radar, Rückblick 2025.

Die BSI TR-02102-2, Version 2026-01, bevorzugt TLS 1.3 und empfiehlt geeignete TLS-1.2-Konfigurationen noch bis Ende 2031. Auch die alleinige klassische Schlüsseleinigung wird dort nur bis Ende 2031 empfohlen. Algorithmuslisten, Mindestschlüssellängen und Anwendungsbereich gehören zusammen: Für RSA-Signaturschlüssel nennt §3.6 mindestens 3000 Bit. Die Empfehlung für bestimmte PKCS#1-v1.5-Signaturverfahren endete 2025; daraus folgt kein automatisches Ablaufdatum jedes bestehenden RSA-Zertifikats. Die TR ersetzt weder eine Implementierungsprüfung noch eine Risikobewertung. BSI TR-02102-2.

PCI DSS verlangt starke Kryptografie in seinem jeweiligen Geltungsbereich. Der PCI SSC stellt ausdrücklich klar, dass PCI DSS keine bestimmte TLS-Version pauschal festlegt; SSL und verwundbares frühes TLS erfüllen die Anforderung nicht. Eine Protokollnummer allein reicht daher auch dort nicht. PCI SSC, FAQ zu TLS-Versionen.

NIS2 beziehungsweise §30 BSIG verlangen für betroffene Einrichtungen angemessene Maßnahmen und Konzepte für Kryptografie. Ob bestimmte technische Vorgaben verbindlich sind, hängt von Geltungsbereich und Verpflichtung ab. Weder HTTPS noch eine Scannernote stellt umfassende Rechtskonformität her. Den rechtlichen Anschluss behandelt Web Security und Compliance.

Praktisch prüfen und Befunde lesen

Prüfen Sie mit dem benötigten Namen, SNI, aktivierter Namens- und Vertrauensprüfung und einem bekannten Clientstand. Ein lesendes Diagnosebeispiel für eine eigene Domain ist:

openssl s_client -connect www.example.com:443 \
  -servername www.example.com -verify_hostname www.example.com \
  -verify_return_error -showcerts </dev/null

Ersetzen Sie die Beispieldomain. Der verwendete OpenSSL-Truststore muss zum Prüfziel passen; für eine interne PKI geben Sie bewusst den vorgesehenen CA-Bestand an. -showcerts zeigt die vom Server gesendeten Zertifikate, keine bereits verifizierte Kette. Ohne -verify_return_error kann das Diagnosewerkzeug trotz Verifikationsfehlern fortfahren. Das Ergebnis sagt nichts über alle anderen Browser, Standorte oder Zertifikatsvarianten aus. OpenSSL s_client.

Der Web Security Check kann die ausgehandelte TLS-Version, Cipher und begrenzte Zertifikatsbefunde erfassen. Nach einer HTTPS-Weiterleitung beschreibt die gesonderte TLS-Prüfung grundsätzlich den finalen HTTPS-Host; der Ergebnisdatensatz hält den geprüften Host und einen Hostwechsel fest. Das ist keine Einzelprüfung aller Redirect-Zwischenstationen. DNS und andere Nebenprüfungen können einen anderen Bezugspunkt haben.

Die TLS-Prüfung verbindet zu einer geprüften IP und wertet Zertifikatsvertrauen mit Node/OpenSSL sowie eine zusätzliche Namensprüfung aus. Der Serverkontakt kann dabei zu Analysezwecken auch mit fehlerhaftem Zertifikat stattfinden; eine aufgebaute Verbindung bedeutet deshalb nicht „vertrauenswürdig“. Zeitgültigkeit, Vertrauen und Namensfehler müssen zusammen gelesen werden. Der öffentliche Check inventarisiert weder alle Protokolle und Ciphers noch alle CDN-Knoten, Browser-Root-Stores oder internen Verbindungen. Auch HTTP/3 über QUIC ist durch diese TCP-basierte TLS-Probe nicht abgedeckt.

Die ergänzende Legacy-Probe belegt alte TLS-Unterstützung nur bei erfolgreicher Aushandlung. Scheitert sie, kann die Ursache auch beim Prüfclient oder Transport liegen. Die CT-Auswertung liest eingebettete Strukturen in einem gesonderten Abruf; SCT-Signaturen, Logaufnahme und vollständige Browser-CT-Konformität werden nicht geprüft. OCSP-Validierung, erfolgreiche künftige Erneuerung und eine vollständige PQC-Bewertung folgen aus dem Check ebenfalls nicht.

In den lokalen Gegenproben wurden fehlendes Zwischenzertifikat, unbekannter Root, falscher Name, abgelaufenes und noch nicht gültiges Zertifikat getrennt geprüft. Dabei konnte Node auch ein nur im Common Name benanntes Testzertifikat akzeptieren. Das illustriert die Grenze zwischen einem bestimmten Prüfclient und aktuellen Namensregeln; es ist keine Empfehlung, SAN wegzulassen. Wiederholen Sie die entscheidenden Fälle mit den tatsächlich unterstützten Clients.

Weiterlesen und Umsetzung

HSTS ergänzt den Wechsel zu HTTPS, DNS-Sicherheit behandelt DNSSEC und CAA. Die Einführungsarchitektur verbindet öffentliche Antwort, Proxy und Betrieb.