Nginx mit HTTPS absichern: Eine Schritt-für-Schritt-Anleitung
Erfahren Sie in dieser umfassenden Schritt-für-Schritt-Anleitung, wie Sie Ihren Nginx-Webserver mit HTTPS absichern. Wir behandeln die Beschaffung kostenloser SSL/TLS-Zertifikate von Let's Encrypt mit Certbot, die Konfiguration von Nginx für verschlüsselte Verbindungen und die Implementierung wesentlicher Sicherheitsmaßnahmen wie HSTS. Schützen Sie Ihre Daten, bauen Sie Vertrauen bei Ihren Nutzern auf und verbessern Sie Ihr SEO mit einer richtig konfigurierten HTTPS-Einrichtung.
Nginx mit HTTPS absichern: Eine Schritt-für-Schritt-Anleitung
Nginx mit HTTPS abzusichern ist normalerweise eine kleine Aufgabe, aber es gehört zu den Aufgaben, bei denen kleine Fehler große Auswirkungen haben. Eine fehlende Zertifikatsdatei verhindert das Neuladen von Nginx. Eine vergessene Firewall-Regel lässt die Seite wie offline aussehen. Ein übereilter HSTS-Header kann Benutzer länger als beabsichtigt in einer defekten HTTPS-Konfiguration einsperren.
Die gute Nachricht ist, dass der normale Weg einfach ist. Sie zeigen mit DNS auf den Server, stellen sicher, dass Nginx auf Port 80 antwortet, verwenden Certbot, um ein Let's-Encrypt-Zertifikat anzufordern, testen die generierte Nginx-Konfiguration, laden sie neu und überprüfen dann die Verlängerung. Diesem Weg folgt diese Anleitung.
Ich werde im Folgenden example.com und www.example.com verwenden. Ersetzen Sie sie durch Ihre echten Namen und überspringen Sie die Überprüfungen nicht, bevor Sie Nginx neu laden.
Bevor Sie ein Zertifikat anfordern
Bevor Sie Certbot berühren, bestätigen Sie die langweiligen Teile. Die meisten Zertifikatsprobleme kommen von DNS, Firewalls oder einem Serverblock, der nicht für die angeforderte Domain antwortet.
Überprüfen Sie DNS von außerhalb des Servers:
dig +short example.com
dig +short www.example.com
Beide Namen sollten auf die öffentliche Adresse auflösen, die Ihren Nginx-Host oder Load Balancer erreicht.
Stellen Sie sicher, dass die Ports 80 und 443 auf jeder Ebene geöffnet sind: Cloud-Sicherheitsgruppe, Host-Firewall, Netzwerk-Firewall und jeder Load Balancer vor dem Host.
sudo ss -tulnp | grep nginx
sudo ufw status
Überprüfen Sie bei einer Cloud-VM auch die Konsole des Anbieters. Ich habe schon oft gesehen, dass saubere Nginx-Konfigurationen fehlschlugen, weil die Instanz-Firewall 443 erlaubte, die Cloud-Sicherheitsgruppe sie aber immer noch blockierte.
Bestätigen Sie schließlich, dass Nginx die Domain bereits über einfaches HTTP bedient:
curl -I http://example.com
curl -I http://www.example.com
Die Antwort muss nicht hübsch sein. Es kann eine Platzhalterseite sein. Es muss nur beweisen, dass Anfragen für diesen Hostnamen auf diesem Nginx-Server ankommen.
Certbot installieren
Für Debian/Ubuntu:
sudo apt update
sudo apt install certbot python3-certbot-nginx
Für RHEL-kompatible Systeme:
sudo dnf install certbot python3-certbot-nginx
Ältere CentOS-Systeme verwenden möglicherweise yum und benötigen möglicherweise zuerst EPEL. Die Paketnamen variieren auch je nach Distributionsversion. Verwenden Sie daher die Paketdokumentation Ihrer Distribution, wenn diese Befehle das Plugin nicht finden.
Das Zertifikat anfordern
Das Nginx-Plugin kann das Zertifikat anfordern und den passenden Serverblock bearbeiten:
sudo certbot --nginx -d example.com -d www.example.com
Certbot wird nach einer E-Mail-Adresse, der Zustimmung zu den Bedingungen und manchmal fragen, ob HTTP auf HTTPS umgeleitet werden soll. Für eine normale öffentliche Website wählen Sie die Weiterleitung. Für eine API oder einen internen Dienst überprüfen Sie zuerst die Clients. Einige ältere Clients oder Health Checks rufen möglicherweise immer noch http:// auf und erwarten eine bestimmte Antwort.
Wenn Certbot sagt, dass es keinen passenden Serverblock finden kann, überprüfen Sie server_name. Ein Block wie dieser gibt Certbot etwas Klares, mit dem es arbeiten kann:
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com/public;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
Führen Sie eine Syntaxprüfung durch, bevor Sie Certbot bitten, etwas zu bearbeiten:
sudo nginx -t
Wenn die aktuelle Konfiguration bereits defekt ist, beheben Sie das zuerst.
Wie die Nginx-Konfiguration aussehen sollte
Nach einem erfolgreichen Durchlauf sehen Sie normalerweise einen HTTP-Block, der weiterleitet, und einen HTTPS-Block, der die Seite bedient:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
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;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
root /var/www/example.com/public;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
Kopieren Sie dies nicht blind über eine Produktionskonfiguration. Bewahren Sie Ihre vorhandenen location-Regeln, Proxy-Einstellungen, Logs und Upload-Limits. Die wichtigen Teile sind listen 443 ssl, die Zertifikatspfade und das Weiterleitungsverhalten auf Port 80.
Testen, neu laden und überprüfen
Testen Sie immer vor dem Neuladen:
sudo nginx -t
Dann laden Sie neu:
sudo systemctl reload nginx
Überprüfen Sie von der Kommandozeile aus:
curl -I http://example.com
curl -I https://example.com
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
Die HTTP-Anfrage sollte weiterleiten, wenn Sie diese Option gewählt haben. Die HTTPS-Anfrage sollte den erwarteten Status zurückgeben. Der openssl-Befehl sollte ein Zertifikat anzeigen, dessen Betreff oder alternative Betreffnamen die Domain abdecken und dessen Daten aktuell sind.
Browser-Tests sind trotzdem wichtig. Öffnen Sie die Seite in einem privaten Fenster und klicken Sie auf das Schloss-Symbol, um das Zertifikat zu überprüfen. Wenn Ihre Seite Assets von alten http://-URLs lädt, kann die Seite gemischte Inhaltswarnungen anzeigen, auch wenn das Hauptzertifikat in Ordnung ist. Beheben Sie diese Asset-URLs in der App, dem CMS oder der Vorlagenebene.
Verlängerung
Let's-Encrypt-Zertifikate sind kurzlebig, daher muss die Verlängerung funktionieren, ohne dass Sie daran denken. Certbot installiert normalerweise einen systemd-Timer oder Cron-Job. Überprüfen Sie ihn:
systemctl list-timers | grep certbot
sudo certbot renew --dry-run
Der Trockenlauf ist der nützliche Teil. Er führt eine Verlängerungssimulation durch und fängt häufige Probleme wie defekte HTTP-Validierung, DNS-Änderungen, fehlende Plugins oder eine Konfiguration, die nicht neu geladen werden kann.
Wenn Sie TLS an einem Load Balancer oder CDN statt direkt auf dem Nginx-Host terminieren, benötigt die Verlängerung möglicherweise eine DNS-Challenge oder einen anderen Bereitstellungspfad. Gehen Sie nicht davon aus, dass die standardmäßige HTTP-Challenge funktioniert, wenn öffentlicher Datenverkehr diesen Server nie erreicht.
TLS-Einstellungen, die eine Überprüfung wert sind
Für die meisten modernen öffentlichen Websites sind TLS 1.2 und TLS 1.3 die praktische Grundlage:
ssl_protocols TLSv1.2 TLSv1.3;
Vermeiden Sie es, Cipher-Listen von Hand anzupassen, es sei denn, Sie wissen warum. Certbots enthaltene options-ssl-nginx.conf und der Mozilla SSL Configuration Generator sind bessere Ausgangspunkte als eine kopierte Cipher-Zeichenfolge aus einem alten Blogbeitrag. Cipher-Empfehlungen ändern sich im Laufe der Zeit, und die Kompatibilitätsanforderungen unterscheiden sich zwischen einer öffentlichen Marketing-Website und einer internen Legacy-API.
HSTS ist nützlich, verdient aber Vorsicht:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Beginnen Sie während des Tests mit einem kurzen Wert:
add_header Strict-Transport-Security "max-age=300" always;
Verwenden Sie includeSubDomains nur, wenn jede Subdomain gültiges HTTPS bereitstellen kann. Wenn old.example.com, mail.example.com oder eine kundenspezifische Subdomain nicht bereit ist, kann diese Option echte Benutzer beeinträchtigen.
Häufige Fehler
Wenn Certbot die Domain nicht verifizieren kann, überprüfen Sie zuerst DNS, dann Port 80, dann den Nginx-Serverblock. Die HTTP-01-Challenge erfordert, dass Let's Encrypt ein Token unter /.well-known/acme-challenge/ erreicht. Weiterleitungen sind in Ordnung, wenn sie richtig konfiguriert sind, aber ein Proxy, CDN oder Catch-All-Block kann die Challenge versehentlich woanders hinschicken.
Wenn Nginx nach Certbot-Änderungen nicht neu geladen werden kann, führen Sie aus:
sudo nginx -t
sudo journalctl -u nginx -n 80 --no-pager
Der Syntax-Test sagt Ihnen normalerweise die genaue Datei und Zeile. Häufige Ursachen sind doppelte listen 443 ssl-Blöcke, ein entfernter Zertifikatspfad oder ein Snippet, das von einem Pfad eingebunden wird, der auf diesem Server nicht existiert.
Wenn HTTPS lokal funktioniert, aber nicht für Benutzer, überprüfen Sie den öffentlichen Pfad. Ein Load Balancer zeigt möglicherweise immer noch auf eine alte Zielgruppe. Ein CDN hat möglicherweise eine Weiterleitung zwischengespeichert. IPv6-DNS zeigt möglicherweise auf einen anderen Host als IPv4. Testen Sie beide:
curl -4 -I https://example.com
curl -6 -I https://example.com
Die sauberste HTTPS-Konfiguration ist langweilig: DNS zeigt auf die richtige Stelle, Nginx hat einen offensichtlichen Serverblock für die Domain, die Certbot-Verlängerung besteht einen Trockenlauf, und Header werden nur hinzugefügt, nachdem die Grundlagen funktionieren.