Meine praktischen Erfahrungen mit Let’s Encrypt
Anfang diesen Jahres wurde ich zum ersten Mal auf Let’s Enrcypt aufmerksam. Mit großem Interesse habe ich die Thematik verfolgt, und mich schlussendlich für den geschlossenen Betatest vor einigen Wochen angemeldet.
Inzwischen habe ich einige meiner Domains bereits mit Let’s Enrcypt Zertifikaten erfolgreich versehen, und möchte meine bisherigen Erfahrungen hier gerne mitteilen. Meine Eindrücke, soweit greife ich an dieser Stelle einfach mal vor, sind „positiv gemischt“.
1. Wer oder was verbirgt sich hinter Let’s Encrypt?
Die Story ist schnell erzählt: Let’s Encrypt ist eine freie, automatisierte und offene SSL-Zertifikat-Authority, die von der Internet Security Research Group (ISRG) angeboten wird.
Dahinter verbergen sich die folgenden Grundsätze:
- Frei: Jeder, der eine Domain besitzt kann Let’s Encrypt verwenden, um ein sicheres und kostenloses Zertifikat zu bekommen
- Automatisch: Die Software von Let’s Encrypt läuft auf einem Webserver. Sie interagiert einfach und sicher mit Let’s Encrypt, Zertifikate können automatisch erneuert werden
- Sicher: Let’s Encrypt bietet eine moderne Platform an, die den aktuellen TLS Standards entspricht.
- Transparent: Jedes ausgestellte, oder widerrufene Zertifikat kann öffentlich für jedermann eingesehen werden
- Open: Der automatisierte Ausstellungs- und Widerrufprozeß wird ebenso nach dem OpenSource-Standard veröffentlicht, wie die Software selbst
- Kooperativ: Let’s Encrypt ist eine offene Community, die frei von organisatorischen Zwängen, lediglich den angewendeten, standardisierten Interetprotokollen unterliegt
2. Wie binde ich Let’s Encrypt ein?
Let’s Enrcypt bietet einen Client an, die auf der Linux Konsole funktioniert. Dieser kann via Git heruntergeladen werden:
cd /opt && git clone https://github.com/letsencrypt/letsencrypt
Erste Schritte mit dem Let’s Encrypt Client können z.B. so aussehen:
cd /opt/letsencrypt ./letsencrypt-auto --help
Ähm Jungs von Let’s Encrypt: dabei wird Python und auch eine Menge an abhängigen Paketen auf meinem Linux-Server installiert.
Vor allem: egal ob auf CentOS oder Debian/Ubuntu Derivaten, es wird offensichtlich mit dem Flag „-y“ installiert. Sprich, ich als Admin werde nicht mal gefragt, alle erforderlichen Python- und abhängigen Pakete werden einfach installiert.
Ich möchte das, nett formuliert, als „Epic-Fail“ bezeichnen.
Dafür gibts schon gleich einen echt fetten Minuspunkt.
So weit so gut, Zertifikate kann man nun auf mehreren Wegen von Let’s Encyrpt beziehen: „Standalone“ und „Webroot-Plugin“.
Let’s Encrypt erklärt hier die Funktionsweise im Detail.
1. Die Standalone-Methode
Der Aufruf auf der Konsole hierfür lautet wir folgt:
cd /opt/letsencrypt ./letsencrypt-auto certonly --standalone -d example.com -d www.example.com
Let’s Encrypt weist im HowTo bei dieser Methode explizit darauf hin, dass man seinen Webserver hierzu kurz stoppen muss.
Das bedeutet im Umkehrschluß, dass der Let’s Encrypt-Client – während der Erstellung der Zertifikate – selbst eine Art Webserver einen Dienst startet, der auf den Standard-Ports 80 und 443 läuft.
Das ist auf einem Server, auf dem bereits ein Webserver läuft irgendwie ein wenig ungeschickt.
Und: Jo, das kann man schon so machen!
Aber: will man seinen Webserver „einfach mal so“ stoppen und wieder neu starten, oder das Ganze gar in ein Script und einen Cronjob packen?
Meine Meinung dazu lautet: Nein, das will man nicht.
Die Zertifikate werden, nach erfolgreichem Lauf, unter /etc/letsencrypt/live/example.com abgelegt, bzw. Symlinks nach /etc/letsencrypt/archive angelegt.
2. Die Webroot-Plugin Methode
cd /opt/letsencrypt ./letsencrypt-auto certonly --webroot -w /var/www/example -d example.com -d www.example.com
Der Let’s Encrypt-Client legt bei dieser Methode im Webroot der Domain example.com unter /var/www/example/ einen Ordnersrtuktur an: .well-known/acme-challenge.
Dort wird lokal ein „Challenge-File“ angelegt, welches der Let’s Encrypt-Client durch eine HTTP/HTTPS Abfrage auf http(s)://(www).example.com/.well-known/acme-challenge/ abruft. Das Challenge File wird nach der Erstellung der Zertifikate wieder gelöscht.
Den Webserver muss man bei dieser Methode nicht stoppen!
Hübsch: das funktioniert, das kann man auch scripten und in einen Cronjob packen. Thumbs Up!
Auch hier werden die Zertifikate, nach erfolgreichem Lauf, unter /etc/letsencrypt/live/example.com abgelegt, bzw. Symlinks nach /etc/letsencrypt/archive angelegt.
Nachdem die Zertifikate nun lokal unter /etc/letsenrcypt/live/example.com liegen muss man diese nur noch händisch in die jeweilige Webserver-Konfiguration einspielen.
Ich habe mich dazu entschieden diesen Pfad direkt in meinem Nginx-Sever einzubauen.
In einem nächsten Schritt werde ich noch ein wenig scripten, um die Aktualisierung der Zertifikate so weit wie für mich nötig, zu automatisieren.
3. Let’s Encrypt – meine Conclusio
Grundsätzlich finde ich Let’s Enrcypt eine echt coole Sache.
Webseitenbetreiber die bisher die Kosten für ein SSL-Zertifikat gescheut haben, vor allem wenn Sie diese für mehrere Domains benötigen, werden sich sicherlich schnell mit dem Angebot von Let’s Enrcypt anfreunden.
Leider gibt es auch einige negative Punkte:
- Es gibt keine „Organisation-Validated“ und „Extended-Validated“ SSL-Zertifikate
- Die Zertifikate haben (bisher) leider nur eine Laufzeit von neunzig Tagen
- Der Let’s Encrypt-Client setzt zwingend Python und davon abhängige Pakete voraus
Eine meiner Seiten, die mit einem Let’s Encrypt-Zertifikat läuft ist meine 365 Tage Fotoprojektseite.
