Let's Encrypt SSL/TLS für Nginx einrichten auf Debian 12 und Ubuntu 24.04
Kostenlose TLS-Zertifikate mit Certbot für Nginx auf Debian 12 oder Ubuntu 24.04 beziehen und automatisch erneuern. DNS-Konfiguration, Certbot-Installation, HTTP-zu-HTTPS-Weiterleitung, TLS-Härtung, HTTP/2, HSTS und die OCSP-Abschaltung.
Diese Anleitung führt Sie durch den Bezug eines kostenlosen TLS-Zertifikats von Let's Encrypt mit Certbot, die Konfiguration von Nginx für HTTPS und die Einrichtung der automatischen Erneuerung. Jeder Schritt enthält einen Prüfbefehl, damit Sie das Ergebnis verifizieren können, bevor Sie weitergehen.
Falls Sie Nginx noch nicht installiert haben, beginnen Sie mit Nginx auf Debian 12 und Ubuntu 24.04 aus dem offiziellen Repository installieren. Einen Gesamtüberblick über die Nginx-Verwaltung auf einem VPS finden Sie unter Nginx-Administration auf einem VPS.
Was benötigen 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 für diese Domain laufen. Let's Encrypt validiert die Domain-Inhaberschaft durch einen HTTP-Request an Ihren Server. Falls DNS nicht auf Ihren VPS auflöst oder Nginx nicht lauscht, schlägt die Challenge fehl.
Sie benötigen:
- Einen VPS mit Debian 12 oder Ubuntu 24.04 und Nginx aus dem offiziellen Repository (Nginx auf Debian 12 und Ubuntu 24.04 aus dem offiziellen Repository installieren)
- Einen registrierten Domainnamen (wir verwenden durchgehend
example.com) - Einen A-Record, der
example.comauf 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 für Ihre Domain (Nginx Server Blocks: Mehrere Domains auf einem VPS betreiben)
DNS-Einträge 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 tatsächlichen Adressen Ihres Servers. Setzen Sie die TTL während der Einrichtung niedrig (300 Sekunden), damit Änderungen schnell propagieren. Später können Sie den Wert erhöhen.
DNS-Auflösung prüfen
Warten Sie einige Minuten nach dem Anlegen der Einträge und prüfen 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.
Prüfen 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, prüfen 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 für TLS anzupassen.
sudo apt update
sudo apt install certbot python3-certbot-nginx -y
Prüfen 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 für 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 aus dem offiziellen Repository installieren empfohlen), funktioniert das Certbot-Nginx-Plugin ohne zusätzliche Konfiguration. Es erkennt Server Blocks in /etc/nginx/conf.d/ und /etc/nginx/sites-enabled/.
Wie beziehen Sie ein Let's Encrypt-Zertifikat für Nginx?
Führen 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 für 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 (für Erneuerungserinnerungen) und der Zustimmung zu den Nutzungsbedingungen. Danach:
- Platziert es eine HTTP-01-Challenge-Datei in Ihrem Web Root
- Fordert Let's Encrypt zur Verifizierung auf
- Lädt das signierte Zertifikat herunter
- Passt Ihren Nginx Server Block an und fügt TLS-Direktiven hinzu
- Lädt Nginx neu
Prüfen 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 Schlüssel.
Prüfen Sie, ob Nginx mit der neuen Konfiguration läuft:
sudo nginx -t && sudo systemctl status nginx
nginx -t testet die Konfigurationssyntax. Falls test is successful ausgegeben wird, ist die Konfiguration gültig.
Was ändert Certbot in Ihrer Nginx-Konfiguration?
Certbot fügt mehrere Zeilen in Ihren Server Block ein. Hier sehen Sie die eingefügten 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 enthält Certbots Standard-TLS-Einstellungen. Wir ersetzen diese im Abschnitt zur Härtung weiter unten durch stärkere Einstellungen.
Certbot erstellt außerdem einen zweiten Server Block für die HTTP-zu-HTTPS-Weiterleitung. Wir verbessern diese Weiterleitung im nächsten Abschnitt.
Sie können die genauen Änderungen 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 fügt dies möglicherweise 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 zuverlässiger.
Ersetzen Sie Certbots Weiterleitung durch einen eigenen Server Block. Bearbeiten Sie Ihre Konfigurationsdatei (der Pfad hängt 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 gehört 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
Prüfen 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 härten Sie die TLS-Einstellungen für einen Produktionsserver?
Certbots Standard-TLS-Konfiguration (options-ssl-nginx.conf) ist bewusst konservativ. Für einen Produktionsserver möchten Sie strengere Einstellungen. Wir folgen Mozillas Intermediate-Profil aus dem SSL Configuration Generator, das Sicherheit mit Clientkompatibilität bis zurück 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 können:
sudo nano /etc/nginx/snippets/tls-params.conf
Fügen 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
Prüfen 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 veröffentlicht drei TLS-Profile. Hier der Vergleich:
| Profil | Protokolle | Ältester 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 für Altsysteme |
Verwenden Sie Intermediate, sofern Sie keinen bestimmten Grund dagegen haben. Es deckt 99,9 %+ der aktuellen Browser ab und schließt schwache Protokolle aus. TLS 1.0 und 1.1 wurden durch RFC 8996 im März 2021 offiziell als veraltet erklärt.
Die Cipher-Liste in unserem Snippet verwendet ausschließlich AEAD-Cipher (GCM und ChaCha20-Poly1305). ssl_prefer_server_ciphers off lässt den Client seinen bevorzugten Cipher wählen. Das ist die Empfehlung von Mozilla, da moderne Clients bessere Entscheidungen treffen als eine statische Serverpräferenz.
Unterstützt 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 ausschließlich über Certificate Revocation Lists (CRLs) veröffentlicht. Falls Sie nur Let's Encrypt-Zertifikate verwenden, entfernen Sie alle ssl_stapling-Direktiven aus Ihrer Nginx-Konfiguration.
Hier der zeitliche Ablauf:
- Dezember 2024. Let's Encrypt kündigte das Ende von OCSP an.
- 30. Januar 2025. Zertifikate mit der OCSP-Must-Staple-Erweiterung begannen fehlzuschlagen.
- 7. Mai 2025. Neue Zertifikate enthielten keine OCSP-Responder-URLs mehr. Stattdessen wurden CRL-URLs hinzugefügt.
- 6. August 2025. Der OCSP-Dienst wurde vollständig 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 für Let's Encrypt-Nutzer veralteter Rat. Diese Direktiven sind harmlos (Nginx ignoriert sie stillschweigend, wenn keine OCSP-Responder-URL vorhanden ist), aber sie erzeugen unnötige Unordnung. Entfernen Sie sie.
Falls Sie Zertifikate einer anderen CA verwenden, die noch OCSP anbietet, bleiben diese Direktiven für jene Zertifikate gültig.
Warum hat Let's Encrypt OCSP abgeschafft? Zwei Gründe. OCSP ist ein Datenschutzrisiko: Jedes Mal, wenn ein Browser den Sperrstatus eines Zertifikats per OCSP prüft, erfuhr die CA, welche Website von welcher IP besucht wurde. Auf dem Höhepunkt verarbeitete Let's Encrypts OCSP-Dienst 340 Milliarden Anfragen pro Monat. Der Wechsel zu CRLs beseitigt dieses Datenschutzleck. CRLs werden von Browsern in großen Blöcken heruntergeladen, sodass keine einzelne Anfrage pro Besuch an die CA geht.
Wie aktivieren Sie HTTP/2 mit Nginx?
HTTP/2 multiplext Anfragen über eine einzige Verbindung und reduziert die Latenz. Falls Sie Nginx aus dem offiziellen nginx.org-Repository installiert haben (Version 1.25.1 oder höher), aktivieren Sie HTTP/2 mit der http2-Direktive in Ihrem Server Block.
Fügen 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
Prüfen 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, prüfen Sie, ob http2 on; im richtigen Server Block steht und ob Ihre Nginx-Version es unterstützt.
Wie funktioniert die automatische Zertifikatserneuerung?
Let's Encrypt-Zertifikate laufen nach 90 Tagen ab. Certbot installiert einen systemd-Timer (certbot.timer), der zweimal täglich prüft, ob ein Zertifikat innerhalb von 30 Tagen abläuft. Falls ja, wird es automatisch erneuert. Sie müssen keinen Cron-Job einrichten.
Prüfen Sie, ob der Timer aktiv ist:
systemctl status certbot.timer
Sie sollten Active: active (waiting) und eine Zeile mit dem nächsten Ausführungszeitpunkt sehen.
Prüfen Sie, wann die nächste Erneuerung stattfindet:
systemctl list-timers certbot.timer
Dies zeigt die Zeiten für NEXT und LAST an.
Erneuerung testen ohne tatsächlich zu erneuern
Führen Sie einen Dry-Run aus, um zu prüfen, ob der Erneuerungsprozess durchgängig funktioniert:
sudo certbot renew --dry-run
Dieser Befehl kontaktiert den Staging-Server von Let's Encrypt und simuliert eine vollständige 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 übernehmen. Richten Sie einen Deploy-Hook ein, der nur bei erfolgreicher Erneuerung ausgeführt wird:
sudo mkdir -p /etc/letsencrypt/renewal-hooks/deploy
sudo nano /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
Fügen Sie ein:
#!/bin/bash
/usr/bin/systemctl reload nginx
Machen Sie das Skript ausführbar:
sudo chmod 700 /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
Prüfen Sie die Berechtigungen:
ls -la /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
Die erwartete Ausgabe zeigt -rwx------ (nur root kann lesen und ausführen).
Das Verzeichnis deploy führt Skripte nur nach einer erfolgreichen Erneuerung aus, nicht bei jedem Timer-Durchlauf. Das vermeidet unnötige Neustarts.
Wie überprüfen Sie, ob Ihr TLS-Setup korrekt ist?
Nach Abschluss aller obigen Schritte führen Sie diese Prüfbefehle aus. Jeder prüft einen anderen Aspekt Ihres Setups.
Zertifikatskette mit OpenSSL prüfen
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. Für ECDSA-Zertifikate suchen Sie nach E7 oder E8.
TLS-Version und verwendeten Cipher prüfen
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 hängt davon ab, welche Version Ihr lokales OpenSSL bevorzugt.
HTTPS-Header prüfen
curl -I https://example.com
Achten Sie auf:
HTTP/2 200
strict-transport-security: max-age=63072000; includeSubDomains
Falls strict-transport-security fehlt, prüfen Sie die add_header-Zeile in Ihrem TLS-Snippet. Der Parameter always stellt sicher, dass der Header auch bei Fehlerantworten gesendet wird.
Zusammenfassung der Prüfbefehle
| Befehl | Was wird geprüft | Worauf Sie achten sollten |
|---|---|---|
dig +short example.com |
DNS-Auflösung | 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 für automatische Erneuerung | active (waiting) |
Test mit SSL Labs
Für eine gründliche externe Prüfung 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. Für A+ ist HSTS erforderlich, das wir im TLS-Snippet aktiviert haben.
Vollständige 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;
Für zusätzliche Sicherheitsheader wie Content-Security-Policy, X-Frame-Options und Permissions-Policy, siehe Nginx-Sicherheitshärtung unter Ubuntu und Debian.
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; enthält.
Certbot meldet "Connection refused" oder "Challenge failed" Port 80 muss offen sein. Prüfen Sie Ihre Firewall:
sudo ufw status # if using UFW
sudo nft list ruleset # if using nftables
Prüfen Sie außerdem, ob Nginx auf Port 80 lauscht:
sudo ss -tlnp | grep ':80'
"SSL: error" im Nginx-Error-Log nach Änderung der TLS-Einstellungen Vermutlich liegt ein Syntaxfehler in der Cipher-Zeichenkette oder ein fehlender Dateipfad vor. Prüfen Sie:
sudo nginx -t
sudo journalctl -u nginx -n 20 --no-pager
Browser zeigt "NET::ERR_CERT_DATE_INVALID" Das Zertifikat ist möglicherweise abgelaufen. Prüfen Sie das Ablaufdatum:
sudo certbot certificates
Falls es abgelaufen ist, erzwingen Sie eine Erneuerung:
sudo certbot renew --force-renewal
certbot renew --dry-run schlägt fehl
Häufige Ursache: Der DNS-Eintrag der Domain zeigt nicht mehr auf diesen Server, oder Port 80 ist blockiert. Certbot benötigt HTTP-01-Zugriff für die Erneuerung.
HTTP/2 funktioniert nicht
Prüfen 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 höher ist, stellen Sie sicher, dass http2 on; im richtigen server-Block steht (nicht in http oder location).
Bereit, es selbst auszuprobieren?
Hosten Sie Ihre Webanwendungen auf einem zuverlassigen VPS. →