Nginx SSL/TLS in der Praxis: von HTTPS-Zertifikaten bis A+ Sicherheitshärtung

Der Monitoring-Alarm schrillte plötzlich. Handy gezückt – das Website-Zertifikat war abgelaufen. Das 90-tägige Gratis-Zertifikat war schlicht vergessen worden. Die rote „Nicht sicher“-Warnung im Browser hing wie ein spöttisches Banner auf der Blog-Startseite.

Nach dem Vorfall habe ich eine Woche investiert und die Nginx-SSL/TLS-Konfiguration von Grund auf durchgearbeitet. SSL-Labs-Bewertung von F auf A+, manuelle Verlängerung auf Vollautomatik, Performance von Bremsklotz auf Handshake-Zeiten unter 100 ms.

HTTPS bedeutet mehr als ein Schloss in der Adresszeile. Google nennt HTTPS ausdrücklich einen Ranking-Faktor – korrekt konfiguriert kann der Suchtraffic um 15–20 % steigen. Wichtiger noch: Es verhindert Man-in-the-Middle-Angriffe. Ohne HTTPS sprechen Sie im Grunde lautstark Ihre Bankdaten in der Öffentlichkeit aus.

Dieser Artikel führt Sie Schritt für Schritt durch die Nginx-HTTPS-Konfiguration: Let’s-Encrypt-Zertifikate, TLS-1.3-Härtung, SSL-Labs-A+-Vorlage und die für Produktionsumgebungen unverzichtbare automatische Verlängerung. Alle Konfigurationen können Sie direkt übernehmen.

Kapitel 1: HTTPS-Grundlagen und Zertifikatstypen

1.1 Warum jede Website HTTPS braucht

HTTP überträgt im Klartext – jede Seite, jedes Formular läuft ungeschützt durchs Netz. Öffentliches WLAN im Café, Firmen-Gateway, Provider-Router am Wohnblock: Jeder Knoten dazwischen kann mitlesen.

HTTPS fügt zwischen HTTP und TCP eine TLS-Verschlüsselungsschicht ein. Daten werden vor dem Versand verschlüsselt und erst beim Empfänger entschlüsselt – Angreifer sehen nur Zeichenmüll.

TLS leistet mehr als Verschlüsselung. Es authentifiziert die Identität – Sie erreichen wirklich example.com, nicht eine per DNS-Hijacking umgeleitete Phishing-Seite. Deshalb warnt der Browser bei abgelaufenen oder nicht passenden Zertifikaten rot: „Diese Website ist möglicherweise nicht die, die sie vorgibt zu sein.“

1.2 Die drei SSL-Zertifikatstypen: DV, OV, EV

Zertifikate unterscheiden sich nach Prüfstrenge:

Für die meisten persönlichen Projekte und kleine Teams reicht ein DV-Zertifikat völlig aus. Das kostenlose Let’s-Encrypt-DV-Zertifikat ist 90 Tage gültig und genauso vertrauenswürdig wie kostenpflichtige DV-Zertifikate. Der einzige „Nachteil“: alle 90 Tage erneuern – mit automatischer Verlängerung kein Problem.

OV- und EV-Zertifikate unterscheiden sich vor allem in der Darstellung in der Adresszeile. EV-Zertifikate zeigten früher den Firmennamen (z. B. „Industrial and Commercial Bank of China“) – heute betonen Browser EV kaum noch, Chrome zeigt den Firmennamen standardmäßig nicht mehr. Bei Preisen von mehreren hundert Euro ist das Preis-Leistungs-Verhältnis oft schlecht.

1.3 Let’s Encrypt: die beste Wahl für kostenlose Zertifikate

Let’s Encrypt wird von der ISRG (Internet Security Research Group) betrieben. Kernvorteile:

• Völlig kostenlos: DV-Zertifikate dauerhaft gratis
• Automatisierung: Ausstellung und Verlängerung per ACME-Protokoll
• Breites Vertrauen: alle gängigen Browser und Betriebssysteme
• 90 Tage Gültigkeit: kurze Laufzeit erhöht Sicherheit und erzwingt Automatisierung

Nachteile: nur DV, kein OV/EV; Wildcard-Zertifikate erfordern DNS-Validierung (etwas aufwendiger). Für 99 % der persönlichen und mittelgroßen Websites sind das keine echten Hindernisse.

Als Nächstes beantragen wir das Zertifikat mit Certbot – dem offiziellen Let’s-Encrypt-Client.

Kapitel 2: Let’s-Encrypt-Zertifikat in der Praxis

2.1 Certbot installieren

Die Installation hängt vom Betriebssystem ab. Unter Ubuntu am einfachsten:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

# Ubuntu 20.04+ / Debian 10+
sudo apt update
sudo apt install certbot python3-certbot-nginx

Unter CentOS/RHEL zuerst das EPEL-Repository aktivieren:

# CentOS 8 / RHEL 8
sudo dnf install epel-release
sudo dnf install certbot python3-certbot-nginx

Nach der Installation mit certbot --version die Version prüfen. Dann geht es an die Zertifikatsanforderung.

2.2 Zertifikat beantragen

Certbot unterstützt mehrere Validierungsmodi; am häufigsten: standalone und webroot. Läuft Nginx bereits, empfehle ich webroot:

# webroot-Modus: wenn die Website bereits läuft
sudo certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com

-w setzt das Webroot-Verzeichnis, -d die Domain. Mehrere Domains in einem Zertifikat sind möglich.

Ist Nginx noch nicht gestartet oder testen Sie auf einem temporären Server, eignet sich standalone:

# standalone-Modus: benötigt temporär Port 80
sudo certbot certonly --standalone -d example.com -d www.example.com

Certbot startet kurz einen HTTP-Server zur Validierung und beendet ihn danach. Port 80 muss frei sein – läuft Nginx, vorher stoppen.

Noch einfacher: das Nginx-Plugin passt die Konfiguration automatisch an:

# Automatik-Modus: Certbot ändert Nginx-Konfiguration
sudo certbot --nginx -d example.com -d www.example.com

Zertifikat, HTTPS und Weiterleitung in einem Schritt – gut für Einsteiger. In Produktion empfehle ich manuelle Konfiguration für feinere SSL-Parameter-Kontrolle.

2.3 Zertifikatsdateistruktur

Nach erfolgreicher Beantragung liegen die Dateien standardmäßig unter /etc/letsencrypt/live/example.com/:

/etc/letsencrypt/live/example.com/
├── cert.pem        # Domain-Zertifikat
├── chain.pem       # Intermediate-Zertifikatskette
├── fullchain.pem   # Vollständige Kette (cert + chain)
└── privkey.pem     # Privater Schlüssel

Für Nginx brauchen Sie zwei Dateien: fullchain.pem (ssl_certificate) und privkey.pem (ssl_certificate_key). privkey.pem ist sensibel – Berechtigung 600, niemals weitergeben.

Kapitel 3: Nginx-SSL-Grundkonfiguration

3.1 Minimale HTTPS-Konfiguration

Mit Zertifikat folgt die Nginx-Konfiguration. Die einfachste Variante:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Weitere Konfiguration...
    root /var/www/example.com;
    index index.html;
}

Damit läuft HTTPS – aber höchstens Note D. Ohne TLS-Versionen unterstützt Nginx standardmäßig TLS 1.0 und 1.1, die längst als unsicher gelten.

3.2 HTTP auf HTTPS umleiten

HTTPS allein reicht nicht – Nutzer können HTTP direkt aufrufen. Alle HTTP-Anfragen auf HTTPS umleiten:

server {
    listen 80;
    server_name example.com www.example.com;

    # Permanente Weiterleitung auf HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Weitere Konfiguration...
}

return 301 ist permanent – der Browser cached die Weiterleitung. Beim nächsten http://-Aufruf springt er direkt auf https://.

3.3 Ein häufiger Konfigurationsfehler

Viele schreiben hinter listen 443 ssl; noch http2 als listen 443 ssl http2;. Ab Nginx 1.25.1 gehört HTTP/2 zur separaten http2-Direktive:

# Neue Schreibweise ab Nginx 1.25.1+
server {
    listen 443 ssl;
    http2 on;  # separate http2-Direktive
    server_name example.com;

    # ...
}

Bei neueren Nginx-Versionen die neue Syntax verwenden, um Warnungen zu vermeiden. Version mit nginx -v prüfen.

Kapitel 4: TLS-1.3-Sicherheitshärtung

4.1 TLS-Version wählen

Es gibt vier TLS-Versionen: 1.0, 1.1, 1.2, 1.3. Versionen 1.0 und 1.1 sind obsolet; alle gängigen Browser unterstützen sie seit 2020 nicht mehr.

Der Kernvorteil von TLS 1.3 ist Performance: Handshake von 2-RTT (Round-Trip) auf 1-RTT – theoretisch halbierte Latenz. In der Praxis oft unter 100 ms Handshake-Zeit.

In Nginx steuert ssl_protocols die Versionen:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

ssl_protocols TLSv1.2 TLSv1.3;

Nur TLS 1.3 ist nicht empfehlenswert. 2026 unterstützen fast alle Browser TLS 1.3, aber ältere HTTP-Clients (API-Tools, Embedded-Geräte) manchmal noch nicht. TLS 1.2 als Fallback ist die sichere Wahl.

4.2 Cipher-Suite-Konfiguration

Die Cipher Suite legt Verschlüsselungsalgorithmus, Schlüsselaustausch und MAC fest. Falsche Wahl – HTTPS wirkungslos.

Empfohlene TLS-1.3-Cipher-Suites 2026:

ssl_protocols TLSv1.2 TLSv1.3;

# TLS-1.3-Ciphers (Nginx nutzt OpenSSL-Standardliste)
# Zeile optional, Schaden tut sie nicht
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

# TLS-1.2-Ciphers (Abwärtskompatibilität)
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;

# Server-Ciphers bevorzugen
ssl_prefer_server_ciphers on;

Kernpunkte:

• ECDHE: elliptische Kurven für Schlüsselaustausch – sicherer und schneller als RSA
• AES-GCM: authentifizierte Verschlüsselung, sicherer als CBC
• CHACHA20-POLY1305: bessere Mobile-Performance ohne AES-Hardwarebeschleunigung

Bei Unsicherheit: Mozilla SSL Configuration Generator – https://ssl-config.mozilla.org/

4.3 HSTS: HTTPS erzwingen

HSTS (HTTP Strict Transport Security) teilt dem Browser mit: „Diese Site akzeptiert nur HTTPS.“ Selbst manuelles http:// wird lokal auf https:// umgeleitet – ein Netzwerk-Roundtrip weniger.

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

Parameter:

• max-age=31536000: Gültigkeit 1 Jahr (Sekunden)
• includeSubDomains: gilt für alle Subdomains
• preload: Eintrag in HSTS-Preload-Liste (Submission auf hstspreload.org)

Achtung: HSTS wird vom Browser lange gecacht. Noch HTTP testen? Erst ohne preload oder mit kürzerem max-age.

Kapitel 5: SSL-Performance-Optimierung

5.1 SSL Session Cache

Jeder TLS-Handshake erfordert Schlüsselaustausch und Zertifikatsprüfung – nicht billig. Session Cache erlaubt Clients, eine Sitzung innerhalb einer Frist wiederzuverwenden und den vollen Handshake zu überspringen.

# Session-Cache-Konfiguration
ssl_session_cache shared:SSL:10m;  # 10 MB Cache, ca. 40.000 Sitzungen
ssl_session_timeout 1d;            # Sitzungsgültigkeit 1 Tag
ssl_session_tickets off;           # Session Tickets deaktivieren (sicherer)

shared:SSL:10m: alle Worker teilen 10 MB Cache. 1 MB speichert ca. 4.000 Sitzungen – für mittelgroße Sites ausreichend.

ssl_session_tickets off aus Sicherheitsgründen. Session Tickets benötigen einen Server-Schlüssel; bei Leck können historische Sitzungen entschlüsselt werden. Deaktivierung sicherer, etwas mehr Serverlast – bei hohen Sicherheitsanforderungen sinnvoll.

5.2 OCSP Stapling

Bei der Zertifikatsprüfung muss der Browser prüfen, ob das Zertifikat widerrufen wurde. Klassisch per OCSP-Anfrage an die CA – extra Netzwerkrequest, der verrät, welche Sites Sie besuchen.

OCSP Stapling: Der Server holt den OCSP-Status, cached ihn und liefert ihn mit – mehr Privatsphäre, weniger Latenz.

# OCSP-Stapling-Konfiguration
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

resolver setzt DNS-Server zur Auflösung des OCSP-Server-Hostnamens. Google 8.8.8.8 und 8.8.4.4 sind gängige Wahl.

Nach der Konfiguration mit OpenSSL testen:

openssl s_client -connect example.com:443 -status < /dev/null 2>&1 | grep -A 17 "OCSP response"

Bei „OCSP Response Status: successful“ funktioniert OCSP Stapling.

5.3 ssl_buffer_size optimieren

ssl_buffer_size steuert die TLS-Record-Größe. Standard 16 KB – für kleine Responses (API, Blog) oft zu groß, erhöht TTFB (Time to First Byte).

Für Sites mit vielen kleinen Responses:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

ssl_buffer_size 4k;  # für kleine Responses

Für große Downloads: Standard 16 KB oder 32 KB beibehalten.

Kapitel 6: Automatische Zertifikatsverlängerung

6.1 Certbot-Verlängerungsbefehl

Let’s-Encrypt-Zertifikate sind 90 Tage gültig – regelmäßige Verlängerung nötig. Certbot bietet renew:

# Test-Verlängerung (ohne tatsächliche Erneuerung)
sudo certbot renew --dry-run

# Tatsächliche Verlängerung
sudo certbot renew

renew prüft alle Zertifikate und erneuert nur, wenn weniger als 30 Tage Restlaufzeit. Tägliche Ausführung ist unkritisch – verschwendet kein Let’s-Encrypt-Rate-Limit.

6.2 Crontab einrichten

Zuverlässigste Methode: automatische Verlängerung per crontab:

# crontab des root-Benutzers bearbeiten
sudo crontab -e

Diese zwei Zeilen hinzufügen:

# Täglich um 3:00 und 15:00 Uhr prüfen
0 3 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"
0 15 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"

--quiet: wenig Log-Ausgabe. --post-hook "systemctl reload nginx": nach erfolgreicher Verlängerung Nginx neu laden, damit das neue Zertifikat aktiv wird.

Warum zweimal täglich? Verlängerung schlägt gelegentlich fehl (z. B. temporäre DNS-Probleme) – mehrere Versuche erhöhen die Erfolgsrate.

6.3 Verlängerung testen und Fehler beheben

Bei Fehlern protokolliert Certbot in /var/log/letsencrypt/letsencrypt.log. Häufige Probleme:

1. Port belegt: Standalone-Modus braucht Port 80 frei
2. DNS-Auflösung fehlgeschlagen: DNS muss auf den Server zeigen
3. Rate-Limit: max. 5 gleiche Zertifikate pro Woche – Tests mit --dry-run
4. Verzeichnisrechte: Certbot braucht Schreibzugriff auf /etc/letsencrypt/

Vollständiger Testablauf:

# 1. dry-run
sudo certbot renew --dry-run

# 2. Bei Erfolg tatsächlich verlängern
sudo certbot renew

# 3. Gültigkeit prüfen
sudo certbot certificates

# 4. Nginx neu laden
sudo systemctl reload nginx

Vollständige Konfigurationsvorlage

Produktionsreife Nginx-SSL-Konfiguration mit SSL-Labs-A+-Bewertung:

# HTTP-Weiterleitung
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

# HTTPS-Server
server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    # Zertifikat
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # TLS-Versionen
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher Suite
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256: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 on;

    # Sicherheits-Header
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Frame-Options SAMEORIGIN always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-XSS-Protection "1; mode=block" always;

    # Session Cache
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # Performance
    ssl_buffer_size 4k;

    # Website
    root /var/www/example.com;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}

Nach der Konfiguration mit SSL Labs testen: https://www.ssllabs.com/ssltest/

Fazit

HTTPS einrichten ist leicht – wenige Zeilen reichen zum Start. SSL-Labs A+ mit guter Performance und Kompatibilität erfordert Verständnis von TLS-Versionen, Cipher Suites, Session Cache und OCSP Stapling.

Kernpunkte im Überblick:

1. Zertifikat: Let’s Encrypt kostenlos, Certbot automatisiert
2. TLS-Versionen: TLS 1.2 + 1.3, 1.0 und 1.1 deaktivieren
3. Cipher Suite: ECDHE und AES-GCM bevorzugen, CHACHA20 ergänzen
4. HSTS: HTTPS erzwingen, Weiterleitungs-Overhead reduzieren
5. Performance: Session Cache und OCSP Stapling sind Pflicht
6. Automatische Verlängerung: crontab doppelt absichern, Nginx-Reload nach Erfolg

Vorlage kopieren, Domain und Zertifikatspfade anpassen – fertig. Danach SSL-Labs testen und in den Kommentaren Ihr Ergebnis teilen – vermutlich A+.