TLS/SSL Best Practices: Zertifikate, Cipher, Konfiguration

1. TLS-Handshake verstehen: So entsteht eine sichere Verbindung

Jede TLS-Verbindung beginnt mit einem Handshake, bevor ein einziges Byte Nutzdaten fließt. Der Client sendet ein ClientHello mit unterstützten Protokollversionen, Cipher Suites und Extensions wie SNI (Server Name Indication), damit ein Server mit mehreren Domains das passende Zertifikat auswählen kann. Der Server antwortet mit ServerHello, wählt Protokollversion und Cipher Suite aus und legt sein Zertifikat vor. Nach dem Schlüsselaustausch bestätigen beide Seiten mit einer Finished-Nachricht, die einen MAC über den gesamten bisherigen Handshake enthält, damit nachträgliche Manipulation auffällt. Erst danach beginnt die Record Layer, Nutzdaten mit einem aus dem Handshake abgeleiteten symmetrischen Session Key zu verschlüsseln.

Der Unterschied zwischen TLS 1.2 und TLS 1.3 zeigt sich genau hier: TLS 1.2 benötigt zwei vollständige Round Trips, weil Cipher-Suite-Aushandlung und Schlüsselaustausch getrennte Schritte sind. TLS 1.3 sendet den Key Share bereits im ClientHello und kommt mit einem Round Trip aus, zusätzlich ermöglicht 0-RTT Resumption bei wiederkehrenden Verbindungen einen noch schnelleren Start. Für Magento-Checkout-Prozesse mit vielen einzelnen HTTPS-Verbindungen ist dieser Unterschied spürbar, allerdings birgt 0-RTT ein Replay-Risiko bei nicht-idempotenten Requests wie einer Zahlungsauswahl und sollte dafür deaktiviert bleiben.

2. TLS 1.0/1.1 abschalten: TLS 1.2 vs. TLS 1.3

TLS 1.0 stammt aus dem Jahr 1999 und teilt sich strukturelle Schwächen mit dem noch älteren SSLv3: Der POODLE-Angriff nutzt einen Downgrade auf CBC-Padding aus, BEAST bricht CBC-Verschlüsselung durch vorhersagbare Initialisierungsvektoren, und der Handshake selbst erlaubt schwache Hash-Funktionen wie MD5 und SHA-1. TLS 1.1 behebt nur einen Teil dieser Probleme und gilt seit Jahren als ebenso veraltet. Der PCI Security Standards Council verlangt seit dem 30. Juni 2018 verbindlich TLS 1.2 als Minimum für jedes System, das Kreditkartendaten verarbeitet, und große Payment Gateways wie Adyen oder Braintree haben Verbindungen über TLS 1.0/1.1 längst vollständig eingestellt.

TLS 1.2 bleibt trotzdem praktisch relevant, weil vereinzelte Legacy-Clients, etwa ältere Android-Versionen oder eingebettete IoT-Geräte, kein TLS 1.3 unterstützen. TLS 1.3 selbst (RFC 8446, seit 2018 final) entfernt statischen RSA-Schlüsselaustausch vollständig aus der Spezifikation, erzwingt damit Forward Secrecy für jede Verbindung, verbietet unsichere Legacy-Cipher wie RC4 und 3DES von vornherein und verschlüsselt größere Teile des Handshakes selbst, das Zertifikat wird beispielsweise erst nach der Schlüsseleinigung übertragen. Ein Magento-Shop sollte TLS 1.2 und TLS 1.3 gleichzeitig anbieten und alles darunter konsequent deaktivieren.

3. Cipher Suites richtig wählen: Forward Secrecy mit ECDHE

Eine Cipher Suite legt fest, wie Schlüsselaustausch, Authentifizierung, symmetrische Verschlüsselung und Integritätsprüfung kombiniert werden. Bei statischem RSA-Schlüsselaustausch (etwa TLS_RSA_WITH_AES_128_CBC_SHA) leitet sich der Session Key direkt aus dem langfristigen privaten RSA-Schlüssel des Servers ab. Zeichnet ein Angreifer verschlüsselten Traffic auf und erbeutet Jahre später durch ein Datenleck den privaten Schlüssel, lassen sich damit rückwirkend alle aufgezeichneten Sessions entschlüsseln. Genau dieses Szenario war einer der Gründe, warum Forward Secrecy heute als Pflicht gilt.

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) erzeugt für jede einzelne Verbindung einen neuen, temporären Schlüssel, der nach Ende der Session verworfen wird. Ein später kompromittierter privater Schlüssel schützt damit nur zukünftige, niemals aber vergangene Sessions, das ist die Kerneigenschaft von Forward Secrecy. Empfehlenswerte Cipher Suites kombinieren ECDHE mit AEAD-Verschlüsselungsmodi wie AES-GCM oder ChaCha20-Poly1305 statt CBC mit separatem HMAC, da CBC-Konstruktionen anfällig für Timing-Angriffe wie Lucky13 waren. ChaCha20-Poly1305 ist zusätzlich auf Mobilgeräten ohne AES-NI-Hardwarebeschleunigung spürbar performanter als AES-GCM.

4. Zertifikatsketten validieren: Das Problem fehlender Intermediates

Ein TLS-Zertifikat ist niemals isoliert gültig, sondern Teil einer Kette: eine Root-CA, die im Trust Store von Betriebssystem oder Browser fest hinterlegt ist, ein oder mehrere Intermediate-Zertifikate, und das eigentliche Leaf-Zertifikat für die konkrete Domain. Clients vertrauen ausschließlich den vorinstallierten Root-Zertifikaten direkt. Damit ein Client die Kette bis zu dieser vertrauenswürdigen Root nachvollziehen kann, muss der Server sämtliche Intermediate-Zertifikate zusammen mit dem Leaf-Zertifikat ausliefern, die Root selbst wird nie mitgesendet.

Der häufigste Konfigurationsfehler in der Praxis: Nur das Leaf-Zertifikat wird auf dem Server hinterlegt, die Intermediates fehlen komplett. Moderne Chrome-Versionen kaschieren das oft durch AIA Fetching, ein automatisches Nachladen fehlender Intermediates über die im Zertifikat hinterlegte Authority-Information-Access-URL. Ältere Browser, mobile Apps, viele Payment-SDKs, curl-Aufrufe von Server zu Server und Monitoring-Tools verfügen über dieses Fallback jedoch nicht und scheitern mit einem Fehler wie unable to get local issuer certificate. Das Ergebnis ist ein Shop, der im eigenen Browser einwandfrei funktioniert, aber bei einem relevanten Teil echter Nutzer und bei Server-zu-Server-Integrationen wie Payment-Callbacks fehlschlägt.

# Show the full certificate chain a server actually presents
openssl s_client -connect mironsoft.de:443 -servername mironsoft.de -showcerts </dev/null 2>/dev/null

# Print the leaf certificate details: issuer, validity period, SAN entries
openssl s_client -connect mironsoft.de:443 -servername mironsoft.de </dev/null 2>/dev/null \
  | openssl x509 -noout -text

# Verify the chain against the local system trust store
openssl s_client -connect mironsoft.de:443 -servername mironsoft.de -CApath /etc/ssl/certs </dev/null 2>&1 \
  | grep -E "Verify return code|depth"

# Typical output when an intermediate certificate is missing on the server:
# depth=0 CN = mironsoft.de
# verify error:num=20:unable to get local issuer certificate
# Verify return code: 21 (unable to verify the first certificate)

5. Let's Encrypt und ACME-Automatisierung mit certbot

Let's Encrypt stellt kostenlose, automatisiert ausgestellte Zertifikate über das ACME-Protokoll aus, certbot ist dabei der am weitesten verbreitete ACME-Client. Die HTTP-01-Challenge beweist Domain-Kontrolle über eine Datei unter /.well-known/acme-challenge/, die DNS-01-Challenge über einen TXT-Record im DNS und ist zwingend erforderlich für Wildcard-Zertifikate wie *.mironsoft.de, weil HTTP-01 ausschließlich einzelne, konkret erreichbare Hostnamen validieren kann.

Zertifikate von Let's Encrypt sind bewusst nur 90 Tage gültig, das erzwingt Automatisierung anstelle manueller Verlängerung, die in der Praxis regelmäßig vergessen wird und zu abgelaufenen Zertifikaten führt. certbot renew prüft automatisch alle installierten Zertifikate und erneuert ausschließlich diejenigen, die innerhalb der nächsten 30 Tage ablaufen. Ein systemd-Timer oder Cronjob, der zweimal täglich läuft, ist dafür Best Practice, weil er genug Puffer für temporäre Fehler wie DNS-Ausfälle lässt. Ein deploy-hook lädt den Webserver ohne Downtime neu, sobald tatsächlich ein neues Zertifikat vorliegt, statt bei jedem Cron-Lauf unnötig neu zu starten.

# Install certbot with the nginx plugin (Debian/Ubuntu)
apt-get install -y certbot python3-certbot-nginx

# Issue a certificate and let certbot configure the nginx vhost automatically
certbot --nginx -d mironsoft.de -d www.mironsoft.de \
  --agree-tos -m ops@mironsoft.de --redirect

# Dry run to verify the renewal flow without hitting Let's Encrypt rate limits
certbot renew --dry-run

# /etc/cron.d/certbot-renew: run twice daily, certbot silently skips
# certificates outside the 30 day renewal window on its own
0 3,15 * * * root certbot renew --quiet --deploy-hook "systemctl reload nginx"

# Deploy hook: reloads nginx without downtime, only runs after
# certbot has actually renewed a certificate
#!/usr/bin/env bash
set -euo pipefail
nginx -t && systemctl reload nginx

6. HSTS konfigurieren: Preload-Liste und includeSubDomains

Ein korrektes TLS-Setup schützt allein noch nicht vor dem allerersten Request, der über HTTP erfolgt, etwa weil ein Nutzer die Domain ohne https:// eintippt. Der Strict-Transport-Security-Header weist den Browser an, für die angegebene max-age-Dauer jede zukünftige Anfrage an diese Domain automatisch und ohne Server-Roundtrip zu HTTPS umzuleiten. Das schließt SSL-Stripping-Angriffe in einem Man-in-the-Middle-Szenario, bei denen ein Angreifer den initialen HTTP-Request abfängt, bevor die Weiterleitung zu HTTPS überhaupt greifen kann.

Die Direktive includeSubDomains erzwingt HTTPS auch für alle Subdomains und sollte sorgfältig geprüft werden, weil eine einzelne Subdomain ohne gültiges Zertifikat dadurch für Nutzer komplett unerreichbar wird. Die HSTS-Preload-Liste geht noch einen Schritt weiter: Domains werden fest in Chrome, Firefox und Safari einkompiliert, sodass selbst der allererste Request an diese Domain niemals unverschlüsselt passiert. Die Aufnahme über hstspreload.org ist praktisch unumkehrbar für viele Monate, weil Browser-Updates Zeit brauchen, und sollte deshalb erst erfolgen, nachdem HTTPS auf allen Subdomains nachweislich stabil läuft.

<?php

declare(strict_types=1);

namespace Mironsoft\Security\Plugin;

use Magento\Framework\App\Request\Http as HttpRequest;
use Magento\Framework\App\Response\Http as HttpResponse;

/**
 * Plugin that ensures every HTTPS response carries a correctly configured
 * Strict-Transport-Security header, independent of the webserver configuration.
 */
class AddStrictTransportSecurityHeaderPlugin
{
    /**
     * @param HttpRequest $request Current HTTP request, used to detect a secure connection.
     * @param int $maxAge Header max-age value in seconds, defaults to two years.
     * @param bool $includeSubDomains Whether the includeSubDomains directive is appended.
     * @param bool $preload Whether the preload directive is appended.
     */
    public function __construct(
        private readonly HttpRequest $request,
        private readonly int $maxAge = 63072000,
        private readonly bool $includeSubDomains = true,
        private readonly bool $preload = true,
    ) {
    }

    /**
     * Adds the Strict-Transport-Security header before the response is sent.
     *
     * @param HttpResponse $subject The response object about to be dispatched.
     * @return void
     */
    public function beforeSendResponse(HttpResponse $subject): void
    {
        if ($this->request->isSecure()) {
            $subject->setHeader('Strict-Transport-Security', $this->buildHeaderValue(), true);
        }
    }

    /**
     * Builds the header value from the configured directives.
     *
     * @return string The assembled Strict-Transport-Security header value.
     */
    private function buildHeaderValue(): string
    {
        $directives = ['max-age=' . $this->maxAge];

        if ($this->includeSubDomains) {
            $directives[] = 'includeSubDomains';
        }

        if ($this->preload) {
            $directives[] = 'preload';
        }

        return implode('; ', $directives);
    }
}

7. TLS in der Praxis härten: nginx und Apache

Eine gehärtete nginx-Konfiguration beschränkt ssl_protocols auf TLSv1.2 und TLSv1.3, definiert eine explizite ssl_ciphers-Liste mit ECDHE- und AEAD-Cipher-Suites in sinnvoller Reihenfolge und aktiviert OCSP Stapling. Dabei ruft der Server den Sperrstatus seines eigenen Zertifikats vorab beim CA-Server ab und liefert ihn direkt mit dem Handshake mit, statt jeden einzelnen Client selbst beim CA-Server anfragen zu lassen. Das reduziert Handshake-Latenz und verhindert zusätzlich, dass die CA das Surfverhalten einzelner Nutzer nachvollziehen kann.

Session Resumption über TLS Session Tickets beschleunigt wiederkehrende Verbindungen deutlich, die zugrunde liegenden Ticket-Encryption-Keys sollten aber regelmäßig rotiert werden, damit ein kompromittierter Key nicht dauerhaft alte Sessions entschlüsselbar macht. Für containerisierte Setups übernehmen Traefik oder nginx-proxy TLS-Terminierung und ACME-Automatisierung gleichzeitig und sparen dadurch eine separate certbot-Installation. Der Mozilla SSL Configuration Generator liefert aktuelle, getestete Konfigurationsvorlagen für nginx, Apache und weitere Server nach Kompatibilitätsstufe, statt Cipher-Listen aus veralteten Blogartikeln zu kopieren, die häufig längst unsichere Cipher enthalten.

version: "3.9"
services:
  reverse-proxy:
    image: traefik:v3.1
    command:
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
      # Redirect all plain HTTP traffic to HTTPS
      - --entrypoints.web.http.redirections.entryPoint.to=websecure
      - --entrypoints.web.http.redirections.entryPoint.scheme=https
      # Apply the minimum TLS version defined in dynamic_conf.yml
      - --entrypoints.websecure.http.tls.options=default
      - --providers.file.filename=/etc/traefik/dynamic_conf.yml
      - --certificatesresolvers.letsencrypt.acme.email=ops@mironsoft.de
      - --certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json
      - --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "letsencrypt:/letsencrypt"
      - "./dynamic_conf.yml:/etc/traefik/dynamic_conf.yml:ro"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  magento:
    image: mironsoft/magento-web:2.4.8-p4
    labels:
      - traefik.enable=true
      - traefik.http.routers.magento.rule=Host(`mironsoft.de`)
      - traefik.http.routers.magento.entrypoints=websecure
      - traefik.http.routers.magento.tls.certresolver=letsencrypt

volumes:
  letsencrypt:

# dynamic_conf.yml: forces TLS 1.2 as the minimum negotiated version
# tls:
#   options:
#     default:
#       minVersion: VersionTLS12
#       cipherSuites:
#         - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
#         - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name mironsoft.de www.mironsoft.de;

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

    # Only TLS 1.2 and TLS 1.3, no legacy protocol versions
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # OCSP stapling: the server fetches revocation status once and serves it to every client
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/mironsoft.de/chain.pem;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    # Session resumption without weakening forward secrecy guarantees
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    location / {
        proxy_pass http://magento_upstream;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name mironsoft.de www.mironsoft.de;
    return 301 https://$host$request_uri;
}

8. Testen und Überwachen: SSL Labs und testssl.sh

Der Qualys SSL Labs Test (ssllabs.com/ssltest) prüft Protokollversionen, Cipher Suites, Zertifikatskette, Forward Secrecy und bekannte Schwachstellen wie Heartbleed oder POODLE gegen eine öffentlich erreichbare Domain und vergibt eine Note von A+ bis F. Das ist der Industriestandard für eine schnelle, unabhängige externe Einschätzung und eignet sich hervorragend, um Änderungen an der TLS-Konfiguration vor dem Go-Live zu verifizieren.

testssl.sh ist die passende Ergänzung für CI/CD-Pipelines und interne Systeme ohne öffentliche Erreichbarkeit, weil es lokal oder direkt in der Pipeline läuft und dieselben Prüfungen als Kommandozeilen-Tool mit maschinenlesbarem Output durchführt. Kontinuierliches Monitoring bleibt wichtig, weil sich Best Practices verschieben: Browser-Anbieter haben den Support für TLS 1.0/1.1 2020 und 2021 koordiniert entfernt, und neue Schwachstellen in Cipher-Implementierungen tauchen regelmäßig auf. Zertifikatsablauf sollte zusätzlich über eigenständiges Monitoring, etwa Expiry-Checks per Cronjob oder ein Uptime-Tool, überwacht werden, unabhängig von der certbot-Automatisierung selbst, damit ein stiller Fehler in der Renewal-Pipeline nicht erst beim Ablauf des Zertifikats auffällt.

9. Unsicher vs. sicher im direkten Vergleich

Die größten TLS-Risiken in der Praxis liegen selten in exotischen Angriffen, sondern in wenigen, immer wiederkehrenden Konfigurationsfehlern. Die folgende Übersicht stellt die unsichere Variante der sicheren, empfohlenen Konfiguration gegenüber.

Diese sechs Punkte hängen in der Praxis eng zusammen: Ein Shop mit korrekt konfigurierten Protokollversionen und Cipher Suites, aber fehlenden Intermediate-Zertifikaten, gilt bei automatisierten Scans trotzdem als fehlerhaft. Wer alle sechs Bereiche gemeinsam absichert und regelmäßig über SSL Labs oder testssl.sh verifiziert, erreicht eine TLS-Konfiguration, die nicht nur im eigenen Browser, sondern für alle realen Clients zuverlässig funktioniert.

10. Zusammenfassung

TLS/SSL Best Practices lösen ein Kernproblem: Eine verschlüsselte Verbindung allein garantiert noch keine Sicherheit, wenn Protokollversion, Cipher Suite, Zertifikatskette und begleitende Header wie HSTS nicht sauber zusammenspielen. TLS 1.0 und TLS 1.1 gehören konsequent deaktiviert, TLS 1.2 als Minimum und TLS 1.3 als bevorzugte Version bilden die Basis. ECDHE-Cipher-Suites mit AEAD-Verschlüsselung liefern Forward Secrecy, eine vollständige Zertifikatskette inklusive aller Intermediates verhindert Fehlschläge bei Clients ohne AIA-Fetching, und automatisierte Erneuerung über certbot oder eine ACME-fähige Reverse-Proxy-Lösung wie Traefik eliminiert das Risiko abgelaufener Zertifikate.

Der entscheidende Unterschied zwischen einer TLS-Konfiguration, die in der Praxis funktioniert, und einer, die nur im eigenen Browser gut aussieht, liegt in der konsequenten Umsetzung aller sechs Bereiche gleichzeitig und in kontinuierlicher Verifikation über SSL Labs und testssl.sh. HSTS mit includeSubDomains und, nach stabilem Betrieb, Aufnahme in die Preload-Liste schließt die letzte Lücke: den allerersten, potenziell unverschlüsselten Request, bevor die TLS-Konfiguration überhaupt greifen kann.

11. FAQ: TLS/SSL Best Practices