Dies ist ein Follow-up zu meinem vorherigen Post wo wir einen einfachen Reverse-Proxy-Server mit Nginx einrichten. In diesem Beitrag werden wir die Verbindung zwischen Client und Reverse-Proxy-Server mit kostenlosem TLS (a.k.ein SSL) Zertifikat von LetsEncrypt. Ich ermutige Sie, den oben genannten Beitrag zum Reverse-Proxy für die Grundlagen zu lesen basic.

Voraussetzungen

Ein Server mit statischer öffentlicher IP. Hier läuft Nginx.
Backend-Server mit der beabsichtigten Website, die über HTTP läuft running
Ein registrierter Domainname. Ich werde ranvirslog verwenden.com als meinen primären Domainnamen und die beiden Websites befinden sich unter FQDNs - ww1.ranvirslog.com und ww2ranvirslog.com

Einrichten

Die IP-Adressen haben sich also seit dem letzten Mal geändert, da ich dieses Setup erneut mache. Hier sind die neuen IPs und Hostnamen.

VM/Hostname	Öffentliche IP	Private IP	Rolle/Funktion
ReverseProxy	68.183.214.151	10.135.127.136	TLS-Terminierungspunkt und Reverse-Proxy-Server
web1	N / A	10.135.126.102	Hosting ww1.ranvirslog.com Website über Port 80 HTTP
web2	N / A	10.135.126.187	Hosting ww2.ranvirslog.com Website über Port 80 HTTP

Die DNS-Einträge sind so eingerichtet, dass beide Websites (verschiedene Subdomains) auf dieselbe statische öffentliche IP-Adresse verweisen. Dies ist zufällig die IP-Adresse unseres Nginx-Reverse-Proxys:

Ein Rekord	Wert
ww1.ranvirslog.com	68.183.214.151
ww2.ranvirslog.com	68.183.214.151

Damit unser Reverse-DNS über unverschlüsseltes HTTP funktioniert, haben wir zwei Dateien in /etc/conf . erstellt.d/ namens ww1.conf und ww2.conf jeweils mit folgender Konfiguration:

/etc/conf.d/ww1.conf

Server
hören 80;
zuhören [::]:80;
Servername ww1.ranvirslog.com;
Lage /
proxy_pass http://10.135.126.102/;
proxy_buffering aus;
proxy_set_header X-Real-IP $remote_addr;

/etc/conf.d/ww2.conf

Server
hören 80;
zuhören [::]:80;
Servername ww2.ranvirslog.com;
Lage /
proxy_pass http://10.135.126.187/;
proxy_buffering aus;
proxy_set_header X-Real-IP $remote_addr;

Das von uns verwendete Betriebssystem ist Ubuntu 18.04 LTS und wir haben entfernt die Datei /etc/nginx/sites-enabled/default, damit Nginx mit den oben gezeigten Konfigurationen rein als Reverse-DNS fungieren kann.

Zielsetzung

Da der Reverse-DNS (und die Backend-Websites) bereits in Betrieb sind, ist es unser Ziel, ein einziges TLS-Zertifikat für beide FQDNs (das ist ww1 .) zu installieren.ranvirslog.com und ww2.ranvirslog.com) auf unserem Nginx-Reverse-Proxy.

Der Datenverkehr zwischen jedem Client und dem Reverse-Proxy wird verschlüsselt, aber der Datenverkehr zwischen dem Reverse-Proxy und den Back-End-Servern ist nicht verschlüsselt. Dies ist jedoch immer noch eine unendlich sicherere Option, als gar kein HTTPS zu haben. In Fällen, in denen sich der Reverse-Proxy und die verschiedenen Webserver auf demselben Host befinden, beispielsweise wenn Sie Docker-Container verwenden, um alle auf demselben VPS zu hosten, ist sogar dieser unverschlüsselte Datenverkehr auf einem einzigen Host enthalten single.

Certbot installieren

Certbot ist ein Client-Programm, das auf unserem Reverse-Proxy-Server läuft und ein TLS-Zertifikat mit LetsEncrypt aushandelt. Es wird LetsEncrypt beweisen, dass der Server tatsächlich die Kontrolle über die FQDNs hat, über die er angeblich die Kontrolle hat. Wir werden uns keine Sorgen machen, wie Certbot es macht.

Traditionell können Sie Certbot als eigenständige Software verwenden, die nur die Zertifikate (die im Grunde nur lange kryptografische Schlüssel sind) abruft und auf dem Server speichert. Aber zum Glück gibt es für die meisten Betriebssysteme benutzerdefinierte Plugins für Nginx, Apache und andere Software. Wir werden den Certbot mit Nginx-Plugin installieren. Dadurch wird Nginx automatisch so konfiguriert, dass es die neu erhaltenen Schlüssel verwendet und unsichere Regeln wie das Abhören von HTTP auf Port 80 beseitigt.

Wenn Sie Debian-basierte Systeme verwenden, wie in meinem Fall verwende ich Ubuntu 18.04 LTS, dann ist die Installation ein Kinderspiel.

$ sudo apt-Update
$ sudo apt install software-properties-common
$ sudo add-apt-repository-universum
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-Update
$ sudo apt install python-certbot-nginx

Andere Betriebssysteme, Ihr RedHat, Gentoo, Fedora können den hier aufgeführten offiziellen Anweisungen folgen.

Sobald Sie Certbot . installiert haben mit Nginx-Plugin für Ihre OS-Kombination können wir zur Sache kommen.

TLS-Zertifikate erhalten

Führen Sie den folgenden Befehl aus, um das TLS-Zertifikat zum ersten Mal abzurufen:

$ sudo certbot --nginx

Dies wird eine Reihe interaktiver Fragen durchlaufen, wie unten gezeigt:

Geben sie ihre E-Mail Adresse ein

Debug-Protokoll speichern unter /var/log/letsencrypt/letsencrypt.Log
Ausgewählte Plugins: Authenticator nginx, Installer nginx
Geben Sie die E-Mail-Adresse ein (wird für dringende Verlängerungs- und Sicherheitshinweise verwendet) (Geben Sie 'c' ein, um abzubrechen): [E-Mail geschützt]

Stimmen Sie den AGB zu

Bitte lesen Sie die Nutzungsbedingungen unter https://letsencrypt.org/dokumente/LE-SA-v1.2-November-15-2017.pdf. Sie müssen zustimmen, um sich beim ACME-Server unter https://acme-v02 . zu registrieren.api.letsencrypt.org/verzeichnis
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)Gree/(C)Cancel: A

Optionaler Newsletter

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Wären Sie bereit, Ihre E-Mail-Adresse mit der Electronic Frontier Foundation, einem Gründungspartner des Let's Encrypt-Projekts und der gemeinnützigen Organisation, die Certbot entwickelt, zu teilen?? Wir möchten Ihnen eine E-Mail über unsere Arbeit zur Verschlüsselung des Internets, EFF-Nachrichten, Kampagnen und Möglichkeiten zur Unterstützung der digitalen Freiheit senden.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(J)es/(N)o: Ja

Es erkennt dann die Domainnamen auf Ihrem Server, und wenn Sie alle Domains auswählen möchten, drücken Sie einfach

Für welche Namen möchten Sie HTTPS aktivieren?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: ww1.ranvirslog.com
2: ww2.ranvirslog.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Wählen Sie die entsprechenden Zahlen, die durch Kommas und/oder Leerzeichen getrennt sind, oder lassen Sie die Eingabe leer, um alle angezeigten Optionen auszuwählen (geben Sie 'c' ein, um abzubrechen):

Alles an TLS umleiten. Ich habe die Option 2 gewählt, um alles auf SSL umzuleiten, aber Ihr Anwendungsfall kann sich unterscheiden. Für neue Backend-Installationen ist es sicher Option 2 zu wählen.

Bitte wählen Sie aus, ob HTTP-Datenverkehr auf HTTPS umgeleitet und der HTTP-Zugriff entfernt werden soll.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1: Keine Weiterleitung - Nehmen Sie keine weiteren Änderungen an der Webserver-Konfiguration vor.
2: Umleitung – Alle Anfragen an einen sicheren HTTPS-Zugriff umleiten. Wählen Sie diese Option für neue Websites oder wenn Sie sicher sind, dass Ihre Website auf HTTPS funktioniert. Sie können diese Änderung rückgängig machen, indem Sie die Konfiguration Ihres Webservers bearbeiten.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Wählen Sie die entsprechende Nummer [1-2] und dann [enter] (drücken Sie 'c' zum Abbrechen): 2

Wenn alles gut gelaufen ist, wird Ihnen diese Nachricht angezeigt, stattdessen nur für Ihre Domainnamen.

Herzliche Glückwünsche! Sie haben https://ww1 . erfolgreich aktiviert.ranvirslog.com und https://ww2.ranvirslog.com Sie können die FQDNs besuchen und feststellen, dass die Websites jetzt das Vorhängeschloss-Zeichen haben, das darauf hindeutet, dass alles verschlüsselt ist.

Sehen Sie sich die Konfigurationsdateien an

Wenn Sie die zuvor erstellten Konfigurationsdateien anzeigen, nämlich /etc/conf.d/ww1.conf und /etc/conf.d/ww2.conf, werden Sie feststellen, dass alle „Listen 80“-Regeln verschwunden sind und ein paar neue Zeilen hinzugefügt wurden, die dem Server mitteilen, dass die Kommunikation verschlüsselt werden muss und den Ort der Zertifikate und Schlüssel, um die Verschlüsselung durchzuführen perform.

Ich empfehle dringend, die Konfigurationsdateien durchzusehen, da Sie dadurch auch lernen können, wie Sie Zertifikate richtig installieren und Konfigurationsdateien schreiben.

Zertifizierungsverlängerung

Typische LetsEncrypt-Zertifikate sind 90 Tage gültig und müssen vor Ablauf erneuern. Sie können Certbot verwenden, um die Erneuerung zuerst zu testen, indem Sie den folgenden Befehl ausführen:

$ sudo certbot renew --dry-run

Wenn der Vorgang erfolgreich ist, sehen Sie die folgende Meldung:

Herzlichen Glückwunsch, alle Verlängerungen erfolgreich. Folgende Zertifikate wurden erneuert:

/etc/letsencrypt/live/ww1.ranvirslog.com/fullchain.pem (Erfolg)
** DRY RUN: Simulation von 'certbot renew' kurz vor Ablauf des Zertifikats
** (Die obigen Prüfzeugnisse wurden nicht gespeichert.)

Jetzt können Sie einen Cron-Job hinzufügen, der jede Woche oder so eine Verlängerung versucht. Certbot wird die Zertifikate nicht verlängern, es sei denn, sie sind dafür wirklich fällig, Sie müssen sich also keine Sorgen machen. Der Befehl für die tatsächliche Erneuerung lautet:

$ certbot erneuern

Fügen Sie es dem Cron-Job von root hinzu, indem Sie Folgendes verwenden:

$ sudo crontab -e

Wählen Sie in der folgenden Eingabeaufforderung Ihren bevorzugten Editor aus (wählen Sie Nano, wenn Sie sich nicht sicher sind) und fügen Sie am Ende der jetzt geöffneten Datei die folgenden Zeilen hinzu:

…
# Sie können beispielsweise ein Backup aller Ihrer Benutzerkonten durchführen
# um 5 Uhr.m jede Woche mit:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# Weitere Informationen finden Sie in den Handbuchseiten von crontab(5) und cron(8)
#
# m h dom mon dow Befehl
* 2 * * 2 certbot erneuern

Dadurch wird der Befehl certbot renew um 2 Uhr morgens zu jeder beliebigen Minute am zweiten Tag jeder Woche ausgeführt run.

Fazit

Wenn Sie neu bei TLS-Zertifikaten sind, kann das Experimentieren mit Dingen wie HSTS riskant sein. Da diese Änderungen irreversibel sind. Wenn Sie jedoch in den Kaninchenbau der Sicherheit gehen möchten, kann ich Troy Hunts Blog wärmstens empfehlen, der eine der Hauptinspirationen hinter diesem Artikel ist.

Nginx Reverse Proxy mit HTTPS über LetsEncrypt