Einführung
Seit Version 8.0.3 unterstützt Ignition das Hot-Reloading des SSL-Key Speichers ein. Dank dieser Funktion kann Ignition mit Diensten wie Let’s Encrypt zusammenarbeiten, die eine automatische SSL-Zertifikatsverwaltung bieten. In diesem Dokument wird ein Beispiel für die Integration von Ignition mit Let’s Encrypt erläutert.
Hintergrund
Bevor wir weitermachen, ist es wichtig, ein grundlegendes Verständnis von SSL-Zertifikaten, dem ACME-Framework und dem Let’s Encrypt-Dienst zu haben.
Um sensible Transaktionen im Internet sicher durchführen zu können, verwenden wir Transport Layer Security (TLS), das Secure Sockets Layer (SSL) ablöst. TLS ermöglicht eine sichere Kommunikation über ein unsicheres Netzwerk wie das Internet. SSL-Zertifikate werden als Teil von TLS verwendet, damit sich ein Webserver (wie ein Ignition-Gateway) gegenüber einem Webclient (wie Ihrem Webbrowser) identifizieren und einen Schlüssel für die verschlüsselte Kommunikation bereitstellen kann. Standardmässig vertraut Ihr Webbrowser keinem von einem Webserver vorgelegten SSL-Zertifikat. Ihr Webbrowser verwaltet eine Liste von Stammzertifikaten, die von Dritten, so genannten Zertifizierungsstellen (CAs), ausgestellt wurden. Ihr Browser vertraut diesen Zertifizierungsstellen, und es liegt in der Verantwortung dieser Zertifizierungsstellen, zu überprüfen, ob eine Organisation eine Domäne kontrolliert.
Wenn eine Organisation möchte, dass Webclients ihrem Webserver in ihrer Domäne vertrauen, stellt sie eine Zertifikatsanforderung (Certificate Signing Request, CSR) aus und sendet diese an eine CA. Dies ist vergleichbar mit einer Person, die einen Führerschein beantragt. Die Zertifizierungsstelle kann Hintergrundprüfungen durchführen, um sicherzustellen, dass die Organisation rechtmässig ist und die angegebene Domäne tatsächlich kontrolliert. Wenn alles in Ordnung ist, stellt die Zertifizierungsstelle das SSL-Zertifikat aus, das die Organisation an ihre Domäne bindet, so wie eine Regierungsbehörde einer Person einen gültigen Führerschein ausstellt, der die Identität der Person und ihr Recht, die Strasse zu benutzen, bestätigt.
Sobald dieses von der Zertifizierungsstelle signierte SSL-Zertifikat auf dem Webserver der Organisation installiert ist, wird es jedem Web-Client angezeigt, der sich mit ihm verbindet. Da die Web-Clients der Zertifizierungsstelle vertrauen und die Zertifizierungsstelle das vom Webserver vorgelegte SSL-Zertifikat signiert hat, kann der Web-Client dem Webserver vertrauen und wird sichere Transaktionen mit ihm durchführen.
ACME ist ein Akronym: Automatic Certificate Management Environment. ACME wird in RFC 8555 ausführlich beschrieben. Einfach gesagt ist ACME ein automatisiertes Rahmenwerk für den Erhalt und die Erneuerung von SSL-Zertifikaten für Ihre Domain, so dass Sie SSL / TLS in Ihrem Webserver aktivieren können. Dieses Framework vereinfacht den traditionellen Lebenszyklus von SSL-Zertifikaten, der umständlich ist und von CA zu CA variiert, erheblich.
Let’s Encrypt ist „eine kostenlose, automatisierte und offene Zertifizierungsstelle (CA), die zum Nutzen der Öffentlichkeit betrieben wird“. Let’s Encrypt erreicht dies durch den Betrieb eines ACME-Servers. Jeder Domain-Administrator, der kostenlose SSL-Zertifikate erhalten möchte, denen fast alle Plattformen vertrauen, kann einen ACME-Client einrichten, der auf den ACME-Server von Let’s Encrypt zeigt.
Ansatz
Ab Ignition 8.0.3 holt das Gateway den privaten SSL-Schlüssel und die Zertifikate aus der PKCS12-Schlüsselspeicherdatei, die sich unter $IGNITION/webserver/ssl.pfx befindet. Während der Ausführung des Gateways ist es möglich, diese Schlüsselspeicherdatei durch eine Datei zu ersetzen, die neue Zertifikate enthält. Standardmässig überprüft das Gateway die Datei alle 15 Minuten und übernimmt alle Änderungen. Sie können aber auch den folgenden GCU-Befehl verwenden, um den Schlüsselspeicher sofort von der Festplatte neu zu laden (unter der Annahme einer Linux-Umgebung):
gwcmd.sh –reloadks
Um den Prozess der Zertifikatserneuerung zu automatisieren, haben wir den folgenden Ansatz, um den Prozess der SSL-Zertifikatserneuerung für Ignition zu automatisieren:
- Verwenden Sie einen ACME-Client, um ein SSL-Zertifikat von Let’s Encrypt zu erhalten.
- Verwenden Sie eine Reihe von Tools, um die Zertifikate und Schlüssel in einen PKCS12-Schlüsselspeicher zu konvertieren.
- Kopieren Sie die neue Schlüsselspeicherdatei nach $IGNITION/webserver/ssl.pfx
- Rufen Sie den GCU-Befehl reload key store auf, um den neuen Schlüsselspeicher von der Festplatte zu übernehmen.
Der oben beschriebene allgemeine Ansatz kann als Skript ausgeführt und mit den von Ihnen bevorzugten Tools geplant werden.
ACME-Client
Ich habe mich für die Verwendung von Certbot als ACME-Client entschieden. Wenn Sie sich dafür entscheiden, lesen Sie bitte die Certbot-Dokumentation, um zu erfahren, wie Sie die Software auf Ihrem Rechner installieren. Die folgenden Beispiele verwenden Certbot Version 0.31.0 auf Ubuntu 18.04.2 LTS.
Damit der ACME-Server von Let’s Encrypt ein neues Zertifikat ausstellen kann, müssen wir die Kontrolle über unseren Domainnamen nachweisen können. Der ACME-Server kann entweder eine DNS-Abfrage oder eine HTTP-Abfrage durchführen. Bei jeder Art der Abfrage generiert der ACME-Server ein zufälliges Token. Der ACME-Client nimmt dieses Token und signiert es, um den Besitz des privaten Schlüssels zu beweisen, der mit dem öffentlichen Schlüssel des SSL-Zertifikats verbunden ist. Im Falle der DNS-Challenge wird das signierte Token als DNS-TXT-Eintrag abgelegt. Bei der HTTP- Challenge wird das signierte Token als Ressource auf einem HTTP-Server (Port 80) ausgesetzt, der von einer öffentlichen IP-Adresse aus erreichbar ist, auf die Ihr Domänenname verweist.
In meinem Fall:
- Ich möchte eine HTTP-Abfrage durchführen
- Ignition ist an Port 80 gebunden
- Ich möchte Ignition bei der Erneuerung des SSL-Zertifikats nicht stoppen
Ignition bietet direkte Unterstützung für die Offenlegung der ACME-HTTP-Challenge. Erstellen Sie einfach eine Datei mit dem Token-Wert als Dateinamen und dem signierten Token als Inhalt der Datei in $IGNITION/.well-known/acme-challenge/<token>. Das Gateway gibt den Inhalt der Datei zurück, wenn von der HTTP-Ressource /.well-known/acme-challenge/<token> aus darauf zugegriffen wird. Das ist genau das, was der ACME-Server benötigt, um Ihre Kontrolle über die Domain zu überprüfen.
Um dies zu erreichen, habe ich den folgenden certbot-Befehl ausgeführt:
certbot certonly –webroot
Folgen Sie den Aufforderungen auf dem Bildschirm, um Ihre E-Mail-Adresse einzugeben, die Bedingungen zu akzeptieren und Ihre Domain einzugeben. Wenn Certbot Sie nach dem Pfad zu Ihrem Webroot fragt, geben Sie den Pfad zu Ihrer $IGNITION Installation ein (Stammverzeichnis, in dem das Gateway installiert ist). Certbot erstellt automatisch die Token-Datei in $IGNITION/.well-known/acme-challenge/<token> für Sie und entfernt die Datei, sobald der ACME-Server sie verifiziert oder ein Fehler auftritt.
Wenn Sie stattdessen eine DNS-Challenge verwenden möchten, gibt es eine Vielzahl von Plugins für certbot. So gibt es beispielsweise ein Plugin, mit dem Sie die Challenge über die Route 53-Dienste von AWS schreiben können, wenn Sie AWS Route 53 als DNS-Server verwenden.
Wenn Ignition nicht auf Port 80 läuft und Sie keinen anderen Dienst auf Port 80 laufen haben, können Sie die Option –standalone von Certbot anstelle von –webroot verwenden. Dadurch wird Certbot seinen eigenen HTTP-Server einrichten, der für die Dauer der HTTP-Herausforderung an Port 80 gebunden ist.
Standardmässig verweist Certbot auf die produktiven Let’s Encrypt-Dienste. Vielleicht möchten Sie beim Lernen/Experimentieren mit der Option –test-cert herumspielen. Dieses Flag verweist certbot auf die Staging-Dienste von Let’s Encrypt, die hinsichtlich der Ressourcenbeschränkungen nachsichtiger sind. Allerdings müssen Sie dem gefälschten Staging-Root-CA-Zertifikat vorübergehend vertrauen, während Sie mit Staging-Zertifikaten testen. Auf der Website von Let’s Encrypt finden Sie weitere Informationen.
Es gibt noch eine Reihe anderer, hier nicht genannter Möglichkeiten, die ACME-Challenge durchzuführen. Die beste Option hängt von Ihrer Netzwerkarchitektur, Ihren Anforderungen und Ihren persönlichen Vorlieben ab.
Erstellen des Schlüsselspeichers
An dieser Stelle wird davon ausgegangen, dass Sie ein CA-signiertes SSL-Zertifikat erhalten haben. Wenn Sie wie ich Certbot in Ubuntu Linux verwendet haben, ist der Standardspeicherort für die Zertifikatskette und den privaten Schlüssel wie folgt:
Zertifikatskette: /etc/letsencrypt/live/<Ihr Domainname>/fullchain.pem
Privater Schlüssel: /etc/letsencrypt/live/<Ihr Domänenname>/privkey.pem
Hinweis: Die oben genannten Speicherorte für diese Dateien sind zwar standardmässig vorgegeben, können aber mit Befehlszeilenargumenten oder einer Konfigurationsdatei überschrieben werden. Weitere Einzelheiten finden Sie in der Certbot-Dokumentation.
Die Zertifikatskette wird in diesem Dokument als $CERT_CHAIN und der private Schlüssel als $PRIV_KEY bezeichnet.
Sie benötigen auch das Root-CA-Zertifikat, um einen gültigen SSL-Schlüsselspeicher für Ignition zu erstellen, da die Let’s Encrypt-Zertifikatskette nur das Serverzertifikat und das zwischengeschaltete CA-Zertifikat enthält. Zum Zeitpunkt der Erstellung dieses Artikels verwendet Let’s Encrypt DST Root CA 1 als Root-CA-Zertifikat. Kopieren Sie den Inhalt in eine .pem-Datei an einem bekannten Ort auf Ihrem Server und nennen Sie sie in diesem Dokument $ROOT_CA_CERT.
Als Nächstes erstellen wir das vollständige Zertifikatsbündel vom Serverzertifikat über das Zwischenzertifikat bis hin zum Stammzertifikat. Zu diesem Zweck habe ich Folgendes ausgeführt:
cat $CERT_CHAIN $ROOT_CA_CERT > $CERT_BUNDLE
$CERT_BUNDLE ist der Speicherort der .pem-Datei des Zertifikatsbündels, das wir durch Verkettung des Root-CA-Zertifikats am Ende der Let’s Encrypt-Zertifikatskette erstellen möchten.
Schliesslich können wir den PKCS12-Schlüsselspeicher mit OpenSSL erstellen:
openssl pkcs12 \ -export \ -out $TEMP_KEYSTORE \ -inkey $PRIV_KEY \ -in $CERT_BUNDLE \ -passout pass:$KEYSTORE_PWD \ -name $KEYSTORE_ALIAS
$TEMP_KEYSTORE ist der Pfad zu einer temporären Schlüsselspeicherdatei, in die OpenSSL den neuen Schlüsselspeicher schreiben wird.
$PRIV_KEY und $CERT_BUNDLE wurden oben bereits erwähnt.
$KEYSTORE_PWD ist das Passwort, das den Schlüsselspeicher und den privaten Schlüssel schützt. Ignition verwendet standardmässig den Wert „ignition“. Hinweis: Es ist im Allgemeinen nicht ratsam, Klartext-Passwörter in einem Befehlszeilen-Argument zu übergeben. Konsultieren Sie die OpenSSL-Dokumentation für andere Optionen wie die Verwendung einer Umgebungsvariablen oder einer Datei, die das Passwort enthält.
$KEYSTORE_ALIAS ist der gut lesbare Name für den Schlüsselspeichereintrag. Ignition verwendet standardmässig den Wert „ignition“.
Kopieren des Schlüsselspeichers
Jetzt sollten Sie die PKCS12-Schlüsselspeicherdatei mit der intakten Zertifikatskette und dem privaten Schlüssel im Verzeichnis $TEMP_KEYSTORE haben.
Wenn Sie einen bestehenden SSL-Schlüsselspeicher haben, der vom Gateway verwendet wird, erstellen Sie als Nächstes ein Backup davon:
cp $IGNITION/webserver/ssl.pfx $IGNITION/webserver/ssl.pfx.bk
Kopieren Sie nun den neuen Schlüsselspeicher in Ignition:
cp $TEMP_KEYSTORE $IGNITION/webserver/ssl.pfx
Bereinigen Sie schliesslich die temporären Dateien:
rm $CERT_BUNDLE $TEMP_KEYSTORE
Hot-Reloading des Schlüsselspeichers
Zu diesem Zeitpunkt ist Ihr neues SSL-Zertifikat in einem neuen Schlüsselspeicher installiert, der sich in $IGNITION/webserver/ssl.pfx befindet. Nun ist es an der Zeit, dass Ignition mit der Verwendung des neuen Schlüsselspeichers beginnt:
$IGNITION/gwcmd.sh –reloadks
Wenn Sie Ihr Gateway jetzt über https aufrufen, sollten Sie das neue Zertifikat und ein Schloss oder einen grünen Balken sehen, der anzeigt, dass der Browser dem Gateway vertraut.
Automatisierte Erneuerung
SSL-Zertifikate haben eine bestimmte Gültigkeitsdauer, ähnlich wie ein Führerschein. Sobald ein SSL-Zertifikat abläuft, vertraut ein Webbrowser dem Zertifikat und dem Webserver, der es ausstellt, nicht mehr. Daher müssen Administratoren das SSL-Zertifikat ihres Webservers erneuern, bevor es abläuft. Insbesondere Let’s Encrypt-Zertifikate laufen nach etwa 90 Tagen ab dem Zeitpunkt ihrer Ausstellung ab.
Certbot kann mit dem Befehlszeilenargument -n nicht-interaktiv ausgeführt werden. Viele der Werte, die in der interaktiven Eingabeaufforderung eingegeben werden, können über das Kommandozeilenargument zur Automatisierung übergeben werden. Hier ist ein Beispiel:
certbot certonly \ --webroot --webroot-path $IGNITION --domains $DOMAIN --agree-tos --deploy-hook $DEPLOY_SCRIPT
Im obigen Befehl ist $IGNITION das Hauptinstallationsverzeichnis des Gateways. $DOMAIN ist der Name Ihrer Domain (z. B. example.com). $DEPLOY_SCRIPT ist der Pfad zu einem Skript, das ausgeführt werden kann, sobald das neue SSL-Zertifikat generiert ist.
Sie könnten dann ein Bash-Skript unter $DEPLOY_SCRIPT erstellen, das Folgendes tut:
$DEPLOY_SCRIPT
1 | #! /bin/bash |
2 | |
3 | # create cert chain bundle from server cert to root ca cert: |
4 | cat $CERT_CHAIN $ROOT_CA_CERT > $CERT_BUNDLE |
5 | # create the PKCS12 key store: |
6 | openssl pkcs12 -export -out $TEMP_KEYSTORE -inkey $PRIV_KEY -in $CERT_BUNDLE -passout pass:$KEYSTORE_PWD -name $KEYSTORE_ALIAS |
7 | # backup existing SSL key store if it exists: |
8 | [[ -f $IGNITION/webserver/ssl.pfx ]] && cp $IGNITION/webserver/ssl.pfx $IGNITION/webserver/ssl.pfx.bk |
9 | # copy the new SSL key store: |
10 | cp $TEMP_KEYSTORE $IGNITION/webserver/ssl.pfx |
11 | # clean up temp files: |
12 | rm $CERT_BUNDLE $TEMP_KEYSTORE |
13 | # hot-reload the new key store into the running Gateway: |
14 | $IGNITION/gwcmd.sh –reloadks |
Zum Schluss noch ein Beispiel für einen Cron-Job, der den Certbot-Befehl mit Deploy-Hook jeden Tag um 17:13 Uhr ausführt:
13 17 * * * certbot certonly --webroot --webroot-path $IGNITION --domains $DOMAIN --agree-tos --deploy-hook $DEPLOY_SCRIPT >> $RENEW_LOG
$RENEW_LOG ist der Speicherort einer Protokolldatei, in die die Ausgaben des Cron-Jobs geschrieben werden.
Weitere Informationen zu den Certbot-Befehlszeilenargumenten finden Sie in der Certbot-Dokumentation oder unter certbot –help all.
Schlussfolgerung
Ich hoffe, dass dieses Dokument den Benutzern eine Vorstellung davon vermittelt, wie sie ihre SSL-Zertifikatsverwaltung mit Let’s Encrypt und den neuen Funktionen in Ignition 8.0.3 automatisieren können. Der obige Ansatz ist nicht die einzige Möglichkeit, Ignition mit Let’s Encrypt zu integrieren, und er ist sicherlich nicht der „beste“ Weg, dies zu erreichen, aber er sollte den Prozess veranschaulichen, den jede Lösung durchlaufen muss, um unser Ziel zu erreichen.