Seit einiger Zeit gibt es die Möglichkeit, über das Projekt Let's Encrypt kostenlose SSL/TLS-Zertifikate zu erstellen.
Ich wollte das unbedingt ausprobieren und erfuhr, dass der Weg dorthin recht steinig ist. D.h. auch wenn es im Internet ausreichend Anleitungen gibt, sind diese teilweise nicht sehr gut verständlich oder auch unvollständig.
Daher will ich hier den Versuch wagen, mein eigenes Vorgehen zu dokumentieren.
Ich hatte bereits eine installierte Version von Fedora 23 in einer Virtual Machine (VM) von VirtualBox (Version 5.1.12). Dabei hatte ich schon seit längerem das Problem, dass die Guest Additions nicht installiert werden können. Ohne die gibt es aber keine gemeinsame Zwischenablage (Copy/Paste zwischen Host und Guest) und keine gemeinsamen Ordner. Beides hätte ich gern für o.g. Zertifikate.
Zuerst also dieses Problem, was schwierig zu lösen war. Mein Kernel ist ein sogen. PAE-Kernel (PAE = Physical Address Extension, PAE wird wohl automatisch aktiviert bei 32-Bit-Versionen wie bei meinem Fedora innerhalb einer VM). Wichtig für die Installation der Guest Additions ist das exakte Übereinstimmen des Kernel und seiner Quellen. Man muss also ausführen:
Kernel, Kernel-Header, Kernel-Quellen aktualisieren und danach neu starten:
sudo dnf upgrade kernel*
Oder auch (und danach neu starten):
Fedora: sudo dnf upgrade --allowerasing
Debian: sudo apt-get update
sudo apt-get upgrade
Weitere nötige Pakete installieren (für PAE-Kernel "kernel-PAE-devel", für normalen Kernel "kernel-devel"):
Fedora: sudo dnf install gcc kernel-PAE-devel kernel-headers dkms make patch bzip2 perl
Debian: sudo apt-get install gcc dkms make patch bzip2 perl
su -c 'm-a prepare'
Systemvariable KERN_DIR auf den aktuellen Kernel setzen:
KERN_DIR=/usr/src/kernels/`uname -r`
Guest Additions-ISO-Datei mounten, in das gemountete Verzeichnis wechseln und danach die Installation starten:
sudo ./VBoxLinuxAdditions.run
Let's Encrypt installieren:
Fedora: sudo dnf install letsencrypt
Debian: sudo apt-get install letsencrypt
Danach hat man ein voll funktionierendes Gastsystem.
Das Ganze funktioniert auch direkt unter Windows 10 und dem dort integrierten (aber ziemlich gut versteckten) Linux-Subsystem (aktuell Ubuntu 16.04). Dieses Subsystem muss aber erst aktiviert und aktualisiert werden. Dies geht unter den Windows 10, Versionen bis 1909 (WSL1) wie folgt (so durchgeführt unter Version 1710):
Das Filesystem für das Linux-Subsystem liegt übrigens unter <userverzeichnis>\AppData\Local\lxss\rootfs.
Ab Windows 10, Version 2004 gibt es ein neues Subsystem namens WSL2 und mit diesen aktuelleren Versionen geht man so vor (Dokumentation bei Microsoft):
Jetzt kommt die eigentliche Arbeit bzgl. des Zertifikats. Dabei wählen wir den "Manual Mode", d.h. wir erzeugen die Zertifikate nicht direkt auf dem Webserver, sondern zuhause und transferieren die Zertifikate nachträglich auf den Webserver.
Mit der Funktion "certbot" von Let's Encrypt starten wir den Prozess im Textmodus und geben einige Parameter mit bzgl. Kontakt-e-Mail, die zu verschlüsselnden Domains (mehrere Domains mit Kommata getrennt), erweiterte Schlüsselgröße 4096 (anstatt Standard 2048), Einverständnis mit den Terms of Service (TOS) und vor allem dem wichtigen "Manual Mode":
certbot --text --email mailto:kontakt@beispiel.de --domains www.beispiel.de,beispiel.de --rsa-key-size 4096 --agree-tos --renew-by-default --manual --preferred-challenges http --manual-public-ip-logging-ok certonly
Nach diesem Start muss man nun genau lesen, welche weiteren Anweisungen es gibt.
Danach kommt der wirklich komplizierte Teil. Hier wird nun für jede Domain jeweils eine sogenannte "challenge" erzeugt, um zu prüfen, ob man Zugriff auf die Domain hat und es wird damit später eine Zuordnung durchgeführt. Dazu muss man bei der hier gewählten HTTP-Methode bestimmte Dateien auf den Webserver hochladen und dann jeweils den Prozess fortsetzen.
Konkret heißt das, dass man auf dem Webserver ein Verzeichnis ".well-known/acme-challenge" (führenden "." beachten!) erstellen muss. Dort hinein muss man dann während des Prozesses für jede Domain jeweils eine Datei mit einem bestimmten Inhalt kopieren, wobei der Dateiname und der Inhalt der Datei jeweils von dem Prozess vorgegeben wird. Der Inhalt besteht aus dem Dateinamen nochmal und einer weiteren Zeichenfolge. Es sind jeweils lange komplizierte Zeichenfolgen.
Ich erledigte die ganze Prozedur so, dass ich via Copy/Paste (nur Mausbediennung, keinesfalls(!) irgendwelche Tasten drücken, sonst greift man in den Funktionsablauf der Zertifikatserzeugung ein!) die jeweiligen Dateinamen und den jeweiligen Dateiinhalt auf den VM-Host übertrug und von dort via FTP auf den Webserver schrieb. Dies für jede Domain schrittweise, d.h. Datei+Inhalt erzeugen, via FTP hochladen, ENTER drücken und das Ganze für die nächste Domain wiederholen.
Die Textdateien kodierte ich als UNIX-Text und übertrug vorsichtshalber im binären FTP-Übertragungsmodus.
Jedes Mal, wenn ich die jeweilige Datei übertragen hatte, bestätigte ich dies mit ENTER und die nächste Challenge wurde erzeugt und ich konnte die nächste Datei erzeugen und übertragen.
Eine dazu alternative Methode funktioniert via DNS und man muss anstatt der hochzuladenden Dateien in der Domainkonfiguration für jede Domain einen TXT-Eintrag (TXT-Record) erstellen. Der Eintrag beinhaltet die jeweilige Challenge und verweist auf die jeweilige Domain, wobei dem Domainnnamen ein "_acme-challenge." vorangestellt ist. Bei mir funktionierte das gut und hatte (zumindest bei mir) den Vorteil, dass ich die Challenges nicht jedes Mal neu erstellen musste. Denn diese bleiben jeweils gleich. Nachteil der Methode ist, dass nicht jeder technisch bzw. von den Möglichkeiten des Providers her in der Lage ist, entsprechende TXT-Einträge anlegen zu dürfen. Das Kommando lautet also:
certbot --text --email mailto:kontakt@beispiel.de --domains www.beispiel.de,beispiel.de --rsa-key-size 4096 --agree-tos --renew-by-default --manual --preferred-challenges dns --manual-public-ip-logging-ok certonly
Zum Schluss prüft nun certbot, ob alle vorgegebenen Challenges jeweils den erstellten bzw. hochgeladenen Challenges auf dem Webserver oder in einer DNS-Abfrage entsprechen. Wenn alle Challenges geprüft worden sind, wird im Verzeichnis /etc/letsencrypt/live oder auch /etc/letsencrypt/archive das Zertifikat erstellt. Es besteht aus mehreren Dateien:
Ich verwendete zum Einbinden beim meinem Provider nur die letzten beiden Dateien und hatte damit Erfolg, wie eine Prüfung beim SSL Checker ergab.
Das Zertifkat ist nur 90 Tage lang gültig. Mit der nun vorhandenen Infrastruktur im Guest sollte es nicht schwer sein, dass Zertifikat zu erneuern und auf dem Webserver zu ersetzen. Ich habe dabei die Erfahrung gemacht, dass es am einfachsten ist, das Zertifikat mit dem o.g. langen Kommando "neu" zu erzeugen und auch neue "challenges" auf den Webserver hochzuladen. Andere spezielle "renew"-Kommandos sind vor allem dafür geeignet, wenn auf demselben System auch der Webserver läuft. Bei mir mit dem vorherigen "certonly" hat das nicht funktioniert.
Eine weitere sinnvolle Beschreibung: LetsEncrypt now available in Fedora By James Hogarth