Abbildung 1: Der Browser meldet, dass mit dem Let's-Encrypt-Zertifikat alles in Ordnung ist. Am 30. Mai läuft es aber ab.
Sysadmin-Kolumnist Charly Kühnast bricht eine Lanze für die kostenlosen SSL-Zertifikate von Let’s Encrypt. Insbesondere der zugehörige Softwareclient hat es ihm angetan, der von der Beschaffung der Zertifikate bis zum Einbinden in den Webserver alles erledigt.
Obwohl heute mehr Webserver TLS einsetzen als früher, scheuen Kleinbetriebe und Hobbyisten vor den Kosten und dem Verwaltungsaufwand zurück, die mit SSL-Zertifikaten einhergehen. Die Electronic Frontier Foundation, die Universität Michigan und die Mozilla-Stiftung sind Geburtshelfer eines Projekts, das an beiden neuralgischen Punkten ansetzt.
Zum einen verteilt Let’s Encrypt [1] SSL-Zertifikate kostenlos. Zum anderen, und hier punktet das Projekt gegenüber allen anderen Kostenlosangeboten, liefert es eine in Python geschriebene Clientsoftware. Sie sorgt im Alleingang fürs Erstellen, Validieren, Signieren und rechtzeitige Erneuen von Zertifikaten und geht dem Admin sogar beim Einbinden der Zertifikate in Serverdienste zur Hand.
Für Debian und davon abgeleitete Distributionen gibt es fertige Pakete. Wer selbst Hand anlegen muss oder möchte, besorgt sich den Let’s-Encrypt- Client mit dem Befehl
git clone https://github.com/letsencrypt/letsencrypt
von Github. Im Verzeichnis »letsencrypt« finde ich nun das Tool »letsencrypt-auto« . Um damit ein Zertifikat für meine Beispieldomäne »mydomain.com« zu erzeugen, genügt das Kommando:
sudo ./letsencrypt-auto certonly --standalone -d mydomain.com
»certonly« erzeugt das Zertifikat, baut es aber nicht automatisch in die Webserver-Konfiguration ein. Das mache ich lieber selbst, denn dieser Teil der Software ist noch im Betastadium und funktioniert recht ordentlich nur für Apaches, an deren Konfiguration bislang kein Admin eine Feder gekrümmt hat.
Der Parameter »–standalone« startet einen Webserver zum Validieren – einer der Gründe, warum das Tool Rootrechte benötigt. »letsencrypt-auto« stoppt also den laufenden Webserver kurz, erst nach getaner SSL-Prüfarbeit darf der Server dann weitermachen wie gehabt.
In den Webserver einbinden
Die erzeugten Zertifikate »cert.pem« , »chain.pem« sowie »fullchain.pem« , das die beiden vorgenannten kombiniert, und der private Schlüssel »privkey.pem« landen im Verzeichnis »/etc/letsencrypt/live/mydomain.com/« . Beim Einbinden in einen Apache-Webserver muss ich auf dessen Versionsnummer achten, Listing 1 nennt die jeweiligen Direktiven.
Um die Zertifikate, die nur 90 Tage gültig sind (Abbildung 1), automatisch zu erneuern, reicht es, »letsencrypt-auto« mit dem Parameter »renew« innerhalb dieses Zeitraums aufzurufen. (jk)
Abbildung 1: Der Browser meldet, dass mit dem Let’s-Encrypt-Zertifikat alles in Ordnung ist. Am 30. Mai läuft es aber ab.
Listing 1
Zertifikate einbinden
01 # Apache 2.4.8 und neuer: 02 SSLCertificateFile /etc/letsencrypt/live/mydomain.com/fullchain.pem 03 SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.com/privkey.pem 04 05 # Aelter als Apache 2.4.8: 06 SSLCertificateFile /etc/letsencrypt/live/mydomain.com/cert.pem 07 SSLCertificateChainFile /etc/letsencrypt/live/mydomain.com/chain.pem 08 SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.com/privkey.pem 09 10 # Nginx: 11 ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem; 12 ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem;
Infos
- Let’s Encrypt: https://letsencrypt.org
Der Autor
Charly Kühnast administriert Unix-Systeme im Rechenzentrum Niederrhein. Zu seinen Aufgaben gehören Sicherheit und Verfügbarkeit der Firewalls und der DMZ.
