So installierst du ein SSL-Zertifikat auf NGINX

Diese Anleitung zeigt Ihnen, wie Sie ein SSL/TLS-Zertifikat auf NGINX installieren. Sie behandelt den Teil, an dem die meisten Nutzer scheitern: den Aufbau der korrekten Zertifikatskette („fullchain“), die NGINX benötigt, das Setzen der richtigen Direktiven auf die richtigen Dateien, das Testen der Konfiguration vor dem Neuladen sowie das Einrichten einer sauberen Weiterleitung von HTTP zu HTTPS, damit jeder Besucher auf der sicheren Version Ihrer Website landet.

CSR-Code für NGINX erzeugen

Wenn Sie Ihren CSR bereits erstellt haben und die ausgestellten Zertifikatsdateien vorliegen, springen Sie direkt zu SSL-Zertifikat auf NGINX installieren.

Bevor eine Zertifizierungsstelle Ihr Zertifikat ausstellen kann, müssen Sie einen CSR (Certificate Signing Request) einreichen: einen kleinen Textblock, der Ihre Domain-Daten und einen öffentlichen Schlüssel enthält, gepaart mit einem privaten Schlüssel, der auf dem Server verbleibt. Sie haben zwei Möglichkeiten:

• Erzeugen Sie den CSR automatisch mit unserem CSR-Generator. Das Tool liefert sowohl den CSR als auch den passenden privaten Schlüssel, den Sie anschließend auf den Server hochladen.
• Erzeugen Sie den CSR direkt auf dem Server mit OpenSSL, indem Sie unserem Tutorial zum Erstellen eines CSR auf NGINX folgen. Der private Schlüssel verbleibt dabei auf dem Server.

Öffnen Sie die resultierende .csr-Datei in einem beliebigen Texteditor; der darin enthaltene Textblock (einschließlich der Zeilen —–BEGIN CERTIFICATE REQUEST—– und —–END CERTIFICATE REQUEST—–) ist das, was Sie beim Bestellvorgang in das SSL-Antragsformular einfügen. Wenn Sie den Inhalt des CSR vor dem Absenden überprüfen möchten, fügen Sie ihn in unseren CSR-Decoder ein.

SSL-Zertifikat auf NGINX installieren

Sobald die CA das Zertifikat ausgestellt hat, erhalten Sie in der Regel:

• Ihr primäres (Server-)Zertifikat, meist eine .crt-Datei, die nach Ihrer Domain benannt ist.
• Die Zwischenzertifikate (und manchmal auch das Root-Zertifikat), entweder als separate .crt-Dateien oder in einer .ca-bundle-Datei gebündelt.
• Den privaten Schlüssel (eine .key-Datei), der zusammen mit Ihrem CSR erzeugt wurde.

NGINX benötigt das Serverzertifikat und die Zwischenkette in einer einzigen Datei kombiniert (die „fullchain“), auf die mit ssl_certificate verwiesen wird; der private Schlüssel wird separat über ssl_certificate_key referenziert. Das Auslassen der Kette ist der häufigste Installationsfehler überhaupt: Das Zertifikat sieht in einem Desktop-Browser einwandfrei aus, schlägt jedoch auf Android, in API-Clients und bei Tools wie unserem SSL Checker fehl.

Schritt 1: Zertifikate in einer Datei kombinieren

Die Reihenfolge der Zertifikate in der kombinierten Datei ist wichtig. Zuerst kommt Ihr Serverzertifikat, dann jedes Zwischenzertifikat von der ausstellenden CA aufwärts, mit dem Root-Zertifikat an letzter Stelle (oder ausgelassen, da Browser Root-Zertifikate bereits in ihrem integrierten Speicher vertrauen):

• Ihr primäres Zertifikat für den Domainnamen.
• Zwischenzertifikat(e).
• Root-Zertifikat (optional).

Sie können die fullchain-Datei manuell in einem Texteditor erstellen (jeden PEM-Block der Reihe nach einfügen) oder mit einem einzigen cat-Befehl. Wenn Sie separate Zwischen- und Root-Dateien erhalten haben, führen Sie aus:

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

Wenn die Zwischen- und Root-Zertifikate bereits in einer .ca-bundle-Datei enthalten sind, führen Sie aus:

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

Ersetzen Sie die Dateinamen durch Ihre eigenen. Verschieben Sie die kombinierte Datei (und den privaten Schlüssel, falls dieser sich noch nicht dort befindet) in das SSL-Verzeichnis auf Ihrem Server, zum Beispiel /etc/ssl/ oder /etc/nginx/ssl/. Sorgen Sie dafür, dass die Schlüsseldatei nur für root lesbar ist:

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

Schritt 2: Die NGINX-Konfigurationsdatei bearbeiten

Öffnen Sie die NGINX-Konfigurationsdatei für Ihre Website. Unter Debian und Ubuntu liegt sie in /etc/nginx/sites-available/ (mit einem symbolischen Link in sites-enabled/); unter RHEL, CentOS, AlmaLinux und Rocky Linux liegt sie in /etc/nginx/conf.d/. Fügen Sie den Server-Block hinzu, der auf Port 443 lauscht, oder bearbeiten Sie ihn so, dass er auf die fullchain-Datei und den privaten Schlüssel verweist:

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

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    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;

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

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

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

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

Ein paar Anmerkungen zu den obigen Direktiven:

• listen 443 ssl; aktiviert TLS auf Port 443. Die veraltete Direktive ssl on; wurde in NGINX 1.25 entfernt und sollte in modernen Konfigurationen nicht mehr vorkommen.
• http2 on; aktiviert HTTP/2 als eigenständige Direktive (NGINX 1.25.1 und höher). Ältere Konfigurationen verwendeten listen 443 ssl http2;, was zwar noch funktioniert, aber als veraltet gilt.
• ssl_protocols TLSv1.2 TLSv1.3; deaktiviert die veralteten Protokolle TLS 1.0 und 1.1. Ab NGINX 1.27.3 ist dies auch die Standardeinstellung, wenn Sie die Direktive weglassen, aber sie explizit zu setzen, ist die klarere und auditfreundlichere Wahl.
• Die Cipher-Liste entspricht dem „intermediate“-Profil von Mozilla und funktioniert mit jedem aktuellen Client. Wenn Sie nur TLS-1.3-Clients benötigen, können Sie ssl_ciphers vollständig weglassen.

Schritt 3: HTTP zu HTTPS weiterleiten

Fügen Sie einen separaten Server-Block auf Port 80 hinzu, der jede Anfrage dauerhaft zu HTTPS weiterleitet, damit Besucher, die über einfaches HTTP kommen, auf der sicheren URL landen:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Die Verwendung von return 301 ist schneller und sicherer als eine auf regulären Ausdrücken basierende rewrite-Regel und entspricht der von NGINX selbst empfohlenen Vorgehensweise.

Schritt 4: Konfiguration testen und NGINX neu laden

Prüfen Sie die Konfiguration immer, bevor Sie sie neu laden, damit ein Tippfehler den Dienst nicht lahmlegt:

sudo nginx -t

Sie sollten syntax is ok und test is successful sehen. Meldet das Programm einen Fehler, enthält die Meldung die Datei und Zeilennummer; korrigieren Sie den Fehler und führen Sie den Test erneut aus. Wenn der Test erfolgreich ist, laden Sie NGINX neu, damit die neue Konfiguration übernommen wird, ohne bestehende Verbindungen zu trennen:

sudo systemctl reload nginx

Auf Systemen ohne systemd verwenden Sie stattdessen das eigene Reload-Signal von NGINX:

sudo nginx -s reload

Bevorzugen Sie reload gegenüber restart: Ein Reload liest die Konfiguration neu ein, ohne aktive Verbindungen zu schließen, während ein Neustart diese trennt.

Schritt 5 (optional): OCSP Stapling aktivieren

OCSP Stapling ermöglicht es NGINX, zusammen mit dem Zertifikat einen aktuellen, signierten Sperrstatus auszuliefern, sodass Clients nicht bei jedem Handshake die CA kontaktieren müssen. Fügen Sie Folgendes in Ihrem HTTPS-Server-Block hinzu:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

Laden Sie NGINX erneut mit sudo systemctl reload nginx neu. Stapling ist ein kleiner, aber lohnender Härtungsschritt, und die meisten modernen Zertifikate unterstützen ihn ohne Weiteres.

Installation überprüfen

Öffnen Sie Ihre Website über https:// in einem Browser und prüfen Sie, ob das Schlosssymbol geschlossen ist und das Zertifikat zu Ihrer Domain passt. Führen Sie anschließend einen tiefergehenden Scan mit unserem SSL Checker durch, um sofort einen Bericht zum Zertifikat, zur Kette sowie zu den Protokollen und Ciphern zu erhalten, die Ihr Server anbietet. Ein grünes Ergebnis bedeutet, dass Clients auf allen wichtigen Plattformen dem Zertifikat vertrauen, einschließlich mobiler und API-Clients.

Häufig gestellte Fragen