So installieren Sie ein SSL-Zertifikat auf Nginx

Dieser Leitfaden führt Sie durch die Installation eines SSL-Zertifikats auf Nginx — vom Hochladen der Dateien über die Optimierung der TLS-Einstellungen bis zur Fehlerbehebung häufiger Probleme. Er funktioniert mit Zertifikaten von GetHTTPS, Certbot oder jeder anderen Quelle.

Wenn Sie noch kein Zertifikat haben, besorgen Sie sich eines kostenlos in 5 Minuten.

Voraussetzungen

• Nginx installiert und Ihre Website wird auf HTTP (Port 80) ausgeliefert
• Root-/Sudo-Zugriff auf den Server
• Zertifikatsdateien — Sie benötigen zwei:
  • fullchain.pem — Ihr Zertifikat + Zwischen-Kette (kombiniert)
  • privkey.pem — Ihr privater Schlüssel

Welche Datei ist welche? GetHTTPS gibt Ihnen vier Dateien. Nginx benötigt fullchain.pem (nicht cert.pem) und privkey.pem. Die Verwendung von cert.pem allein verursacht Fehler wegen „unvollständiger Kette”, da Browser den Vertrauenspfad nicht verifizieren können. Zertifikatsformate erklärt →

Schritt 1: Zertifikatsdateien auf den Server hochladen

Kopieren Sie die Dateien in ein sicheres Verzeichnis:

# Verzeichnis erstellen
sudo mkdir -p /etc/ssl/gethttps

# Dateien kopieren (von Ihrem lokalen Rechner zum Server)
sudo cp fullchain.pem /etc/ssl/gethttps/
sudo cp privkey.pem /etc/ssl/gethttps/

# Berechtigungen des privaten Schlüssels einschränken — nur root sollte ihn lesen können
sudo chmod 600 /etc/ssl/gethttps/privkey.pem
sudo chmod 644 /etc/ssl/gethttps/fullchain.pem
sudo chown root:root /etc/ssl/gethttps/*

Bei Übertragung via SCP:

scp fullchain.pem privkey.pem user@your-server:/tmp/
# Dann auf dem Server:
sudo mv /tmp/fullchain.pem /tmp/privkey.pem /etc/ssl/gethttps/

Schritt 2: HTTPS-Serverblock konfigurieren

Bearbeiten Sie die Nginx-Konfiguration Ihrer Website. Die Datei befindet sich typischerweise unter:

• /etc/nginx/sites-available/yourdomain.conf (Debian/Ubuntu)
• /etc/nginx/conf.d/yourdomain.conf (CentOS/RHEL)

Vollständige empfohlene Konfiguration:

# HTTPS-Serverblock
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

    # ─── Zertifikatsdateien ──────────────────────
    ssl_certificate     /etc/ssl/gethttps/fullchain.pem;
    ssl_certificate_key /etc/ssl/gethttps/privkey.pem;

    # ─── TLS-Protokoll und Chiffren ──────────────
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # ─── Session-Caching (Leistung) ─────────────
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # ─── OCSP-Stapling (schnellere Verifizierung) ─
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # ─── Sicherheitsheader ───────────────────────
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;

    # ─── Ihre Website ───────────────────────────
    root /var/www/html;
    index index.html;

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

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

Was jeder Abschnitt bewirkt:

Schritt 3: Konfiguration testen

Testen Sie immer vor dem Neuladen:

sudo nginx -t

Erwartete Ausgabe:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Wenn der Test fehlschlägt, zeigt Nginx Ihnen die genaue Zeilennummer mit dem Fehler. Häufige Fehler:

• Tippfehler im Dateipfad (ssl_certifcate statt ssl_certificate)
• Datei existiert nicht am angegebenen Pfad
• Fehlende Semikolons

Schritt 4: Nginx neu laden

sudo systemctl reload nginx

Verwenden Sie reload, nicht restart. Reload wendet die neue Konfiguration auf neue Verbindungen an, ohne bestehende zu trennen — keine Ausfallzeit.

Schritt 5: Zertifikat verifizieren

Browser-Check

Besuchen Sie https://yourdomain.com. Klicken Sie auf das Schloss-Symbol, um zu bestätigen:

• Ausgestellt von: „Let’s Encrypt” (oder Ihre CA)
• Gültig: Start- und Enddaten
• Domain: stimmt mit Ihrer URL überein

Kommandozeilen-Check

# Vollständige Zertifikatsdetails
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Prüfen, ob die vollständige Kette vorhanden ist
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | grep -E 'Verify return code|depth='

Erwartet: Verify return code: 0 (ok) und mehrere Tiefenstufen (Ihr Zertifikat + Zwischenzertifikat).

Online-Check

Verwenden Sie den SSL Labs Server Test für einen umfassenden Bericht. Er prüft:

• Gültigkeit der Zertifikatskette
• Protokollunterstützung (sollte nur TLS 1.2 + 1.3 zeigen)
• Stärke der Cipher-Suites
• Bekannte Schwachstellen (BEAST, POODLE, Heartbleed)
• HSTS-Konfiguration

Ziel: Note A oder A+.

So erneuern Sie

Wenn sich Ihr Zertifikat dem Ablauf nähert (Tag 60 von 90 bei Let’s Encrypt):

1. Besorgen Sie ein neues Zertifikat von GetHTTPS (oder Ihrem Erneuerungstool)
2. Ersetzen Sie die Dateien:

   sudo cp new-fullchain.pem /etc/ssl/gethttps/fullchain.pem
   sudo cp new-privkey.pem /etc/ssl/gethttps/privkey.pem

3. Laden Sie Nginx neu:

   sudo systemctl reload nginx

Kein Neustart erforderlich. Nginx übernimmt die neuen Dateien beim Neuladen. Vollständiger Erneuerungsleitfaden →

Automatische Erneuerung gewünscht? Installieren Sie Certbot für automatische Erneuerung: sudo certbot --nginx -d example.com. Es übernimmt alles einschließlich der Nginx-Konfiguration.

Fehlerbehebung

„SSL: error:0B080074:x509 certificate routines”

Ursache: Sie verwenden cert.pem anstelle von fullchain.pem.

Lösung: Ändern Sie ssl_certificate, sodass es auf fullchain.pem verweist, das sowohl Ihr Zertifikat als auch die Zwischen-Vertrauenskette enthält:

ssl_certificate /etc/ssl/gethttps/fullchain.pem;  # NICHT cert.pem

„cannot load certificate key”

Ursache: Berechtigungen der privaten Schlüsseldatei sind falsch, die Datei ist beschädigt oder der Schlüssel passt nicht zum Zertifikat.

Lösung:

# Berechtigungen prüfen (sollte 600 sein)
ls -la /etc/ssl/gethttps/privkey.pem

# Prüfen, ob der Schlüssel gültig ist
sudo openssl ec -in /etc/ssl/gethttps/privkey.pem -check  # Für ECDSA
sudo openssl rsa -in /etc/ssl/gethttps/privkey.pem -check  # Für RSA

# Prüfen, ob Schlüssel zum Zertifikat passt
sudo openssl x509 -noout -modulus -in /etc/ssl/gethttps/fullchain.pem | md5sum
sudo openssl rsa -noout -modulus -in /etc/ssl/gethttps/privkey.pem | md5sum
# Beide Hashes MÜSSEN übereinstimmen

„nginx: [emerg] bind() to 0.0.0.0:443 failed”

Ursache: Port 443 wird bereits von einem anderen Prozess verwendet.

Lösung:

# Herausfinden, was Port 443 verwendet
sudo ss -tlnp | grep 443

# Normalerweise: eine andere Nginx-Instanz oder Apache
sudo systemctl stop apache2  # Falls Apache läuft
sudo systemctl reload nginx

HTTPS funktioniert, aber der Browser zeigt „Nicht sicher”

Ursache: Mixed Content — Ihre Seite lädt Bilder, Skripte oder CSS über http://.

Lösung: Öffnen Sie DevTools (F12) → Konsole → suchen Sie nach „Mixed Content”-Warnungen. Aktualisieren Sie alle Ressourcen-URLs auf https:// oder relative Pfade.

„ERR_SSL_VERSION_OR_CIPHER_MISMATCH”

Ursache: Der Client unterstützt die TLS-Versionen oder Chiffren nicht, die Ihr Server anbietet.

Lösung: Stellen Sie sicher, dass Ihre Konfiguration TLS 1.2 enthält (nicht nur 1.3):

ssl_protocols TLSv1.2 TLSv1.3;  # NICHT nur TLSv1.3

Zertifikat wird als „Nicht vertrauenswürdig” angezeigt, obwohl die Dateien korrekt sind

Ursache: Die Zertifikatskette ist unvollständig — fullchain.pem fehlt das Zwischenzertifikat, oder die Datei ist in der falschen Reihenfolge.

Lösung: Erstellen Sie fullchain.pem neu, indem Sie Ihr Zertifikat und das Zwischenzertifikat zusammenfügen:

cat cert.pem chain.pem > fullchain.pem

Die Reihenfolge ist wichtig: Ihr Zertifikat zuerst, dann das Zwischenzertifikat.

Häufig gestellte Fragen

Benötige ich separate Konfigurationsdateien für HTTP und HTTPS?

Nein. Fügen Sie beide server-Blöcke (Port 80 und 443) in dieselbe Datei ein. Der HTTP-Block existiert nur, um zu HTTPS weiterzuleiten.

Sollte ich ssl on; verwenden?

Nein. ssl on; ist veraltet. Verwenden Sie stattdessen listen 443 ssl; — der ssl-Parameter in der listen-Direktive ist der moderne Ansatz.

Was ist der Unterschied zwischen reload und restart?

reload wendet die neue Konfiguration elegant auf neue Verbindungen an, ohne bestehende zu trennen. restart stoppt und startet den Prozess, wobei kurzzeitig alle Verbindungen getrennt werden. Verwenden Sie für Zertifikatsänderungen immer reload.

Kann ich mehrere Domains mit unterschiedlichen Zertifikaten bedienen?

Ja. Verwenden Sie separate server-Blöcke mit unterschiedlichen server_name, ssl_certificate und ssl_certificate_key-Direktiven. Nginx verwendet SNI (Server Name Indication), um das korrekte Zertifikat basierend auf dem angeforderten Hostnamen auszuliefern.

Unterstützt Nginx ECDSA/ECC-Zertifikate?

Ja. Nginx behandelt ECDSA-Zertifikate genau wie RSA — gleiche Direktiven, gleiches Dateiformat. GetHTTPS generiert standardmäßig ECDSA P-256 (kleinere Schlüssel, schnellere Handshakes).

Wie aktiviere ich HTTP/2?

Fügen Sie http2 zur listen-Direktive hinzu: listen 443 ssl http2;. Dies ist bereits in der obigen empfohlenen Konfiguration enthalten. HTTP/2 erfordert HTTPS — es kann nicht über unverschlüsseltes HTTP verwendet werden.