Sichere Web-Kommunikation: Wildcard HTTPS mit Let's Encrypt und Nginx

Sichere Web-Kommunikation: Wildcard HTTPS mit Let's Encrypt und Nginx

14:51, 13.12.2023

Artikel Inhalt
arrow

  • Konfigurieren von Firewall-Regeln für HTTP/S
  • Erneuerung von Zertifikaten verwalten
  • Annullieren von Zertifikaten zur Verbesserung der Sicherheit
  • Verstärkung der Web-Sicherheitsmaßnahmen
  • Verwenden Sie nur sichere Protokolle
  • Aktivieren von HTTP Strict Transport Security (HSTS)
  • Verbesserung von Chiffriersuiten
  • Implementierung des ephemeren Diffie-Hellman-Algorithmus
  • Automatische Umleitung von unverschlüsselten Verbindungen
  • Einbindung aller Sicherheitsmaßnahmen in die Konfiguration

Sichere Web-Kommunikation ist für das reibungslose Funktionieren Ihres Servers sehr wichtig.

Viele verschiedene Ansätze bieten Verschlüsselung und damit Schutz für Ihre Serveraktivitäten. Natürlich ist es ratsam, verschiedene Sicherheitsmaßnahmen in Kombination zu verwenden, um die Zuverlässigkeit der Webkommunikation zu erhöhen.

In diesem Artikel befassen wir uns mit den verschiedenen Sicherheitsmethoden und damit, wie Sie diese auf Ihrem Server aktivieren und kombinieren können.

Konfigurieren von Firewall-Regeln für HTTP/S

Eine Firewall ist eine Software, die ein Betriebssystem schützt, indem sie den Zugang zum Internet regelt und Informationen aus dem Internet filtert. Mit einer Firewall erlauben oder blockieren Sie Datenverkehr oder bestimmte Arten von Datenverkehr.

Wenn Sie HTTP/S-Verkehr zulassen, weisen Sie die Firewall an, die Verschlüsselung von Daten aus dem Internet über HTTPS zu aktivieren. Wenn Sie die HTTP/S-Verkehrskonfiguration festlegen, erlauben Sie den Zugriff auf Websites, die die angegebenen Protokolle verwenden, in bestimmten Bereichen der Website oder der gesamten Website, auf der HTTP/S läuft.

Die Firewall-Regeln in CentOS 7 und ihre Standardeinstellungen erlauben beispielsweise keinen Zugriff auf HTTP/S-Protokolle. Auch bei Verwendung des Let's Encrypt-Clients wird der Zugriff nur dann erlaubt, wenn Sie die Konfiguration der Firewall-Regeln ändern.

Um die Standard-Firewall-Regelkonfiguration so zu ändern, dass HTTP/S-Datenverkehr zugelassen wird, benötigen Sie Folgendes:

  • Einen Cloud-Server mit RHEL 7 oder CentOS 7, der die Firewall unterstützt
  • Zugang zu Ihrem Server
  • Grundlegendes Verständnis von SSH

Loggen Sie sich zunächst über SSH in Ihren Server ein und vergewissern Sie sich, dass die Firewall unterstützt wird, indem Sie den Befehl "systemctl status firewalld" verwenden.

Führen Sie anschließend den folgenden Befehl für HTTP aus:

sudo firewall-cmd --permanent --zone=public --add-service=http

Befehl für HTTPS:

sudo firewall-cmd --permanent --zone=public --add-service=https

Starten Sie die Firewall neu, um die Änderungen mit diesem Befehl zu speichern:

sudo firewall-cmd --reload

Nach Abschluss dieser Schritte verfügt Ihr Server über die erforderliche Konfiguration, um die HTTP- und HTTPS-Versionen Ihrer Website anzuzeigen. Nachdem die Firewall-Konfiguration abgeschlossen ist, können Sie die Zertifikate installieren.

Erneuerung von Zertifikaten verwalten

Sie können Wildcard-Zertifikate verwenden, wenn Sie mehrere Domains (Hosts) auf Ihrem Server verwalten. Wildcard-Zertifikate sind SSL-Zertifikate, die mehrere Hosts schützen. Die Verwaltung mehrerer Hosts auf einem Server mit Wildcard-Zertifikaten kann Ihnen Zeit und Geld sparen.

Im Allgemeinen kann Let's Encrypt die erforderlichen Zertifikate automatisch installieren und Webdienste entsprechend ausführen. Wenn Sie bereits einen Let's Encrypt-Client haben, prima! Wenn nicht, müssen Sie die Clients Nginx und Certbot installieren, bevor Sie den Let's Encrypt-Client installieren. Um Zertifikate für Ihren Server zu erstellen, benötigen Sie außerdem einen Domainnamen und einen DNS-Anbieter, der den Certbot-Client unterstützt.

Nachdem Sie den Certbot-Client installiert haben, können Sie mit der Erstellung von Zertifikaten beginnen.

Beachten Sie, dass der Let's Encrypt-Client eine DNS-Validierung benötigt, um Wildcard-Zertifikate zu erhalten.

Der folgende Befehl wird verwendet, um Wildcard-Zertifikate zu erhalten:

sudo certbot certonly --manual --preferred-challenges=dns --email xyz@example.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d example.com -d .example.com

Wo:

  • certonly - Zertifikate beantragen
  • manual - Zertifikate beziehen
  • preferred-challenges=dns - Autorisierung über DNS
  • server - für die Zertifikatserstellung verwendeter Server
  • agree-tos - Zustimmung zu den Bedingungen und Konditionen
  • d - Domäne (oder Host), für die Zertifikate erstellt werden

Einige Zertifikate haben ein Verfallsdatum. Wenn ein aktives Zertifikat abläuft, können Sie daher Zertifikate erneuern.

Sie können überprüfen, ob die Erneuerung für die aktuellen (aktiven) Zertifikate funktioniert, indem Sie deren Ablauf mit dem folgenden Befehl in Certbot simulieren:

sudo certbot renew --dry-run

Verwenden Sie den folgenden Befehl, um Zertifikate in Certbot zu aktualisieren:

sudo certbot renew

Danach laden Sie den Webdienst neu, um aktualisierte Zertifikate zu erhalten:

sudo nginx -s reload

Wenn Sie diesen Vorgang automatisieren möchten, können Sie dies mit dem unten stehenden Skript tun.

sudo vi /etc/cron.daily/letsencrypt-renew
#!/bin/sh
if certbot renew > /var/log/letsencrypt/renew.log 2>&1 ; потом
nginx -s reload
fi
exit
sudo chmod +x /etc/cron.daily/letsencrypt-renew


Das Skript aktualisiert die Zertifikate und sendet die Ergebnisse an eine Protokolldatei; wenn die Aktualisierung erfolgreich war, führt das Skript einen Neustart des Nginx-Clients durch, um die Änderungen zu übernehmen.

Sobald der Prozess abgeschlossen ist, können Sie das Skript mit Crontab automatisieren, indem Sie die Crontab des Root-Benutzers öffnen und den folgenden Bearbeitungsbefehl verwenden:

sudo Crontab -e

Zum Automatisieren geben Sie den folgenden Befehl in das crontab-Fenster ein:

01 02,14 * * * /etc/cron.daily/letsencrypt-renew,

Die Skriptaktualisierungszeit ist 02:01 und 14:01, d.h. das Skript wird zweimal am Tag aktualisiert. Sie können die für Sie am besten geeignete Zeit einstellen.

Speichern Sie dann Ihre Änderungen.

Annullieren von Zertifikaten zur Verbesserung der Sicherheit

Um SSL-Zertifikate vom Server zu entfernen, führen Sie den folgenden Befehl mit Ihrem Domain- (oder Host-) Namen aus:

sudo certbot revoke --cert-path /etc/letsencrypt/live/domain_name/cert.pem

Nach der Ausführung dieses Befehls erhalten Sie keine Benachrichtigungen über Änderungen an den Zertifikaten. Sie können den Befehl jedoch erneut ausführen, und wenn er meldet, dass das Zertifikat bereits aufgehoben wurde, bedeutet dies, dass der Vorgang erfolgreich abgeschlossen wurde.

Verstärkung der Web-Sicherheitsmaßnahmen

Wenn Sie Zertifikate erhalten oder aktualisieren, überprüfen Sie den Nginx-Client auf weitere HTTPS-Konfiguration.

Verwenden Sie nur sichere Protokolle

Nicht alle Sicherheitsprotokolle sind gleich konzipiert, und einige sind weniger sicher als andere. So bleiben beispielsweise SSLv2- und SSLv3-Zertifikate in puncto Sicherheit hinter den TLS-Zertifikaten zurück. SSL-Zertifikate gelten als inhärente Schwachstellen bei den Sicherheitsprotokollen. Daher bestand die Notwendigkeit, sie durch fortschrittlichere Protokolle zu ersetzen. Bei SSL sind dies TLSv1.1 und TLSv1.2.

Aber auch bei den TLS-Zertifikaten ist es besser, neuere Zertifikate zu verwenden, auch wenn einige Browser noch ältere Versionen verlangen.

Aktivieren von HTTP Strict Transport Security (HSTS)

Strict Transport Security schützt TLS-Zertifikate und bietet sichere Links zu Websites, die diese verwenden. Selbst wenn es Konfigurations- oder Implementierungsprobleme gibt, bietet HSTS eine ausreichende Zertifikatsicherheit, so dass alle Links sicher sind. Außerdem werden die Benutzer über Angriffe informiert, indem die in den Zertifikaten enthaltene Link-Warnfunktion deaktiviert wird.

Sie können HTST mit dem folgenden Befehl aktivieren:

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";

Verbesserung von Chiffriersuiten

Der Zweck von Chiffriersuiten besteht darin, zu bewerten, wie sicher der Datenaustausch zwischen einem Webserver und den Besucherclients ist.

Nachstehend finden Sie ein Beispiel für RSA- und ECDSA-Schlüssel:

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA: ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256

Daher gibt der Client die von ihm verwendeten Zeichensätze an und überlässt den Servern die Auswahl. Der Client ordnet die Chiffren auf dem Server in absteigender Reihenfolge an, vom sichersten zum unsichersten. Sie können den folgenden Befehl verwenden, um diese Funktion zu aktivieren:

ssl_prefer_server_ciphers on;

Beachten Sie, dass diese Funktion mit SSL-Protokollen funktioniert, insbesondere mit SSLv3 und neueren.

Beachten Sie, dass diese Funktion mit SSL-Protokollen funktioniert, insbesondere mit
SSLv3 und neueren.

Implementierung des ephemeren Diffie-Hellman-Algorithmus

Der Diffie-Hellman-Algorithmus ist ein Protokoll, bei dem Schlüssel zwischen zwei Parteien ausgetauscht werden, um ein gegenseitiges Geheimnis zu schaffen, das außerhalb der Kommunikation der beiden Parteien nicht entdeckt werden kann. Im Wesentlichen handelt es sich bei einem solchen Algorithmus um eine Verschlüsselungsmethode, bei der zwei Parteien einen öffentlichen Schlüssel verwenden, um die ausgetauschten Daten zu verschlüsseln oder zu entschlüsseln. Einfach ausgedrückt, werden geheime Informationen mit öffentlich zugänglichen Informationen vermischt, so dass es unmöglich wird, die geheimen Informationen zu erkennen. Dies ist eine nützliche Methode, um einen gemeinsamen Schlüssel zwischen Server und Client zu erstellen und ihn zur Verschlüsselung der ausgetauschten Daten zu verwenden.

Das statische DH-Protokoll unterscheidet sich vom ephemeren Algorithmus dadurch, dass letzterer einen temporären Schlüssel für jede Interaktion erzeugt, ohne ihn zu wiederholen. Der ephemere Diffie-Hellman-Algorithmus bietet also eine langfristige Sicherheit, da der temporäre Schlüssel nicht deklassifiziert werden kann und auch die Daten, die er schützt, nicht.

Sie können den Diffie-Hellman-Algorithmus mit dem folgenden Befehl verwenden:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Die resultierende Ausgabe kann in der Nginx-Konfiguration verwendet werden, z.B. wie folgt:

ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

Automatische Umleitung von unverschlüsselten Verbindungen

Eine nützliche Methode zur Gewährleistung einer sicheren Webkommunikation besteht darin, unverschlüsselte HTTP-Verbindungen auf verschlüsselte HTTPS-Verbindungen umzuleiten. Dies kann mit dem folgenden Befehl geschehen:

server {
listen 80;
server_name_domain_name;
return 301 https://$server_name$request_uri;
}

Mit einem solchen Befehl erstellen Sie nur ein HTTP-Segment, damit Ihr Webserver es erkennen und die HTTP-Verbindung auf HTTPS umstellen kann. Auf diese Weise wird der Link, auch wenn er "http:" verwendet, in "https:" umgewandelt.

Einbindung aller Sicherheitsmaßnahmen in die Konfiguration

Obwohl der Certbot-Client die Nginx-Konfiguration speichert, wenn Sie CentOS verwenden, verhindert die manuelle Bearbeitung der Nginx-Client-Konfiguration, dass diese Datei in Zukunft aktualisiert wird. Erstellen Sie dazu eine neue Nginx-Datei mit dem folgenden Befehl:

sudo vi /etc/nginx/conf.d/domain_name.conf

Mit diesem Befehl erstellen Sie eine separate Nginx-Datei, die HTTPS-Verbindungen unter Verwendung aller zuvor genannten Sicherheitsmaßnahmen blockiert.

Um Sicherheitsmaßnahmen hinzuzufügen, duplizieren Sie das folgende Beispiel in Nginx:

# HTTPS server
server {.
listen 443 ssl;
server_name domain_name;
ssl_certificate /etc/letsencrypt/live/domain_name/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain_name/privkey.pem;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_ciphers
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA: ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
#HTTP redirect
server {
listen 80;
server_name_domain_name;
return 301 https://$server_name$request_uri;
}

Vergewissern Sie sich, dass Sie die Datei in Nginx speichern, und starten Sie Nginx mit dem folgenden Befehl neu:

sudo systemctl restart nginx

Sie können nun Ihre Website in einem Browser unter https://domain_name (Ihr Domainname) öffnen. Wenn sie geladen wird, bedeutet dies, dass die Installation erfolgreich war.

Wenn Sie weiter testen möchten, wie gut die serverseitige Verschlüsselung in Ihrem Browser funktioniert, verwenden Sie den Qualys SSL Labs-Test. Geben Sie den Namen Ihrer Domäne (Ihres Hosts) auf deren Website ein und klicken Sie auf "Submit". Der Test liefert Informationen über verschiedene Aspekte der Verschlüsselung Ihres Servers.

views 8m, 41s
views 2
Teilen

War dieser Artikel für Sie hilfreich?

VPS beliebte Angebote

Weitere Artikel zu diesem Thema

cookie

Cookies und Datenschutz akzeptieren?

Wir verwenden Cookies, um sicherzustellen, dass wir Ihnen die beste Erfahrung auf unserer Website bieten. Wenn Sie fortfahren, ohne Ihre Einstellungen zu ändern, gehen wir davon aus, dass Sie mit dem Empfang aller Cookies auf der HostZealot-Website einverstanden sind.