HTTPS und TLS richtig gemacht — ein praktischer Konfigurationsleitfaden | Scanthra

Scanthra · 8 Min Lesezeit · Aktualisiert Mai 2026

Warum „wir haben HTTPS" meist nicht reicht

Eine Website, die über HTTPS lädt, aber auch noch über einfaches HTTP erreichbar ist — oder TLS/SSL (Verschlüsselung) 1.0, ein abgelaufenes Zertifikat oder schwache Cipher-Suites verwendet — entspricht einem Sicherheitsschloss an einer angelehnt gebliebenen Tür. Jeder moderne Sicherheitsfragebogen, Browser-Warnung und jede Compliance-Vorschrift (DSGVO (GDPR) Art. 32, NIS2 Art. 21(2)(h), PCI DSS 4.0) behandelt TLS-Hygiene als Grundlage, nicht als Extra.

Die fünf Dinge, die du richtig machen musst

1. Ein gültiges, modernes Zertifikat

Kostenlos, automatisch, von jedem Browser akzeptiert: Let's Encrypt. Die meisten Hosting-Panels (cPanel, Plesk, DirectAdmin, ISPmanager) haben einen Ein-Klick-Installer. Für VPS-Nutzer erneuern certbot oder acme.sh alle 60 Tage automatisch. Wähle RSA-2048 oder ECDSA P-256 — beide sind in Ordnung.

2. Nur HTTPS — kein HTTP, kein Mixed Content

Jede HTTP-Anfrage sollte auf HTTPS mit einem 301 weitergeleitet werden (nicht 302 — Suchmaschinen behandeln sie unterschiedlich). Mixed Content (eine HTTPS-Seite lädt ein HTTP-Bild oder -Skript) bricht die Sicherheitsgarantie still — die meisten Browser blockieren das, aber einige ältere Einbettungen kommen durch. Prüfe das im Browser-Tab „Sicherheit" in den Entwicklertools.

3. HSTS — dem Browser sagen, dass er sich HTTPS merken soll

Ohne HSTS (HTTPS-Erzwingung) enthält jeder erste Besuch noch eine HTTP-Anfrage, die abgefangen werden kann. Die Lösung ist ein einziger HTTP-Response-Header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age=31536000 — ein Jahr. Starte während des Tests bei einem Monat (2592000), dann erhöhen.
• includeSubDomains — gilt auch für jede Subdomain. Füge das nur hinzu, wenn du sicher bist, dass jede Subdomain HTTPS hat.
• preload — berechtigt, in die integrierte HSTS-Liste von Browsern aufgenommen zu werden unter hstspreload.org. Nur einreichen, wenn alles andere stabil ist; die Entfernung aus der Liste dauert Wochen.

4. Moderne Protokolle und Cipher-Suites

Deaktiviere SSLv3, TLS 1.0 und TLS 1.1 — sie haben bekannte Schwachstellen und kein moderner Client benötigt sie. Aktiviere TLS 1.2 und TLS 1.3.

Für nginx (Mozilla „intermediate" Baseline, generiert von ssl-config.mozilla.org):

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:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

Für Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite 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
SSLHonorCipherOrder off

5. OCSP-Stapling und HTTP/2

OCSP-Stapling lässt deinen Server den Widerrufsstatus des Zertifikats in den TLS-Handshake einbetten — und vermeidet so einen separaten (langsamen, manchmal fehlerhaften) Aufruf des Browsers an die CA.

ssl_stapling on;
ssl_stapling_verify on;

HTTP/2 ist keine Sicherheitsfunktion an sich, aber die meisten modernen Sicherheitsprüfer werten sein Fehlen als Zeichen eines veralteten Stacks:

listen 443 ssl http2;

Cloudflare-Kurzweg

Wenn dein Origin hinter Cloudflare sitzt, deckt ein einziger Schalter das meiste oben Genannte ab:

• SSL/TLS → Übersicht: auf Vollständig (streng) setzen.
• SSL/TLS → Edge-Zertifikate: „Immer HTTPS verwenden", „Automatische HTTPS-Umschreibungen" und „Mindest-TLS-Version: TLS 1.2" aktivieren sowie HSTS über das Panel einschalten.
• Das deckt ~80 % der TLS-Befunde ab, ohne den Origin-Server anzufassen.

Erneuerung — das Langweilige, das dich doch beißt

Das häufigste TLS-Problem: „Das Zertifikat lief am Sonntagmorgen ab, niemand hat es gemerkt, Kunden konnten die Website sechs Stunden nicht erreichen." Zwei Schutzmaßnahmen:

• Automatische Erneuerung auf Zertifikatsebene (Let's Encrypt macht das standardmäßig; prüfe mit certbot renew --dry-run).
• Ein externer Monitor — UptimeRobot, Better Uptime, BetterStack oder ein kostenloser Cloudflare-ähnlicher Cron-Alert —, der dich 14 Tage vor Ablauf benachrichtigt.

So überprüfst du dein Setup

• Mozilla Observatory — kostenlos, gibt eine Schulnote und erklärt jeden Abzug.
• SSL Labs SSL Test (Qualys) — das maßgebliche TLS-Tiefentest, 2026 noch immer relevant.
• Scanthra — unsere Module SSL/TLS, HSTS und Security Headers fassen dieselben Befunde in einfacher Sprache zusammen und liefern sie als PDF, das du einem Kunden oder Prüfer aushändigen kannst.

Häufige Stolpersteine

• SNI-Verwirrung. Einige ältere Clients auf derselben IP können das falsche Zertifikat ausliefern. Nutze einen VirtualHost pro Zertifikat und halte das Default-Server-Zertifikat gültig.
• Vergessene Subdomains. www. und cdn. brauchen oft ein eigenes Zertifikat oder einen SAN-Eintrag im Hauptzertifikat.
• HSTS-bedingte Aussperrungen. Wenn du HSTS mit includeSubDomains setzt, bevor jede Subdomain TLS hat, werden diese Subdomains für den max-age-Zeitraum unerreichbar. Starte ohne includeSubDomains.
• Cipher-Suite-Paranoia. Jede Cipher-Suite zu verbieten, die jemals eine Schwachstelle hatte, sperrt Nutzer auf alten Smartphones aus. Das Mozilla-„intermediate"-Preset ist ein sinnvoller Kompromiss.

So erkennt Scanthra TLS-Probleme

Unser Modul SSL/TLS prüft: Zertifikatsgültigkeit und Ablaufdatum, unterstützte Protokollversionen, HSTS-Vorhandensein und -Policy, Zertifikatsketten-Vertrauen und einige häufige Fehlkonfigurationen. Die Befunde erscheinen im Bericht mit Schweregrad, verständlicher Erklärung und einem kopierfertigen Fix — genau wie in diesem Artikel.