Let's Encrypt SSL/TLS fuer Nginx einrichten auf Debian 12 und Ubuntu 24.04

11 Min. Lesezeit·Matthieu|

Kostenlose TLS-Zertifikate mit Certbot fuer Nginx auf Debian 12 oder Ubuntu 24.04 beziehen und automatisch erneuern. DNS-Konfiguration, Certbot-Installation, HTTP-zu-HTTPS-Weiterleitung, TLS-Haertung, HTTP/2, HSTS und die OCSP-Abschaltung.

Let's Encrypt SSL/TLS fuer Nginx einrichten auf Debian 12 und Ubuntu 24.04

Diese Anleitung fuehrt Sie durch den Bezug eines kostenlosen TLS-Zertifikats von Let's Encrypt mit Certbot, die Konfiguration von Nginx fuer HTTPS und die Einrichtung der automatischen Erneuerung. Jeder Schritt enthaelt einen Pruefbefehl, damit Sie das Ergebnis verifizieren koennen, bevor Sie weitergehen.

Falls Sie Nginx noch nicht installiert haben, beginnen Sie mit Nginx auf Debian 12 und Ubuntu 24.04 installieren. Einen Gesamtueberblick ueber die Nginx-Verwaltung auf einem VPS finden Sie unter Nginx-Administration auf einem VPS.

Was benoetigen Sie vor der Zertifikatsanforderung?

Bevor Certbot ein Zertifikat ausstellen kann, muss Ihre Domain auf die IP-Adresse Ihres Servers verweisen, und Nginx muss mit einem Server Block fuer diese Domain laufen. Let's Encrypt validiert die Domain-Inhaberschaft durch einen HTTP-Request an Ihren Server. Falls DNS nicht auf Ihren VPS aufloest oder Nginx nicht lauscht, schlaegt die Challenge fehl.

Sie benoetigen:

  • Einen VPS mit Debian 12 oder Ubuntu 24.04 und Nginx aus dem offiziellen Repository (Nginx auf Debian 12 und Ubuntu 24.04 installieren)
  • Einen registrierten Domainnamen (wir verwenden durchgehend example.com)
  • Einen A-Record, der example.com auf die IPv4-Adresse Ihres Servers zeigt
  • Einen AAAA-Record, der auf Ihre IPv6-Adresse zeigt (falls Ihr Server eine hat)
  • Port 80 offen in Ihrer Firewall (Certbot nutzt HTTP-01 Challenges)
  • Einen funktionierenden Nginx Server Block fuer Ihre Domain (Nginx Server Blocks)

DNS-Eintraege einrichten

Erstellen Sie einen A-Record bei Ihrem DNS-Anbieter:

Typ Name Wert TTL
A example.com 203.0.113.10 300
AAAA example.com 2001:db8::1 300

Ersetzen Sie die IP-Adressen durch die tatsaechlichen Adressen Ihres Servers. Setzen Sie die TTL waehrend der Einrichtung niedrig (300 Sekunden), damit Aenderungen schnell propagieren. Spaeter koennen Sie den Wert erhoehen.

DNS-Aufloesung pruefen

Warten Sie einige Minuten nach dem Anlegen der Eintraege und pruefen Sie dann von Ihrem lokalen Rechner (nicht vom Server):

dig +short example.com A
dig +short example.com AAAA

Sie sollten die IP-Adressen Ihres Servers in der Ausgabe sehen. Falls nichts oder eine andere IP angezeigt wird, hat der Eintrag sich noch nicht verbreitet. Warten Sie und versuchen Sie es erneut.

Pruefen Sie, ob Nginx auf Port 80 antwortet, von Ihrem lokalen Rechner aus:

curl -I http://example.com

Sie sollten eine HTTP/1.1 200 OK-Antwort mit Server: nginx erhalten. Falls die Verbindung abbricht, pruefen Sie Ihre Firewall-Regeln.

Wie installieren Sie Certbot auf Debian 12 und Ubuntu 24.04?

Installieren Sie Certbot und das Nginx-Plugin aus dem Paket-Repository Ihrer Distribution mit apt. Das Nginx-Plugin erlaubt Certbot, Ihre Server Blocks automatisch fuer TLS anzupassen.

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

Pruefen Sie die Installation:

certbot --version

Auf Debian 12 wird Certbot 2.1.0 installiert. Auf Ubuntu 24.04 erhalten Sie Certbot 2.9.0. Beide Versionen funktionieren fuer alles in dieser Anleitung.

Gut zu wissen: Falls Sie Nginx aus dem offiziellen nginx.org-Repository installiert haben (wie in Nginx auf Debian 12 und Ubuntu 24.04 installieren empfohlen), funktioniert das Certbot-Nginx-Plugin ohne zusaetzliche Konfiguration. Es erkennt Server Blocks in /etc/nginx/conf.d/ und /etc/nginx/sites-enabled/.

Wie beziehen Sie ein Let's Encrypt-Zertifikat fuer Nginx?

Fuehren Sie certbot --nginx mit Ihrem Domainnamen aus. Certbot kontaktiert Let's Encrypt, weist nach, dass Sie die Domain kontrollieren (per HTTP-01 Challenge), bezieht das Zertifikat und bearbeitet Ihren Nginx Server Block fuer die Nutzung. Der gesamte Vorgang dauert etwa 30 Sekunden.

sudo certbot --nginx -d example.com -d www.example.com

Certbot fragt nach Ihrer E-Mail-Adresse (fuer Erneuerungserinnerungen) und der Zustimmung zu den Nutzungsbedingungen. Danach:

  1. Platziert es eine HTTP-01-Challenge-Datei in Ihrem Web Root
  2. Fordert Let's Encrypt zur Verifizierung auf
  3. Laedt das signierte Zertifikat herunter
  4. Passt Ihren Nginx Server Block an und fuegt TLS-Direktiven hinzu
  5. Laedt Nginx neu

Pruefen Sie, ob das Zertifikat ausgestellt wurde:

sudo ls -la /etc/letsencrypt/live/example.com/

Sie sollten folgende Ausgabe sehen:

lrwxrwxrwx 1 root root  ... cert.pem -> ../../archive/example.com/cert1.pem
lrwxrwxrwx 1 root root  ... chain.pem -> ../../archive/example.com/chain1.pem
lrwxrwxrwx 1 root root  ... fullchain.pem -> ../../archive/example.com/fullchain1.pem
lrwxrwxrwx 1 root root  ... privkey.pem -> ../../archive/example.com/privkey1.pem

Das sind Symlinks. fullchain.pem ist Ihr Zertifikat plus die Intermediate-CA-Kette. privkey.pem ist Ihr privater Schluessel.

Pruefen Sie, ob Nginx mit der neuen Konfiguration laeuft:

sudo nginx -t && sudo systemctl status nginx

nginx -t testet die Konfigurationssyntax. Falls test is successful ausgegeben wird, ist die Konfiguration gueltig.

Was aendert Certbot in Ihrer Nginx-Konfiguration?

Certbot fuegt mehrere Zeilen in Ihren Server Block ein. Hier sehen Sie die eingefuegten Zeilen (markiert mit # managed by Certbot):

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

    listen 443 ssl;
    listen [::]:443 ssl;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    # ... your existing location blocks ...
}

Die Datei options-ssl-nginx.conf enthaelt Certbots Standard-TLS-Einstellungen. Wir ersetzen diese im Abschnitt zur Haertung weiter unten durch staerkere Einstellungen.

Certbot erstellt ausserdem einen zweiten Server Block fuer die HTTP-zu-HTTPS-Weiterleitung. Wir verbessern diese Weiterleitung im naechsten Abschnitt.

Sie koennen die genauen Aenderungen anzeigen, indem Sie Ihre Konfiguration vergleichen:

sudo diff /etc/nginx/conf.d/example.com.conf /etc/nginx/conf.d/example.com.conf.bak 2>/dev/null || echo "No backup found. Certbot modifies in place."

Wie leiten Sie HTTP auf HTTPS in Nginx um?

Jeglicher HTTP-Datenverkehr sollte mit einem 301-Redirect (permanent) auf HTTPS umgeleitet werden. Certbot fuegt dies moeglicherweise automatisch hinzu, nutzt dabei aber ein if-Statement innerhalb des bestehenden Server Blocks. Das ist ein Anti-Pattern in Nginx. Ein separater Server Block ist sauberer und zuverlaessiger.

Ersetzen Sie Certbots Weiterleitung durch einen eigenen Server Block. Bearbeiten Sie Ihre Konfigurationsdatei (der Pfad haengt von Ihrem Setup ab; typischerweise /etc/nginx/conf.d/example.com.conf):

# HTTP -> HTTPS redirect (separate server block, not an if-statement)
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Dieser Block gehoert in dieselbe Datei wie Ihr HTTPS-Server-Block oder in eine separate Datei. Stellen Sie sicher, dass Sie den von Certbot generierten Redirect-Block entfernen, um Duplikate zu vermeiden.

Testen und neu laden:

sudo nginx -t
sudo systemctl reload nginx

Pruefen Sie die Weiterleitung von Ihrem lokalen Rechner:

curl -I http://example.com

Erwartete Ausgabe:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

Wie haerten Sie die TLS-Einstellungen fuer einen Produktionsserver?

Certbots Standard-TLS-Konfiguration (options-ssl-nginx.conf) ist bewusst konservativ. Fuer einen Produktionsserver moechten Sie strengere Einstellungen. Wir folgen Mozillas Intermediate-Profil aus dem SSL Configuration Generator, das Sicherheit mit Clientkompatibilitaet bis zurueck zu Firefox 27, Chrome 31 und Android 4.4.2 ausbalanciert.

Erstellen Sie eine Snippet-Datei, die Sie per include in jeden Server Block einbinden koennen:

sudo nano /etc/nginx/snippets/tls-params.conf

Fuegen Sie folgenden Inhalt ein:

# TLS protocol versions — TLS 1.2 and 1.3 only
# TLS 1.0 and 1.1 are deprecated (RFC 8996)
ssl_protocols TLSv1.2 TLSv1.3;

# Ciphers — Mozilla Intermediate profile (January 2026)
# Source: https://ssl-config.mozilla.org/
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:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

# DH parameters — 2048-bit, RFC 7919 ffdhe2048
ssl_dhparam /etc/nginx/dhparam.pem;

# Session settings
ssl_session_timeout 1d;
ssl_session_cache shared:TLS:10m;
ssl_session_tickets off;

# HSTS — tell browsers to always use HTTPS (2 years)
# Only add includeSubDomains if ALL subdomains use HTTPS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

# Hide Nginx version in error pages and headers
server_tokens off;

Generieren Sie die DH-Parameter-Datei (dies dauert einige Sekunden):

sudo openssl dhparam -out /etc/nginx/dhparam.pem 2048

Pruefen Sie, ob die Datei erstellt wurde:

sudo ls -la /etc/nginx/dhparam.pem

Aktualisieren Sie nun Ihren HTTPS-Server-Block mit diesen Einstellungen anstelle von Certbots Standards. Entfernen Sie die Zeile include /etc/letsencrypt/options-ssl-nginx.conf; und die Zeile ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;. Ersetzen Sie sie durch:

server {
    listen 443 ssl;
    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;

    # TLS hardening (replaces Certbot defaults)
    include snippets/tls-params.conf;

    # ... your location blocks ...
}

Testen und neu laden:

sudo nginx -t
sudo systemctl reload nginx

Welche TLS-Versionen und Cipher sollten Sie verwenden?

Mozilla veroeffentlicht drei TLS-Profile. Hier der Vergleich:

Profil Protokolle Aeltester kompatibler Client Einsatzzweck
Modern Nur TLS 1.3 Firefox 63, Chrome 70, Android 10 Dienste, bei denen alle Clients aktuell sind
Intermediate TLS 1.2 + 1.3 Firefox 27, Chrome 31, Android 4.4 Allgemeine Webserver
Old TLS 1.0 + 1.1 + 1.2 + 1.3 Firefox 1, Chrome 1, IE 8 Nur fuer Altsysteme

Verwenden Sie Intermediate, sofern Sie keinen bestimmten Grund dagegen haben. Es deckt 99,9 %+ der aktuellen Browser ab und schliesst schwache Protokolle aus. TLS 1.0 und 1.1 wurden durch RFC 8996 im Maerz 2021 offiziell als veraltet erklaert.

Die Cipher-Liste in unserem Snippet verwendet ausschliesslich AEAD-Cipher (GCM und ChaCha20-Poly1305). ssl_prefer_server_ciphers off laesst den Client seinen bevorzugten Cipher waehlen. Das ist die Empfehlung von Mozilla, da moderne Clients bessere Entscheidungen treffen als eine statische Serverpraeferenz.

Unterstuetzt Let's Encrypt noch OCSP Stapling?

Nein. Let's Encrypt hat seinen OCSP-Dienst am 6. August 2025 abgeschaltet. Zertifikate, die nach Mai 2025 ausgestellt wurden, enthalten keine OCSP-Responder-URL. Der Sperrstatus (Revocation Status) wird nun ausschliesslich ueber Certificate Revocation Lists (CRLs) veroeffentlicht. Falls Sie nur Let's Encrypt-Zertifikate verwenden, entfernen Sie alle ssl_stapling-Direktiven aus Ihrer Nginx-Konfiguration.

Hier der zeitliche Ablauf:

  1. Dezember 2024. Let's Encrypt kuendigte das Ende von OCSP an.
  2. 30. Januar 2025. Zertifikate mit der OCSP-Must-Staple-Erweiterung begannen fehlzuschlagen.
  3. 7. Mai 2025. Neue Zertifikate enthielten keine OCSP-Responder-URLs mehr. Stattdessen wurden CRL-URLs hinzugefuegt.
  4. 6. August 2025. Der OCSP-Dienst wurde vollstaendig abgeschaltet. Alle zuvor ausgestellten Zertifikate mit OCSP-URLs sind inzwischen abgelaufen.

Falls Sie ssl_stapling on; oder ssl_stapling_verify on; in einer Anleitung oder einem Config-Snippet sehen, ist das fuer Let's Encrypt-Nutzer veralteter Rat. Diese Direktiven sind harmlos (Nginx ignoriert sie stillschweigend, wenn keine OCSP-Responder-URL vorhanden ist), aber sie erzeugen unnoetige Unordnung. Entfernen Sie sie.

Falls Sie Zertifikate einer anderen CA verwenden, die noch OCSP anbietet, bleiben diese Direktiven fuer jene Zertifikate gueltig.

Warum hat Let's Encrypt OCSP abgeschafft? Zwei Gruende. OCSP ist ein Datenschutzrisiko: Jedes Mal, wenn ein Browser den Sperrstatus eines Zertifikats per OCSP prueft, erfuhr die CA, welche Website von welcher IP besucht wurde. Auf dem Hoehepunkt verarbeitete Let's Encrypts OCSP-Dienst 340 Milliarden Anfragen pro Monat. Der Wechsel zu CRLs beseitigt dieses Datenschutzleck. CRLs werden von Browsern in grossen Bloecken heruntergeladen, sodass keine einzelne Anfrage pro Besuch an die CA geht.

Wie aktivieren Sie HTTP/2 mit Nginx?

HTTP/2 multiplext Anfragen ueber eine einzige Verbindung und reduziert die Latenz. Falls Sie Nginx aus dem offiziellen nginx.org-Repository installiert haben (Version 1.25.1 oder hoeher), aktivieren Sie HTTP/2 mit der http2-Direktive in Ihrem Server Block.

Fuegen Sie http2 on; in Ihren HTTPS-Server-Block ein:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    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;
    include snippets/tls-params.conf;

    # ... your location blocks ...
}

Die Direktive http2 on; hat die veraltete Syntax listen 443 ssl http2; ab Nginx 1.25.1 ersetzt. Die alte Syntax funktioniert noch, erzeugt aber Deprecation-Warnungen im Error Log. Falls Sie das Distributions-Paket von Nginx verwenden (1.22 auf Debian 12, 1.24 auf Ubuntu 24.04), nutzen Sie stattdessen die alte Syntax listen 443 ssl http2;.

Testen und neu laden:

sudo nginx -t
sudo systemctl reload nginx

Pruefen Sie, ob HTTP/2 aktiv ist:

curl -I --http2 -s https://example.com | head -1

Erwartete Ausgabe:

HTTP/2 200

Falls Sie stattdessen HTTP/1.1 sehen, pruefen Sie, ob http2 on; im richtigen Server Block steht und ob Ihre Nginx-Version es unterstuetzt.

Wie funktioniert die automatische Zertifikatserneuerung?

Let's Encrypt-Zertifikate laufen nach 90 Tagen ab. Certbot installiert einen systemd-Timer (certbot.timer), der zweimal taeglich prueft, ob ein Zertifikat innerhalb von 30 Tagen ablaeuft. Falls ja, wird es automatisch erneuert. Sie muessen keinen Cron-Job einrichten.

Pruefen Sie, ob der Timer aktiv ist:

systemctl status certbot.timer

Sie sollten Active: active (waiting) und eine Zeile mit dem naechsten Ausfuehrungszeitpunkt sehen.

Pruefen Sie, wann die naechste Erneuerung stattfindet:

systemctl list-timers certbot.timer

Dies zeigt die Zeiten fuer NEXT und LAST an.

Erneuerung testen ohne tatsaechlich zu erneuern

Fuehren Sie einen Dry-Run aus, um zu pruefen, ob der Erneuerungsprozess durchgaengig funktioniert:

sudo certbot renew --dry-run

Dieser Befehl kontaktiert den Staging-Server von Let's Encrypt und simuliert eine vollstaendige Erneuerung. Falls Congratulations, all simulated renewals succeeded ausgegeben wird, ist Ihr Setup korrekt.

Deploy-Hook einrichten, um Nginx neu zu laden

Wenn Certbot ein Zertifikat erneuert, muss Nginx neu geladen werden, um die neuen Dateien zu uebernehmen. Richten Sie einen Deploy-Hook ein, der nur bei erfolgreicher Erneuerung ausgefuehrt wird:

sudo mkdir -p /etc/letsencrypt/renewal-hooks/deploy

sudo nano /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Fuegen Sie ein:

#!/bin/bash
/usr/bin/systemctl reload nginx

Machen Sie das Skript ausfuehrbar:

sudo chmod 700 /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Pruefen Sie die Berechtigungen:

ls -la /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Die erwartete Ausgabe zeigt -rwx------ (nur root kann lesen und ausfuehren).

Das Verzeichnis deploy fuehrt Skripte nur nach einer erfolgreichen Erneuerung aus, nicht bei jedem Timer-Durchlauf. Das vermeidet unnoetige Neustarts.

Wie ueberpruefen Sie, ob Ihr TLS-Setup korrekt ist?

Nach Abschluss aller obigen Schritte fuehren Sie diese Pruefbefehle aus. Jeder prueft einen anderen Aspekt Ihres Setups.

Zertifikatskette mit OpenSSL pruefen

Von Ihrem lokalen Rechner:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Erwartete Ausgabe:

notBefore=Mar 19 00:00:00 2026 GMT
notAfter=Jun 17 00:00:00 2026 GMT
subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R12

Gut zu wissen: Das notAfter-Datum sollte etwa 90 Tage nach der Ausstellung liegen. Der Issuer sollte Let's Encrypt sein. Aktuelle RSA-Zwischenzertifikate (Intermediates) sind R12 und R13. Fuer ECDSA-Zertifikate suchen Sie nach E7 oder E8.

TLS-Version und verwendeten Cipher pruefen

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep -E "Protocol|Cipher"

Erwartete Ausgabe:

    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

Falls Sie TLSv1.2 sehen, ist das ebenfalls in Ordnung. Es haengt davon ab, welche Version Ihr lokales OpenSSL bevorzugt.

HTTPS-Header pruefen

curl -I https://example.com

Achten Sie auf:

HTTP/2 200
strict-transport-security: max-age=63072000; includeSubDomains

Falls strict-transport-security fehlt, pruefen Sie die add_header-Zeile in Ihrem TLS-Snippet. Der Parameter always stellt sicher, dass der Header auch bei Fehlerantworten gesendet wird.

Zusammenfassung der Pruefbefehle

Befehl Was wird geprueft Worauf Sie achten sollten
dig +short example.com DNS-Aufloesung IP Ihres Servers
curl -I http://example.com HTTP-Weiterleitung 301 mit Location: https://
curl -I https://example.com HTTPS + Header HTTP/2 200, HSTS-Header
openssl s_client -connect ... Zertifikatskette, TLS-Version Let's Encrypt Issuer, TLSv1.2 oder 1.3
certbot renew --dry-run Erneuerungsprozess all simulated renewals succeeded
systemctl status certbot.timer Timer fuer automatische Erneuerung active (waiting)

Test mit SSL Labs

Fuer eine gruendliche externe Pruefung reichen Sie Ihre Domain beim SSL Labs Server Test ein. Mit der Konfiguration aus dieser Anleitung sollten Sie eine Bewertung von A oder A+ erhalten. Fuer A+ ist HSTS erforderlich, das wir im TLS-Snippet aktiviert haben.

Vollstaendige Nginx-Konfigurationsreferenz

Hier der komplette Server Block mit allen Einstellungen aus dieser Anleitung zusammengefasst:

# HTTP -> HTTPS redirect
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# HTTPS server block
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name example.com www.example.com;

    # Let's Encrypt certificate
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # TLS hardening
    include snippets/tls-params.conf;

    root /var/www/example.com/html;
    index index.html;

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

    # Deny access to hidden files
    location ~ /\. {
        deny all;
    }
}

Und das TLS-Snippet unter /etc/nginx/snippets/tls-params.conf:

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:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_dhparam /etc/nginx/dhparam.pem;

ssl_session_timeout 1d;
ssl_session_cache shared:TLS:10m;
ssl_session_tickets off;

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

Fuer zusaetzliche Sicherheitsheader wie Content-Security-Policy, X-Frame-Options und Permissions-Policy, siehe Nginx-Sicherheitshaertung.

Etwas funktioniert nicht?

Certbot meldet "Could not automatically find a matching server block" Certbot sucht eine server_name-Direktive, die zu Ihrer -d-Domain passt. Stellen Sie sicher, dass Ihre Server-Block-Datei in /etc/nginx/conf.d/ oder /etc/nginx/sites-enabled/ liegt und server_name example.com; enthaelt.

Certbot meldet "Connection refused" oder "Challenge failed" Port 80 muss offen sein. Pruefen Sie Ihre Firewall:

sudo ufw status          # if using UFW
sudo nft list ruleset    # if using nftables

Pruefen Sie ausserdem, ob Nginx auf Port 80 lauscht:

sudo ss -tlnp | grep ':80'

"SSL: error" im Nginx-Error-Log nach Aenderung der TLS-Einstellungen Vermutlich liegt ein Syntaxfehler in der Cipher-Zeichenkette oder ein fehlender Dateipfad vor. Pruefen Sie:

sudo nginx -t
sudo journalctl -u nginx -n 20 --no-pager

Browser zeigt "NET::ERR_CERT_DATE_INVALID" Das Zertifikat ist moeglicherweise abgelaufen. Pruefen Sie das Ablaufdatum:

sudo certbot certificates

Falls es abgelaufen ist, erzwingen Sie eine Erneuerung:

sudo certbot renew --force-renewal

certbot renew --dry-run schlaegt fehl Haeufige Ursache: Der DNS-Eintrag der Domain zeigt nicht mehr auf diesen Server, oder Port 80 ist blockiert. Certbot benoetigt HTTP-01-Zugriff fuer die Erneuerung.

HTTP/2 funktioniert nicht Pruefen Sie Ihre Nginx-Version: nginx -v. Falls sie unter 1.25.1 liegt, verwenden Sie listen 443 ssl http2; anstelle der separaten Direktive http2 on;. Falls sie 1.25.1 oder hoeher ist, stellen Sie sicher, dass http2 on; im richtigen server-Block steht (nicht in http oder location).

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfaeltigung, Wiederveroeffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.

Bereit, es selbst auszuprobieren?

Stellen Sie Ihren eigenen Server in Sekunden bereit. Linux, Windows oder FreeBSD.

VPS-Angebote ansehen

Verwandte Artikel