HTTPS in Nginx: SSL-Zertifikat einrichten

• Server und Infrastruktur
• Aktualisiert: 04.10.2026
• Ca. 9 Min. Lesezeit

HTTPS in sieben Schritten

1. 1

   Voraussetzungen prüfen

   Bevor Let's Encrypt ein Zertifikat ausstellt, prüft es, ob die Domain wirklich unter Ihrer Kontrolle steht. Beim gängigsten Verfahren verbindet sich der Validierungsserver über Port 80 mit Ihrer Domain und fordert eine temporäre Datei an. Deshalb gilt:

   • Der DNS-Eintrag der Domain (und des www-Namens, falls Sie ihn nutzen) muss auf diesen Server zeigen.
   • Die Ports 80 und 443 müssen in der Firewall geöffnet sein.
   • In Nginx muss für diese Domain ein server-Block mit korrekter server_name-Zeile vorhanden sein.

   Wo die Site-Dateien liegen, hängt von der Distribution ab: /etc/nginx/conf.d ist verbreitet, /etc/nginx/sites-available ist das Layout von Debian/Ubuntu.

   : Vergrößern

2. 2

   Zertifikat mit Certbot beziehen

   Der Installationsbefehl für Certbot hängt von Distribution und Paketverwaltung ab; die erste Zeile unten ist nur ein Beispiel. Nach der Installation bezieht die Option --nginx das Zertifikat und trägt die nötigen Zeilen selbst in den passenden server-Block ein. Jedes -d steht für einen Domainnamen.

   Bash

   # Die Installation hängt von der Distribution ab. Beispiel (Paketquellen von Debian/Ubuntu):
   sudo apt install certbot python3-certbot-nginx
   
   # Zertifikat beziehen und in die Nginx-Konfiguration eintragen
   sudo certbot --nginx -d beispiel.de -d www.beispiel.de

   Certbot legt die Dateien unter /etc/letsencrypt/live/beispiel.de/ ab. Für Nginx sind zwei davon wichtig:

   • fullchain.pem: das Zertifikat Ihrer Website zusammen mit dem Zwischenzertifikat. ssl_certificate verweist auf diese Datei.
   • privkey.pem: der private Schlüssel. ssl_certificate_key verweist auf diese Datei. Er wird mit niemandem geteilt und nicht unterhalb des Webroots abgelegt.

   : Vergrößern

3. 3

   HTTPS-Serverblock und Weiterleitung schreiben

   Hat Certbot die Konfiguration selbst angepasst, sehen Sie sich in diesem Schritt nur das Ergebnis an. Schreiben Sie sie von Hand, brauchen Sie zwei Blöcke: Einer lauscht auf Port 80 und leitet jede Anfrage dauerhaft (301) auf HTTPS weiter, der andere antwortet auf Port 443 mit dem Zertifikat.

   Nginx

   # 80: jede Anfrage auf HTTPS weiterleiten
   server {
       listen 80;
       listen [::]:80;
       server_name beispiel.de www.beispiel.de;
   
       return 301 https://$host$request_uri;
   }
   
   # 443: mit dem Zertifikat antworten
   server {
       listen 443 ssl;
       listen [::]:443 ssl;
       server_name beispiel.de www.beispiel.de;
   
       ssl_certificate     /etc/letsencrypt/live/beispiel.de/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/beispiel.de/privkey.pem;
   
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_session_cache shared:SSL:10m;
       ssl_session_timeout 1h;
   
       root /var/www/beispiel.de/public;
       index index.html;
   }

   Die Zeile return 301 https://$host$request_uri; leitet weiter und behält dabei die angeforderte Adresse samt Query-String bei. ssl_protocols TLSv1.2 TLSv1.3; schaltet alte, unsichere Protokollversionen ab. Die Schreibweise der Direktive, die HTTP/2 aktiviert, hängt von der Nginx-Version ab; sehen Sie in der Dokumentation Ihrer Version nach.

4. 4

   Testen und neu laden

   Prüfen Sie zuerst die Syntax; wenn kein Fehler gemeldet wird, laden Sie Nginx neu. Ein Neuladen (Reload) trennt keine offenen Verbindungen. Kontrollieren Sie anschließend Weiterleitung und Zertifikat von außen.

   Bash

   # Syntax prüfen, dann neu laden
   sudo nginx -t
   sudo systemctl reload nginx
   
   # Leitet die HTTP-Adresse auf HTTPS weiter?
   curl -sI http://beispiel.de/ | grep -i -E "^(HTTP|location)"
   
   # HTTPS-Antwort und Header
   curl -sI https://beispiel.de/
   
   # Ausgelieferte Zertifikatskette anzeigen
   openssl s_client -connect beispiel.de:443 -servername beispiel.de < /dev/null

   In der ersten curl-Ausgabe sollten 301 und eine location-Zeile stehen, die mit https:// beginnt. Prüfen Sie im Browser über die Verbindungsinformationen in der Adressleiste den Domainnamen und das Ablaufdatum des Zertifikats. Bei Problemen hilft der Abschnitt „Häufige Fehler“ weiter unten.

   : Vergrößern

5. 5

   Bei Weitergabe an ein Backend: SSL-Terminierung

   In den meisten Installationen arbeitet Nginx als Reverse Proxy: Es nimmt die Anfrage entgegen und gibt sie an die Anwendung dahinter weiter. Dabei wird die verschlüsselte Verbindung an Nginx geöffnet; das nennt man SSL-Terminierung (auch TLS-Terminierung). Das Zertifikat liegt an einer Stelle, und der Backend-Server muss sich nicht um die Verschlüsselung kümmern.

   Nginx

   upstream app_backend {
       server 127.0.0.1:8080;
   }
   
   server {
       listen 443 ssl;
       server_name beispiel.de www.beispiel.de;
   
       ssl_certificate     /etc/letsencrypt/live/beispiel.de/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/beispiel.de/privkey.pem;
   
       location / {
           # Hier wurde entschlüsselt; zum Backend geht unverschlüsseltes HTTP
           proxy_pass http://app_backend;
   
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           # Das vom Besucher verwendete Protokoll: https
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

   Für die Verbindung zwischen Nginx und dem Backend gibt es zwei Möglichkeiten:

   • Unverschlüsseltes HTTP: die übliche Wahl, wenn das Backend auf demselben Server läuft (127.0.0.1) oder in einem vertrauenswürdigen, abgeschlossenen internen Netz steht.
   • Erneute Verschlüsselung: Läuft der Datenverkehr durch ein Netz, dem Sie nicht vertrauen, verwenden Sie proxy_pass https://…. Standardmäßig prüft Nginx das Zertifikat des Backends nicht; für die Prüfung sind proxy_ssl_verify on; und proxy_ssl_trusted_certificate nötig.

   Da das Backend die Anfrage als HTTP sieht, kann es nicht erkennen, dass der Besucher über HTTPS gekommen ist. Der Header X-Forwarded-Proto transportiert diese Information; die Anwendung wertet ihn aus, um sichere Cookies zu setzen und korrekte Adressen zu erzeugen. Die Anwendung sollte diesem Header nur vertrauen, wenn er von Ihrem eigenen Proxy stammt. Mehr dazu: Reverse Proxy mit Nginx einrichten.

   : Vergrößern

6. 6

   HSTS zuerst mit kurzer Dauer aktivieren

   Der HSTS-Header (Strict-Transport-Security) teilt dem Browser mit: „Verbinde dich für die angegebene Dauer nur per HTTPS mit dieser Website.“ Das ist ein starker Schutz, lässt sich aber schwer zurücknehmen: Der Browser kehrt erst nach Ablauf der Dauer zu HTTP zurück. Testen Sie deshalb zuerst mit einem max-age von wenigen Minuten.

   Nginx

   # Test: 5 Minuten
   add_header Strict-Transport-Security "max-age=300" always;
   
   # Wenn alles funktioniert, statt der Zeile oben: 1 Jahr
   # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

   Definieren Sie den Header nur im Block für Port 443. Das Wort always sorgt dafür, dass der Header auch bei Fehlerantworten gesendet wird. Bevor Sie includeSubDomains ergänzen, stellen Sie sicher, dass alle Ihre Subdomains per HTTPS funktionieren. Zu den übrigen Headern siehe die Anleitung Sicherheitsheader und HTTPS.

7. 7

   Automatische Erneuerung überprüfen

   Zertifikate von Let's Encrypt sind kurzlebig; sie werden nicht von Hand verfolgt, sondern automatisch erneuert. Certbot-Pakete richten in der Regel einen Zeitplaner ein (systemd-Timer oder Cron); er läuft regelmäßig und erneuert nur Zertifikate, deren Ablauf näher rückt. Überzeugen Sie sich mit einer Probe-Erneuerung, dass die Einrichtung wirklich funktioniert.

   Bash

   # Probe-Erneuerung: Das echte Zertifikat bleibt unberührt
   sudo certbot renew --dry-run
   
   # Zertifikate und Ablaufdaten
   sudo certbot certificates
   
   # Ist der Timer eingerichtet? (auf Distributionen mit systemd)
   systemctl list-timers | grep -i certbot
   
   # Nginx nach einer Erneuerung neu laden
   sudo certbot renew --deploy-hook "systemctl reload nginx"

   Nginx liest die Zertifikatsdatei nur beim Start und beim Neuladen. Ohne Neuladen nach der Erneuerung wird Besuchern weiterhin das alte Zertifikat ausgeliefert, obwohl die Datei erneuert wurde. Der mit --deploy-hook angegebene Befehl läuft nur, wenn tatsächlich ein Zertifikat erneuert wurde. Damit er dauerhaft gilt, können Sie denselben Befehl auch als ausführbares Skript im Verzeichnis /etc/letsencrypt/renewal-hooks/deploy/ ablegen; Certbot führt die Skripte in diesem Verzeichnis nach jeder erfolgreichen Erneuerung aus.

   : Vergrößern

Wenn Certbot die Konfiguration nicht anfassen soll: das Webroot-Verfahren

Wenn Sie die Nginx-Konfiguration vollständig selbst verwalten möchten, können Sie Certbot ausschließlich das Zertifikat beziehen lassen. Bei diesem Verfahren wird die Validierungsdatei in ein von Ihnen festgelegtes Verzeichnis geschrieben; im Block für Port 80 wird dieser Pfad von der Weiterleitung ausgenommen.

listen 80;
listen [::]:80;
server_name beispiel.de www.beispiel.de;

# Validierungsdateien werden nicht weitergeleitet
location /.well-known/acme-challenge/ {
    root /var/www/letsencrypt;
}

location / {
    return 301 https://$host$request_uri;
}

# Nur das Zertifikat beziehen; die Nginx-Konfiguration bleibt unverändert
sudo certbot certonly --webroot -w /var/www/letsencrypt -d beispiel.de -d www.beispiel.de

Wildcard-Zertifikate lassen sich so nicht beziehen; sie erfordern eine Validierung über einen DNS-Eintrag, und die Schritte hängen von Ihrem DNS-Anbieter ab.

TLS-Einstellungen: was hineingehört und was nicht

• Protokoll: ssl_protocols TLSv1.2 TLSv1.3; genügt für aktuelle Browser. Für TLS 1.3 muss die OpenSSL-Bibliothek, mit der Nginx gebaut wurde, diese Version unterstützen.
• An einer Stelle definieren: Laufen mehrere Websites auf dem Server, verhindert es Abweichungen zwischen den Websites, die Protokolleinstellung einmal im http-Block zu schreiben.
• Sitzungscache: ssl_session_cache shared:SSL:10m; verringert wiederholte Handshakes bei wiederkehrenden Besuchern.
• Cipher-Suites: Kopieren Sie keine alten Listen, die im Internet kursieren. Empfehlungen ändern sich mit der Zeit; aktuelle Empfehlungen finden Sie in der Dokumentation Ihrer Serversoftware. Im Zweifel ist die Voreinstellung besser als eine veraltete, eingefügte Liste.

Häufige Fehler und ihre Behebung

Zur Weiterleitungsschleife: Terminiert ein Dienst vor Nginx die TLS-Verbindung (zum Beispiel ein CDN wie Cloudflare) und verbindet er sich per HTTP mit dem Server, können Sie die Weiterleitung im Block für Port 80 an das Protokoll knüpfen, das dieser Dienst meldet:

listen 80;
server_name beispiel.de www.beispiel.de;

# Nur weiterleiten, wenn der Besucher den vorgeschalteten Dienst per HTTP erreicht hat
if ($http_x_forwarded_proto = "http") {
    return 301 https://$host$request_uri;
}

root /var/www/beispiel.de/public;

Vertrauen Sie diesem Header nur, wenn Sie sicher sind, dass die Anfragen wirklich von Ihrem eigenen Proxy kommen. Die dauerhafte Lösung besteht darin, auch die Strecke zwischen dem vorgeschalteten Dienst und Ihrem Server zu verschlüsseln. Dasselbe Problem tritt auf, wenn die Anwendung hinter Nginx selbst auf HTTPS weiterleitet, den Header X-Forwarded-Proto aber nicht berücksichtigt.

Checkliste

• ssl_certificate verweist auf die vollständige Kette (fullchain.pem), ssl_certificate_key auf den privaten Schlüssel.
• Der private Schlüssel ist nur für den berechtigten Benutzer lesbar und liegt weder in Backups noch in Repositorys offen.
• Die http://-Adresse führt in einem Schritt mit 301 zur https://-Adresse; es gibt keine Schleife.
• Nur TLS 1.2 und 1.3 sind aktiv.
• Es gibt keine Warnungen wegen gemischter Inhalte.
• HSTS wurde mit kurzer Dauer getestet und danach verlängert.
• Die Probe-Erneuerung ist erfolgreich; nach der Erneuerung wird Nginx neu geladen.
• Das Ablaufdatum des Zertifikats wird zusätzlich überwacht: Backup und Überwachung.

Häufige Fragen

Verwandte Anleitungen

• Sicherheitsheader und HTTPSHSTS, CSP, X-Content-Type-Options, Referrer-Policy und Permissions-Policy; mit .htaccess-Beispiel.
• Was ist SSL? Wozu dient SSL bei Websites und bei E-Mails?Was https und das Schloss-Symbol auf Websites und die SSL-Einstellung im E-Mail-Programm schützen und worin sie sich unterscheiden.
• Nginx als Reverse Proxy einrichtenSchritt für Schritt: server-Block, proxy_pass, weitergereichte Header, WebSocket, Timeouts und echte Client-IP.
• Nginx-Sicherheitseinstellungen: Ratenbegrenzung, Header, ZugriffsbeschränkungenRatenbegrenzung, Sicherheitsheader, Schutz versteckter Dateien und des Admin-Pfads sowie Anfragegrenzen in Nginx.