Blog

Warum Let's Encrypt allein nicht reicht: TLS vollständig absichern

10. Juni 2026 · 14 min Lesezeit
Auf Play klicken um den Artikel vorlesen zu lassen.
TLSLet's EncryptHSTSCAASecurity HeadersCertificate Transparency TLS Let's Encrypt HSTS CAA Security Headers Certificate Transparency

Let's Encrypt hat die Welt sicherer gemacht — kostenlose TLS-Zertifikate für alle, automatisch erneuert, kein Grund mehr für unverschlüsselte HTTP-Verbindungen. Aber ein Zertifikat bedeutet nur: Die Verbindung ist verschlüsselt. Es bedeutet nicht: Die Verbindung ist sicher. Wer TLS ernsthaft betreiben will, muss über das Zertifikat hinausdenken.

Was ein TLS-Zertifikat tatsächlich garantiert

Ein TLS-Zertifikat von Let's Encrypt bestätigt: Eine Zertifizierungsstelle (Let's Encrypt) hat verifiziert, dass du zum Zeitpunkt der Ausstellung Kontrolle über die Domain hattest. Nicht mehr, nicht weniger. Es garantiert nicht:

  • Dass dein Server korrekt konfiguriert ist
  • Dass keine andere CA ein Zertifikat für deine Domain ausgestellt hat
  • Dass der Nutzer nicht auf eine Phishing-Seite mit gültigem Zertifikat weitergeleitet wird
  • Dass schwache Cipher Suites nicht verwendet werden
  • Dass ein zukünftiger Angriff auf Let's Encrypt keine gefälschten Zertifikate erzeugt

CAA-Records: Wer darf Zertifikate für deine Domain ausstellen?

Certificate Authority Authorization (CAA) ist ein DNS-Record-Typ (RFC 8659), der definiert, welche CAs Zertifikate für deine Domain ausstellen dürfen. Ohne CAA-Record kann prinzipiell jede der hundert+ vertrauenswürdigen CAs ein Zertifikat für deine Domain ausstellen — auch ohne dein Wissen, auch nach einem erfolgreichen Angriff auf eine dieser CAs.

# DNS CAA-Records
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"
# issue: Wer darf normale Zertifikate ausstellen
# issuewild: Wer darf Wildcard-Zertifikate ausstellen
# iodef: Wohin sollen Verletzungsmeldungen gesendet werden

Mit diesem Record darf nur Let's Encrypt Zertifikate für deine Domain ausstellen. Jeder andere Versuch — ob durch Fehler oder Angriff — muss von der ausstellenden CA verweigert werden. CAs sind seit 2017 verpflichtet, CAA-Records zu respektieren.

Certificate Transparency: Jeden neuen Zertifikat-Einträg überwachen

Certificate Transparency (CT) ist eine öffentliche, append-only Datenbank aller ausgestellten TLS-Zertifikate. Jede vertrauenswürdige CA muss ausgestellte Zertifikate in CT-Logs eintragen — was bedeutet: Jedes Zertifikat, das für deine Domain ausgestellt wird, taucht in dieser Datenbank auf.

Das ermöglicht Monitoring: Wenn eine unbekannte CA ein Zertifikat für deine Domain ausstellt — ob durch Fehler, CA-Kompromittierung oder Angriff — weißt du es innerhalb von Minuten.

# Alle Zertifikate für eine Domain anzeigen
# https://crt.sh/?q=example.com

# Monitoring via API
curl -s "https://crt.sh/?q=example.com&output=json" |   python3 -c "import json,sys; [print(c['name_value']) for c in json.load(sys.stdin)]"

Dienste wie Cert Spotter (von SSLMate) oder Facebook's CT Monitor benachrichtigen automatisch per E-Mail wenn ein neues Zertifikat für überwachte Domains ausgestellt wird. Für kritische Domains ist das unverzichtbar.

HSTS: HTTP Strict Transport Security

HSTS ist ein HTTP-Response-Header, der dem Browser mitteilt: Verbinde dich für die nächsten X Sekunden niemals über unverschlüsseltes HTTP mit dieser Domain — auch wenn du es explizit versuchst.

# Nginx HSTS-Header
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Die drei Parameter:

  • max-age=31536000: Ein Jahr — der Browser ignoriert HTTP für diese Domain für 365 Tage
  • includeSubDomains: Gilt auch für alle Subdomains
  • preload: Erlaubt die Aufnahme in die Browser-Preload-Liste

Die HSTS Preload Liste ist in Chromium, Firefox, Safari und Edge eingebaut — Domains auf dieser Liste werden von Anfang an nur über HTTPS aufgerufen, noch bevor der erste HTTP-Request gesendet wurde. Das eliminiert den "First Visit"-Angriff (HTTPS Downgrade beim ersten Besuch). Aufnahme über hstspreload.org — Voraussetzung: preload-Direktive im Header und HTTPS auf allen Subdomains.

Cipher Suites: TLS 1.0 und 1.1 müssen weg

TLS 1.0 (1999) und TLS 1.1 (2006) sind veraltet, haben bekannte Schwachstellen (BEAST, POODLE) und wurden von allen großen Browsern abgekündigt. TLS 1.2 ist akzeptabel, TLS 1.3 ist der aktuelle Standard.

# Nginx: Nur TLS 1.2 und 1.3, starke Cipher Suites
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;
ssl_prefer_server_ciphers off;  # Bei TLS 1.3 nicht nötig, bei 1.2 empfohlen

# OCSP Stapling — prüft Zertifikat-Revokation ohne Client-Round-Trip
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;

Das Ergebnis dieser Konfiguration ist ein SSL-Labs-Rating von A+. Das lässt sich unter ssllabs.com/ssltest kostenlos prüfen.

Security-Header: Was Zertifikate nicht abdecken

TLS schützt die Verbindung. HTTP Security Headers schützen die Anwendung. Die wichtigsten:

# Nginx Security Header Sammlung
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

# Content Security Policy (anwendungsspezifisch anpassen!)
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';" always;

Den Status prüfen: Tools

  • SSL Labs: ssllabs.com/ssltest — vollständiger TLS-Test, Bewertung A–F
  • SecurityHeaders.com: Prüft alle HTTP Security Header
  • MXToolbox: Blacklist-Prüfung und Mail-Server-Test
  • HSTS Preload: hstspreload.org — Status der Preload-Aufnahme
  • crt.sh: Certificate Transparency Suche

Fazit

Ein Let's-Encrypt-Zertifikat ist der Mindeststandard, nicht das Ziel. CAA-Records beschränken wer Zertifikate ausstellen darf. CT-Monitoring benachrichtigt bei unbekannten Ausstellungen. HSTS mit Preload eliminiert Downgrade-Angriffe. Starke Cipher Suites und TLS 1.3 schließen protokollspezifische Schwachstellen. Security Header schützen die Anwendungsebene. Jede dieser Maßnahmen kostet wenig Aufwand — zusammen ergeben sie eine TLS-Konfiguration, die dem Begriff "sicher" tatsächlich gerecht wird.

OCSP Must-Staple: Revokation die funktioniert

Das größte Problem bei TLS-Zertifikaten ist Revokation. Wenn ein Zertifikat kompromittiert wird, soll es sofort ungültig werden — aber CRL-Listen werden selten abgerufen und OCSP hat Performance-Probleme. OCSP Stapling ist eine Verbesserung (der Server fragt OCSP ab und liefert die Antwort im TLS-Handshake mit), aber der Client kann Stapling ignorieren.

OCSP Must-Staple ist eine Zertifikatserweiterung, die den Server zwingt, eine gültige OCSP-Antwort mitzuliefern. Clients die Must-Staple kennen, lehnen Verbindungen ohne gültige OCSP-Stapling-Antwort ab.

# Certbot: Zertifikat mit OCSP Must-Staple anfordern
certbot certonly --must-staple -d example.com

# Nginx: OCSP Stapling korrekt konfigurieren
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

# Status prüfen
openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 20 "OCSP Response"

Content Security Policy: Der komplexeste Header

CSP ist der mächtigste aber auch komplexeste Security-Header. Er definiert, welche Ressourcen (Skripte, Styles, Bilder, Frames) von welchen Quellen geladen werden dürfen. Eine zu restriktive CSP bricht die Seite, eine zu lockere bringt keinen Sicherheitsgewinn.

# Minimale CSP für statische Seiten ohne externe Ressourcen
Content-Security-Policy: default-src 'self'; img-src 'self' data:; style-src 'self'

# Entwicklung: CSP im Report-Only-Modus (keine Blockierung, nur Berichte)
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

# Report-Endpoint einrichten (Nginx)
location /csp-report {
    access_log /var/log/nginx/csp.log;
    return 204;
}

Der Report-Only-Modus ist der richtige Einstieg: Erst beobachten was blockiert würde, dann die Policy entsprechend anpassen, dann zum enforcing Mode wechseln. CSP ohne Testing führt zu Selbst-DoS.

Subresource Integrity (SRI)

Wer externe Ressourcen einbindet (CDN für JavaScript-Libraries), sollte SRI verwenden: Ein Hash der erwarteten Datei wird im HTML-Tag hinterlegt. Wenn die CDN die Datei manipuliert (gehackt oder kompromittiert), schlägt der Browser Alarm und lädt die Datei nicht.

<!-- Beispiel: Bootstrap von CDN mit SRI -->
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bootstrap/5.3.0/css/bootstrap.min.css" integrity="sha384-9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM" crossorigin="anonymous">

# SRI-Hash generieren
curl -s https://cdnjs.cloudflare.com/ajax/libs/bootstrap/5.3.0/css/bootstrap.min.css |   openssl dgst -sha384 -binary | openssl base64 -A

Permissions Policy: Browser-Features einschränken

Der Permissions-Policy-Header (früher Feature-Policy) schränkt ein, welche Browser-APIs die Seite nutzen darf — auch in eingebetteten Frames:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), fullscreen=(self)
# camera=(): Keine Kamera-Zugiffe erlaubt (auch nicht via JS-API)
# fullscreen=(self): Fullscreen nur für eigene Seite, nicht für iframes

Der SSL Labs Score: Wie A+ erreichen

SSL Labs (ssllabs.com/ssltest) bewertet TLS-Konfigurationen von A+ bis F. Für A+ müssen alle diese Bedingungen erfüllt sein:

  • Kein SSLv3, TLS 1.0, TLS 1.1
  • Keine schwachen Cipher Suites (RC4, DES, 3DES, EXPORT)
  • Forward Secrecy für alle Clients
  • HSTS mit min-age ≥ 180 Tage
  • Kein öffentlich bekanntes Sicherheitsproblem (BEAST, POODLE, Heartbleed)
# Vollständige A+-Nginx-Konfiguration
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;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

TLS-Fingerprinting und JA3

Ein wenig bekannter Aspekt von TLS: Der Client gibt beim Handshake viele Informationen über sich preis — welche Cipher Suites er unterstützt, welche Erweiterungen, in welcher Reihenfolge. Diese Informationen können zu einem Fingerprint (JA3-Hash) zusammengefasst werden, der den Client eindeutig identifiziert — oft zuverlässiger als der User-Agent-String.

Für Serveradministratoren: JA3-Fingerprinting ermöglicht die Identifikation von Bots und Scannern, die sich mit gefälschten User-Agents tarnen. Nginx kann JA3-Hashes über das ngx_http_ssl_fingerprint-Modul loggen und für Entscheidungen nutzen.

HTTPS-Everywhere ist Geschichte: Was jetzt?

Die EFF hat HTTPS Everywhere 2022 eingestellt, weil alle großen Browser HTTP-zu-HTTPS-Upgrades nativ unterstützen. Chrome und Firefox können so konfiguriert werden, dass sie automatisch HTTPS versuchen bevor HTTP:

# Nginx: HTTP auf HTTPS redirecten (immer nötig!)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;

    # Ausnahme für Let's Encrypt ACME-Challenge
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    # Alles andere redirecten
    location / {
        return 301 https://$server_name$request_uri;
    }
}

Wer HSTS mit Preload aktiviert hat, kann den HTTP-Server perspektivisch ganz abschalten — Browser werden niemals über HTTP verbinden. Aber erst wenn HSTS-Preload bestätigt ist und man sicher ist, HTTPS nie wieder deaktivieren zu wollen.

Mutual TLS (mTLS): Clients authentifizieren

In API-Umgebungen ist nicht nur die Server-Authentifizierung wichtig, sondern auch die Client-Authentifizierung. mTLS erweitert TLS um Client-Zertifikate: Nur Clients mit einem gültigen Zertifikat der Client-CA können sich verbinden.

# Nginx: mTLS konfigurieren
ssl_client_certificate /etc/nginx/client-ca.pem;
ssl_verify_client on;  # oder optional für optionale Client-Auth

# Client-Zertifikat ausstellen (eigene CA)
openssl genrsa -out client.key 4096
openssl req -new -key client.key -out client.csr
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key   -CAcreateserial -out client.crt -days 365

# In Nginx: Client-Zertifikat-Infos weiterleiten
proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
proxy_set_header X-SSL-Client-DN $ssl_client_s_dn;

mTLS ist Standard in Zero-Trust-Netzwerkarchitekturen und wird zunehmend für API-zu-API-Kommunikation eingesetzt — anstelle von API-Keys, die gestohlen werden können.

Abschließender Security-Check: Die vollständige Checkliste

  • ☑ Let's Encrypt Zertifikat mit Auto-Renewal
  • ☑ CAA-DNS-Record — nur Let's Encrypt darf ausstellen
  • ☑ HSTS-Header mit min-age 31536000
  • ☑ HSTS Preload eingereicht (hstspreload.org)
  • ☑ TLS 1.0 und 1.1 deaktiviert
  • ☑ OCSP Stapling aktiviert
  • ☑ SSL Labs Score A+
  • ☑ Security Headers (X-Frame-Options, X-Content-Type-Options, Referrer-Policy)
  • ☑ Content Security Policy (auch wenn komplex)
  • ☑ Certificate Transparency Monitoring eingerichtet
  • ☑ SRI für externe Ressourcen
  • ☑ IPv6 ebenfalls mit TLS abgesichert

Certificate Pinning: Warum es nicht empfohlen wird

HTTP Public Key Pinning (HPKP) war ein Standard der dem Browser mitteilt, welcher öffentliche Schlüssel für eine Domain erwartet wird. Das klingt sicher — ist aber in der Praxis gefährlich. Wenn der eigene Schlüssel kompromittiert wird oder man das Zertifikat erneuert, ohne den neuen Schlüssel vorab zu pinnen, sperrt man alle Nutzer aus bis das Pin-Timeout abläuft. Google hat HPKP 2017 aus Chrome entfernt.

Alternative: Certificate Transparency Monitoring (als Push-Benachrichtigung) in Kombination mit CAA-Records ist sicherer als Pinning und hat keine Selbst-DoS-Gefahr. Für Application-Layer-Pinning (eigene Apps die mit einem bekannten Backend kommunizieren) ist Pinning noch sinnvoll — aber nur mit einem sorgfältigen Backup-Pin-Prozess.

TLS-Inspektion: Das Unternehmensproblem

In Unternehmensumgebungen wird oft "TLS-Inspektion" (auch "SSL Inspection" oder "Break and Inspect") eingesetzt: Ein Proxy entschlüsselt den HTTPS-Traffic, analysiert ihn, und verschlüsselt ihn neu mit einem internen Zertifikat. Für den Browser sieht das aus wie eine Man-in-the-Middle-Attacke — weil es eine ist, nur eine autorisierte.

Das hat Implikationen für HSTS und CAA: HSTS schützt nicht gegen autorisierte TLS-Inspektion. CAA-Records werden vom Proxy ignoriert. Für Selbsthoster in Unternehmensumgebungen bedeutet das: Wenn der eigene Server in einem Netz betrieben wird das TLS-Inspektion nutzt, sind einige der beschriebenen Sicherheitsmaßnahmen wirkungslos. Das ist keine Lösung, die man selbst beeinflusst — aber man sollte das Scope der eigenen Sicherheitsmaßnahmen kennen.

Let's Encrypt Rate Limits: Produktions-Fallstricke

Let's Encrypt hat Ausstellungslimits die bei intensiver Nutzung zu Problemen führen können:

  • 50 Zertifikate pro Domain und Woche (Certificates per Registered Domain)
  • 5 duplizierte Zertifikate pro Woche (für exakt dieselbe Domain-Kombination)
  • 5 fehlgeschlagene Validierungsversuche pro Account pro Hostname pro Stunde
# Rate Limit Status prüfen
# crt.sh zeigt alle ausgestellten Zertifikate:
curl -s "https://crt.sh/?q=example.com&output=json" |   python3 -c "import json,sys,datetime
data = json.load(sys.stdin)
recent = [d for d in data if '2026' in d.get('not_before','')]
print(f'Zertifikate diese Periode: {len(recent)}')"

# Staging-Umgebung für Tests nutzen!
certbot certonly --staging -d example.com
# Kein Rate-Limit, aber Zertifikat von Test-CA (nicht trusted)

Wer Automation entwickelt (z.B. automatische Zertifikatserneuerung in CI/CD), sollte immer zuerst mit der Let's-Encrypt-Staging-Umgebung testen und erst auf Produktion wechseln wenn alles funktioniert.

Der vollständige Blick: Was TLS-Sicherheit wirklich bedeutet

TLS-Sicherheit ist kein Zertifikat und kein Haken auf einer Checkliste. Es ist ein Prozess: Zertifikate werden ausgestellt und müssen erneuert werden. CAs können kompromittiert werden und müssen überwacht werden. Protokollstandards entwickeln sich weiter und erfordern Konfigurationsanpassungen. Neue Angriffe entstehen und erfordern neue Gegenmaßnahmen.

Das klingt nach viel — aber in der Praxis ist der Aufwand nach der initialen Einrichtung gering. Let's Encrypt erneuert automatisch. CT-Monitoring läuft im Hintergrund. SSL Labs kann monatlich oder quartalsweise geprüft werden. CAA-Records ändern sich selten. Der größte Einmalaufwand ist die Ersteinrichtung; danach ist es Monitoring und gelegentliche Anpassung.

Wer die in diesem Artikel beschriebenen Maßnahmen umsetzt — CAA-Records, HSTS Preload, CT-Monitoring, TLS 1.3, aktuelle Cipher Suites, Security Headers — hat einen Sicherheitsstandard der weit über dem Durchschnitt liegt. Das ist keine akademische Übung, sondern echter Schutz gegen echte Angriffe.

War dieser Beitrag hilfreich?

Alle Beiträge Gregor Krebs · 10. Juni 2026