Ich habe meinen Beitrag zum Sammeln von Let’s Encrypt-Domainbestätigungen um einen Abschnitt erweitert: Mit einer einfachen Weiterleitung auf eine spezielle Subdomain kann man nicht nur alle Subdomains zusammenfassen, sondern auch alle Hosts. Setzt man mehrere Subdomains auf mehreren Hosts ein, ist es ganz praktisch, seine Bestätigungsdateien immer nur noch in einem Verzeichnis auf einem Hosts zu erstellen. Das erspart einem zwar leider auch nicht das Erstellen dieser Dateien, aber immerhin muss man dazu nicht auch noch auf sämtlichen Hosts eingeloggt sein.
Let’s Encrypt Domainbestätigungen von Hosts sammeln
Let’s Encrypt ACME Challenge Responses sammeln [Nginx]
Im Manual Mode des Let’s Encrypt Referenzclients muss jede Domain über eine individuelle Datei im Unterverzeichnis /.well-known/acme-challenge/ derselben Domain bestätigt werden. Bei vielen Domains bremst das Wechseln zwischen den Verzeichnissen und das erstellen der notwendigen Verzeichnisstruktur den Arbeitsablauf. Damit die Domains schneller bestätigt werden können, sammle ich alle ACME Responses in einem gemeinsamen Verzeichnis /var/www/acme-challenges/. Egal, welche Domain gerade bestätigt werden soll: Die Datei zur Bestätigung wird hier abgelegt und steht dennoch unter der gewohnten URL bereit. Und so geht’s:
Let’s Encrypt Zertifikate mit Public Key Pinning und DANE
In mindestens zwei Anwendungsfällen ist die geringe Laufzeit von Let’s Encrypt Zertifikaten lästig: Bei der Nutzung von HPKP (Public Key Pinning) und DANE. Beide Verfahren sollen HTTPS-Verbindungen zusätzlich absichern, indem genau spezifiziert wird, welche TLS-Zertifikate für eine Domain gültig sein sollen. Da mindestens alle 90 Tage ein anderes Let’s Encrypt -Zertifikat eingerichtet werden muss, müssen in diesem Zyklus auch die HPKP- und DANE-Einstellungen mehr oder weniger aufwendig aktualisiert werden.
Der Aufwand lässt sich jedoch mit einem Trick reduzieren: Da beide Verfahren auf der Untersuchung des Public Keys im öffentlichen Zertifikat beruhen, kann man dafür sorgen, dass sich dieser bei der Umstellung auf ein neues Zertifikat nichts ändert. Man verwendet daher bei der Beantragung eines neuen LE-Zertifikats also keinen neuen Private Key, sondern einen alten. (Der Public Key basiert auf dem Private Key). Um einen alten Key nutzen zu können, muss der Referenzclient von Let’s Encrypt im Zusammenspiel mit einem eigenen, gleich bleibenden Private Key und einer eigenen Zertifikatsanfrage (CSR) verwendet werden.
Let’s Encrypt Zertifikate im Manual Mode abholen
Let’s Encrypt ist auf das automatische Abholen und Einrichten von TLS-Zertifikaten ausgelegt. Für Anwender, die mehr Kontrolle über den Prozess haben wollen, gibt es aber auch einen „Manual Mode“, der folgende Vorteile hat:
- Die Zertifikate können von jedem Rechner aus abgeholt werden (Der LE Client muss nicht auf dem Zielserver laufen)
- Der Webserver muss nicht wegen des LE Clients kurzzeitig abgeschaltet werden.
Und so funktioniert’s: Auf von einem beliebigen Rechner aus kann mit dem Let’s Encrypt ACME Client eine Zertifikatsanfrage abgeschickt werden. Zur Bestätigung des Domainbesitzes müssen in einem bestimmten Unterverzeichnis des Ziel-Webservers (Domain-Ziel) Dateien mit einem bestimmten Inhalt hinterlegt werden (=> Challenge-Dateien). Der ACME Server überprüft daraufhin, ob die Dateien unter den jeweiligen Domains erreichbar sind und der Inhalt korrekt ist. Wenn das der Fall ist, ist der Domainbesitz bestätigt und die Zertifikate werden ausgehändigt.
Anleitung für Let’s Encrypt: Kostenlose TLS Zertifikate für alle
Das Let’s Encrypt Projekt (hinter dem unter anderem Mozilla, Facebook und Cisco als Sponsoren stecken) ist gestern in den Public Beta Betrieb übergegangen. Von nun an können nach belieben kostenlose TLS (aka SSL)-Zertifikate für die eigenen Domains erstellt werden. Für den Erhalt eines Zertifikats sind nur wenige, einfache Schritte erforderlich, die ich im Folgenden erkläre:
Eine eigene OpenSSL CA erstellen und Zertifikate ausstellen
OpenSSL bringt umfassende Werkzeuge mit, um eine eigene, kleine Certificate Authority (CA) betreiben zu können. Die Nutzung einer eigenen CA ist besonders dann sinnvoll, wenn mehrere Dienste über SSL/TLS kostenlos abgesichert werden sollen. Neben dem Nachteil, dass die eigene CA vor Benutzung zuerst auf den Clientrechnern bekannt gemacht werden muss, gibt es aber auch einen Vorteil: Mit einer CA unter der eigenen Kontrolle ist man im Zweifel auf der sicheren Seite: In den letzten Jahren wurden immer wieder Fälle bekannt, in denen große Certificate Authorities falsche Zertifikate ausgestellt haben. Es gibt Grund genug, die Vertrauenswürdigkeit großer CAs anzuzweifeln.
Mit dieser Anleitung werdet ihr in der Lage sein, beliebig viele Zertifikate für eure Dienste ausstellen zu können, die in jedem Browser als gültig erkannt werden, sofern vorher das Root-Zertifikat eurer CA importiert wurde.
Apache Reverse Proxy (auch mit SSL Support zum Zielserver) einrichten
Ein Apache Webserver kann durch wenige Zeilen zusätzlicher Konfiguration als Proxy vor einem anderen Webserver dienen. Das kann man sich z.B. bei Serverumzügen zunutze machen. Solange die neue Server-IP zu einer Domain noch nicht durch das DNS an alle Clients verteilt wurde, kann man die Besucher einfach am alten Server abfangen und den Server anweisen, die Webseiten aber vom neuen Server abzuholen und sie den Besuchern dann zu präsentieren. Der alte Webserver gibt die Dokumente dann nicht mehr direkt an den Besucher aus, sondern ist nur noch die Vermittlungsstelle zwischen dem Benutzer und dem neuen Server.
Apache2: SSL-verschlüsselte Verbindungen ermöglichen (Ubuntu 14.04)
Seit dem Bekanntwerden der flächendeckenden, verdachtslosen Überwachung durch die NSA und andere Geheimdienste gewinnt Verschlüsselung im Internet an Bedeutung. Vor allem die Kommunikation zwischen Browser und Webserver wird verstärkt gesichert, um privates privat zu halten. Eine solche SSL-Verschlüsselung kann auch für den eigenen Apache Server eingerichtet werden. Benötigt wird dafür das Apache Modul „ssl“: