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“.

Lets Encrypt WP-Loft

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

Wir funktioniert Let’s Encrypt ?

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 so aussehen:

cd /opt/letsencrypt
./letsencrypt-auto --help

Aber halt! Ä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 lautet wir folgt:

 ./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

Hierfür lautet der Aufruf auf der Konsole:

 ./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.

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.

Welche Erfahrungen haben Sie / hast Du mit Let’s Encrypt schon gemacht ?

8 Kommentare
  1. Martin
    Martin says:

    Die Laufzeit soll in voller Ausbaustufe 30 statt derzeit 90 Tage betragen. Von mir aus lieber nur 7 Tage. Es ist ja explizit mit dem Ziel der Automatisierung gebaut.

    Antworten
    • Martin Wolfert
      Martin Wolfert says:

      Hallo Martin,
      wie gesagt: wenn man das scriptet ist die Laufzeit der Zertifikate wirklich untergeordnet. Man(n) ist halt von den „normalen“ Zertifikats-Laufzeiten andere Dimensionen gewöhnt.
      Grüße,
      Martin

  2. Anders Henke
    Anders Henke says:

    Die Zertifikatslaufzeit hat zwei-drei wichtige Aspekte: zum einen sollte man sich damit beschäftigen, ob die Verfahren (Verschlüsselung, Hashing, Keylänge, …) noch auf „Stand der Technik sind“, zum anderen sollte es auch dazu anhalten, „erneut“ die signierten Informationen zu validieren.

    Wie bei einem Ausweisdokument auch ist ein Zertifikat ein Versprechen der CA, die Informationen seien (wenn nichts dazwischen kommt) bis zu einem Zeitpunkt in der Zukunft korrekt. Rein sachlich ist das natürlich Unsinn: ich kann nicht versprechen, dass eine Information in (ferner) Zukunft noch korrekt sein wird, genausowenig kann ich davon ausgehen, ein Verschlüsselungsverfahren, eingesetzte Hashverfahren, Keylängen oder Keys seien noch in x Jahren „auf Stand der Technik“.

    Genau hier setzte jahrelange Lobbyarbeit an, um die Laufzeit „normaler“ Zertifikate auf 36(+3) Monate zu begrenzen. Gefühlt würden einige Anbieter würden am liebsten ihren Kunden 5- oder gar 10-Jahres-Zertifikate verkaufen.
    Gleichzeitig gibt es Anwendungsszenarien, in denen nur wenige Stunden oder Tage gültige Zertifikate gewünscht sind (und nebenbei spart man sich so auch die lästigen Revocation Lists bzw. OCSP-Responder) – ohne Automatisierung ist da nichts zu machen.

    In diesem Zusammenhang stehen dann auch letztlich OV/EV-Zertifikate sowie Zertifikate für Verwendungszweck jenseits von tls_server (z.B. Codesigning oder S/MIME). Bei DV-Zertifikaten bestätigt die CA nur, dass der im Zertifikat enthaltene Pubkey zum im Zertifikate genannten Domainnamen passt. Diese Information ist technisch einfach automatisiert validierbar – und genau das machen auch Let’s Encrypt sowie andere CAs bei DV-Zertifikaten.

    Bei OV-Zertifikaten wird auch die Identität der Organisation (keine Einzelpersonen!) geprüft, bei EV-Zertifikaten zusätzlich, ob der Antragsteller auch innerhalb der benannten Organisation berechtigt ist, das Zertifikat zu beauftragen und zu erhalten.

    Faktisch ist diese OV/EV-Prüfung ein streng manueller Prozess, bei dem aus einem Fundus möglicher hinreichend vertrauenswürdiger, irgendwie offizieller Dokumente (je nach Land geht das vom notariell beglaubigten Handelsregisterauszug bis hin zu einer aktuellen Stromrechnung) jemand bei der CA manuell prüft, ob diese Informationen sic mit denen des Antragstellers decken.

    Die erweiterte Prüfung bei EV-Zertifikaten geht dann eher in Richtung „Briefpapier hinfaxen, auf dem neben dem Firmennamen auch ein Geschäftsführer oder Vorstand bestätigt, dass du das Zertifikat auf den Namen xyz. bestellen darfst“ (woher weiss die CA, dass es sich um den Geschäftsführer oder Vorstand handelt: diese Information sollte möglichst in der Fußzeile vom Briefpapier zu stehen… mehr kann einige CA-Anbieter überfordern).
    Derartige manuelle Tasks wie bei OV/EV widersprechen komplett dem „komplett automatisiert“-Ansatz von Let’s Encrypt und sind auch vom Let’s-Encrypt-Team nicht zu leisten.

    EV-Zertifikate haben auch noch eine Reihe weiterer Einschränkungen (z.B. dürfen keine Wildcard-EV-Zertifikate ausgestellt werden), was ihren Einsatzbereich nicht immer gerade erweitert – vor der Forderung also bitte genau prüfen, ob das wirklich etwas ist, was dir einen Vorteil bringt. Bereits jetzt wird von einigen Seiten „gemault“, warum Let’s Encrypt denn keine Wildcard-DV-Zertifikate unterstützt… das werden dann auch die ersten sein, die Wildcard-EVs haben wollen :-)

    Interessant fände ich noch personalisierte Zertifikate für die Nutzung als Client- oder S/MIME-Zertifikat. Die für S/MIME relevanten E-Mail-Adressen könnte man per Validierungsmail prüfen, der Rest vom Zertifikat (insbesondere Angaben zur Person) müssten (analog zu DV-Zertifikaten) vermutlich erst einmal leer bleiben. Sofern jemand diese Validierung schreiben würde, sollte so etwas relativ einfach bereits heute umsetzbar sein.

    Und falls es mal einen internationalen Standard oder Anbieter zur automatisierten Prüfung elektronischer Ausweisdokumente geben sollte, könnte man darauf aufbauend dann auch S/MIME-Zertifikate personalisieren und um Inhaberinformationen (Name, Adresse, Ort) ergänzen: der erste Schritt in Richtung OV-Zertifikate.
    Bis es soweit ist und auch die Baseline Requirements des CA/Browser-Forums (die den „gemeinsamen Nenner“ der Anforderungen an CAs definiert) daran angepasst sind, dürfte allerdings noch einige Zeit vergehen.

    Ach so, noch der dritte, nicht unwichtige Aspekt bei der Zertifikatslaufzeit: die Laufzeit sollte die Verlängerungsintervalle mit abbilden. Wenn ein manuelles Prüfverfahren also z.B. 2 Wochen braucht und das Zertifikat-Ausrollen einen Tag, man noch arbeitsfreie Wochenenden, Feiertage, Brückentage, etc. mit einrechnet, sollte man das „Folgezertifikat“ mindestens 3 Wochen „vor“ Ablauf des aktuellen Zertifikats beauftragen. Und aus Sicht der CA sollte der Nutzer auch Zeit einplanen, in der die CA vielleicht nicht verfügbar ist – also noch einmal 1-2 Wochen extra Reservepuffer, nach denen der Nutzer „im Notfall“ dann doch auf das Angebot einer anderen CA eingehen und das Zertifikat „dort“ bestellen kann.

    Bei „regulären“ (kommerziellen) CAs kann man in der Regel auch bis zu 3 Monate an „Restlaufzeit“ des alten Zertifikats anrechnen lassen – damit einem durch die operativ sinnvolle Maßnahme kein finanzieller Schaden entsteht. Bei Let’s Encrypt entsteht durch „vorzeitige Verlängerung“ kein finanzieller Schaden, aber dennoch ist man gut beraten, seine Zertifikate 4 Wochen „vor Ablauf“ zu verlängern (und wenn dann das automatische Verlängern bis 2 Wochen vor Ablauf nicht funktioniert hat, sollte das eigene Monitoringsystem einen Alarm werfen).

    Antworten
    • Martin Wolfert
      Martin Wolfert says:

      Hallo Anders,
      vielen Dank für deinen sehr lebendigen und auch echt langen Kommentar; immerhin 16 Worte länger als der eigentliche Post.
      Ehrlicherweise habe ich mir an für meinen Blogpost absichtlich den „Anwender-Hut“ aufgesetzt.
      Daher ist Dein Beitrag mehr als nur eine Ergänzung.

      Martin

  3. Tim
    Tim says:

    Ich finde es nicht schlimm, dass Let’s Encrypt nur „einfache“ Zertifikate anbietet. Immerhin ist der Hauptgrund für dieses „Projekt“ ja, dass möglichst ALLE Webseiten über HTTPS aufrufbar sind und verschlüsseln. Dafür brauchte es aber einen automatisierten Weg, der aber auch sicher ist. Und genau das hat Lets Encrypt ja geschafft: Immer mehr Webhoster und sogar Plattformen wie WordPress.com bauen Lets Encrypt ein und sorgen so dafür, dass allein so tausende oder sogar Millionen Webseiten nun automatisch verschlüsselt aufrufbar sind.

    Zudem ist das automatisieren von diesem Prozess auch ein Gewinn an Sicherheit. So können die Zertifikate eben auch einfach nur 1-2 Wochen gültig sein, weil man nichts per Hand dauernd austauschen muss. Wird dann ein Zertifikat gestohlen, ist es nicht so schlimm, wie wenn ein 2 Jahre gültiges Zertifikat gestohlen wird. Und das mit dem Zertifikate für ungültig erklären funktioniert auch nicht so wirklich gut.. Deswegen ist es, wie Lets Encrypt es macht, auch aus Sicherheitsgründen sehr gut, wie ich finde.

    Man muss sich als Admin eben umgewöhnen, dass man da nicht mehr selbst Hand anlegen muss und es im Normalfall alles automatisiert läuft :D

    Antworten
    • Martin Wolfert
      Martin Wolfert says:

      Hallo Tim,

      danke für deinen Kommentar. Für mich ist Letsencrypt kein Versprechen, ob eine Web-Seite die ein SSL-Zertifikat von Letsencrypt verwendet, auch wirklich „überprüft sicher“ ist.
      Für mich dienen die Zertifikate von Letsenrypt in erster Linie mal um HTTP2 auf allen meinen Blogs und Domains anbieten zu können ohne mich dafür in den finanziellen Ruin zu treiben.
      Einen Shop z.B. würde ich aktuell never ever mit einem Letsencrypt-Zertifikat online stellen.

  4. Keno
    Keno says:

    Moin Martin,

    danke für Deinen kurzen Bericht, bei dem ich nur wenige Worte verstehe :-).
    Aber egal:
    Ich habe heute LE auf zwei meiner Domains eingerichtet. Mein Hoster WebGo hat diesen Service kostenlos zur Verfügung gestellt und ich wollte es ausprobieren.
    Ich hatte mir dann die Seite von LE angesehen und viele Großkonzerne, wie auch Facebook als Sponsor entdeckt. Kann man da LE noch vertrauen?

    Hast Du Erfahrungen damit, ob sich das Zertifikat von LE ebenfalls positiv auf das Google Ranking auswirken oder muss man dafür dann doch in die Tasche greifen?

    Danke im Voraus und schöne Grüße aus dem Norden!
    Keno

    Antworten
    • Martin Wolfert
      Martin Wolfert says:

      Moin Keno,
      ob man Letsencrypt vertrauen kann? Ich denke schon. Es gibt ja ausser Facebook noch andere gewichtige Sponsoren, denen man vertrauen kann.
      Wenn man dem vertraut … :) … was man über den aktuellen Google Algorythmus weiss, dann werden Seiten die mit SSL/TLS laufen sicherlich höher gerankt als unverschlüsselte Seiten.
      Ob Google noch Diversifizierungen ab dem benutzten Zertifikat macht weiß ich nicht.

      Grüße,
      Martin

Was denkst du darüber?

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.