Mit Let’s Encrypt zum HTTPS-Zertifikat für den virtuellen Server

Bis vor wenigen Monaten war der Erwerb eines sicheren (d.h. grünen HTTPS-Zertifikats) noch eine teure Angelegenheit. Privatpersonen oder kleinere Firmen scheuten die Investition von mindestens 100 € pro Jahr und Domain und gaben sich mit dem ungesicherten http oder einem selbst signierten Zertifikat zufrieden. Doch seit dem 12. April 2016 ist dieser Zustand nun vorbei. Mit Hilfe von Let’s Encrypt kann sich nun jeder ein sicheres Zertifikat für seine Domains und auch Subdomains besorgen.

In diesem Artikel wollen wir ein paar Hintergründe zu Let’s Encrypt liefern und am Ende zeigen, wie Beantragung und Verlängerung von Let’s Encrypt-Zertifikaten unter Ubuntu funktioniert. Wir werden dabei auf das offizielle Tool certbot und die Authorisierungsmethode standalone von Let’s encrypt eingehen.

Ein bisschen Geschichtswissen zu Let’s Encrypt

Spätestens seit den Snowden-Enthüllungen im Jahre 2013 ist klar, dass weltweit der Internetverkehr abgefangen und ausgewertet wird. Kaum ein Jahr später, im November 2014, erblickte die Internet Security Research Group (ISRG) das Licht der Welt und versprach freie und sichere SSL-Zertifikate für alle Serverbetreiber. Gründungsmitglieder der ISRG waren Branchengrößen wie die Mozilla Corporation, Cisco Systems, Akamai Technologies, die Electronic Frontier Foundation, IdenTrust sowie Forscher der University of Michigan. Die ISRG sprach in ihrem ersten Blogeintrag am 18. November 2014 davon, dass “alle verschlüsseln sollten” und dass “die Herausforderung in den Zertifikate liegt”.

Vital personal and business information flows over the Internet more frequently than ever, and we don’t always know when it’s happening. It’s clear at this point that encrypting is something all of us should be doing. Then why don’t we use TLS (the successor to SSL) everywhere? Every browser in every device supports it. Every server in every data center supports it. Why don’t we just flip the switch? The challenge is server certificates. The anchor for any TLS-protected communication is a public-key certificate which demonstrates that the server you’re actually talking to is the server you intended to talk to. For many server operators, getting even a basic server certificate is just too much of a hassle. The application process can be confusing. It usually costs money. It’s tricky to install correctly. It’s a pain to update. Let’s Encrypt is a new free certificate authority, built on a foundation of cooperation and openness, that lets everyone be up and running with basic server certificates for their domains through a simple one-click process. (aus dem Blogeintrag https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html)

Das ursprüngliche angepeilte Ziel des Go-Lives der ISRG vom zweiten Quartal 2015 wurde zwar verfehlt, aber mittlerweile ist Let’s Encrypt für den produktiven Betrieb geeignet.

Pro und Contra von HTTPS

Wenn man seine Webseite per HTTPS ausliefert, profitieren die Seitenbesucher und man selbst. Der Vorteil für die Kunden ist der offensichtliche: Sie können dank SSL-/TLS-Zertifikate nun verschlüsselt mit der Webseite kommunizieren.  Man selbst wird durch einen kleinen Boost des Google Webseiten-Ranking belohnt. Natürlich kann sich mit der zunehmenden Verbreitung von HTTPS-Zertifikaten dieser positive Ranking-Faktor nivellieren, aktuell ist die Verwendung von einem Zertifikat jedoch definitiv ein Plus im Bewertungsalgorithmus von Google.

Zusätzlich lässt sich sagen, dass ein grünes Schloss in der URL-Leiste auch Vertrauen bei den Besuchern einer Webseite schafft und ab sofort eher zum Standard als zur Ausnahme gehören sollte.

Grundsätzlich gibt es kein Argument, was gegen den Einsatz eines HTTPS-Zertifikats spricht. Die Ladegeschwindigkeit der Seite bleibt gleich, jeder Browser kann damit umgehen und auch sonst will einfach kein Grund dagegen einfallen.Wie funktioniert Let’s Encrypt?

Im Zentrum von Let’s Encrypt steht eine Zertifizierungsstelle (Certificate Authority oder CA), die Domain-Inhabern kostenlos ein SSL-Zertifikat ausstellt. Dabei handelt es sich um Domain-Validated-Zertifikate, die für die meisten Zwecke ausreichen. Um so ein Zertifikat zu erhalten, muss man gegenüber der CA lediglich beweisen, dass man eine Domain (oder auch Subdomain) unter Kontrolle. Wenn man diesen Nachweis erbringen kann, dann erhält man ein Zertifikat. Hierfür gibt es verschiedene Methoden, auf die wir im späteren Verlauf des Textes noch eingehen werden.

Die ausgestellten Zertifikate der “Let’s Encrypt Authority X3” werden von den gängigen Browsern akzeptiert.

Das besondere an diesen Zertifikaten ist, dass die Client Authority von Let’s Encrypt automatisch von jedem Browser akzeptiert wird. Ganz im Gegensatz zu selbst erzeugten Zertifikaten. Hier ist man selbst die eigene CA, welche aber von keinem Browser als vertrauenswürdig akzeptiert wird und daher vermutet jeder Browser ein Risiko hinter dem Aufruf einer Seite mit einem selbst signierten Zertifikat.

Dazu muss man wissen, dass jedes Betriebssystem eine Liste von beglaubigten CAs verwaltet. Diese Liste gibt an, welchem Aussteller eines Zertifikats automatisch vertraut wird und welchem nicht. Da natürlich nur wenige Firmen diesen Status des Vertrauens genießen, ließ man sich die Beglaubigung eines Zertifikats bisher gut bezahlen. Mit der Let’s Encrypt Authority ist aber nun auch eine Zertifizierungsstelle in der Liste jedes Browsers und Betriebssystems enthalten, die eben kein Geld für die Beglaubigung der Zertifikate verlangt.

Die zweite Besonderheit ist der automatische Beglaubigungsprozess, welches es ermöglicht ohne menschliches Eingreifen auf Seiten der CA Let’s-Encrypt-Zertifikate zu erstellen. Um dies zu erreichen, installiert man auf seinem Server den Let’s-Encrypt-Client, der über das Automated Certificate Management Environment, kurz ACME für eine bestimmte Domain oder Subdomain ein Zertifikat anfordert. Die CA stellt dem Server daraufhin eine Aufgabe, welche der Client erfüllen muss, um die Hoheit über die Domain zu beweisen. Dies kann zum Beispiel eine Datei sein, die auf dem Webserver angelegt werden und über die Domain erreichbar sein muss (=webroot validation). Alternativ kann auch anstelle des Webservers ein Dienst gestartet werden, der auf einem entsprechenden Port lauscht und eine Anfrage der CA beantwortet (=standalone validation). Für den Webserver Apache gibt es sogar ein eigenes Modul, welches nicht nur das Zertifikat beantragt, sondern auch gleich in die Konfiguration mit einbindet. Die Entwickler sprechen jeweils von einem eigenen Plugin, welches eine andere Art der Domainhoheit nutzt.

Sobald diese Aufgabe vom Client gelöst wurde, holt sich der Client das Zertifikat ab. 90 Tage lang ist dieses Zertifikat gültig und muss innerhalb dieser Zeit erneuert werden. Diese kurze Lebenszeit dient der Sicherheit, da es den Domainbesitzer zwingt, regelmäßig die Hoheit über die Domain zu beweisen. Natürlich läuft auch der Erneuerungsprozess automatisch ab.

Let’s Encrypt – ganz konkret

Nachdem Sie nun verstanden haben, was Let’s Encrypt ist und wie es funktioniert, wollen wir Ihnen zeigen, wie Sie Ihre Domain oder Ihren virtuellen Server mit einem grünen SSL-Zertifikat ausstatten. Wir gehen von einem virtuellen Server mit Ubuntu und nginx als Webserver aus. Aufgrund der guten Dokumentation des eingesetzten certbots sollte es Ihnen jedoch möglich sein, diese Anleitung auch auf andere Browser oder Betriebssysteme zu übertragen. Eine zentrale Voraussetzung ist jedoch, dass Sie auf Ihrem Server einen Root-Zugriff haben, da Sie sonst die notwendige Installation des certbots sowie der Konfiguration des Webservers nicht vornehmen können.

Als Beispiel für den folgenden Text beziehen wir uns auf unseren virtuellen Server bei Host-Europe, auf dem sowohl die Domain www.ionas.com als auch www.ionas-server.com gehostet werden. Bisher hatten wir zwar ein HTTPS-Zertifikat für die beiden Hauptdomains, jedoch war uns der Kauf eines wildcard-Zertifikats für beliebige Subdomains zu teuer. Nun möchten wir mit Let’s Encrypt die Subdomain https://cloud.ionas.com absichern. Eine weitere Besonderheit ist, dass die Domain cloud.ionas.com gar nicht auf den Webspace bei Host-Europe liegen soll, sondern auf einen ionas-Server Small Business bei uns im lokalen Netzwerk. Dies macht die Angelegenheit zwar etwas komplizierter, verdeutlicht aber gleichzeitig die vielfältigen Einsatzmöglichkeiten von Let’s Encrypt. Um Let’s Encrypt für den normalen Webspace bei Host-Europe zu nutzen, muss man einfach nur ein paar vorbereitende Schritte weglassen und würde auch zum gewünschten Ergebnis kommen. Legen wir also los.

Schritte 1: Weiterleitung von Anfragen an https://cloud.ionas.com einrichten

Unsere Domain www.ionas.com verwalten wir über Plesk, ein Server-Administrationstool, welches unser Domain-Hoster Host-Europe zur Verfügung stellt. Wir passen die DNS-Einstellungen für ionas.com an und fügen einen neuen CNAME-Eintrag hinzu.

Durch den CNAME-Eintrag werden Anfragen an https://cloud.ionas.com an den ionas-Server in unserem lokalen Netzwerk weitergeleitet.

Wenn die Subdomain auf den Webspace des virtuellen Servers bei Host-Europe zeigen soll, hätten wir hier die IP-Adresse des virtuellen Servers eingetragen. Da wir jedoch auf einen ionas-Server Small Business im lokalen Netzwerk unseres Büros zeigen wollen, verweisen wir auf Adresse ionas.spdns.de.

ionas.spdns.de ist ein DynDNS-Eintrag, hinter dem sich wiederum eine Umleitung auf die IP-Adresse unseres Büros verbirgt. Die Aktualisierung des DynDNS-Eintrags übernimmt dankenswerter der Small Business gleich selber.

Nach diesen Änderungen würden HTTPS-Anfragen an cloud.ionas.com bis zu unserem Router im Büro kommen. Von diesem werden Sie solange verworfen, bis wir im Router eine Portweiterleitung für den generischen HTTPS Port 443 eintragen. Ist dies geschehen – und auch die Firewall des ionas-Servers für den Port 443 geöffnet -, erreichen die Browseranfragen den Webserver des ionas-Servers Small Business. Kommen wir nun zur Einrichtung des Zertifikats auf dem Webserver.

Schritt 2: Let’s Encrypt Client installieren und Zertifikat anfordern

Als nächstes benötigen wir einen Root-Shell auf dem ionas-Server. Auf dieser installieren wir den offiziellen Certbot ACME-Client mit den folgenden Befehlen:

cd /usr/local/bin
git clone https://github.com/certbot/certbot
cd certbot

Wir empfehlen die Installation des Tools unter /usr/local/bin, weil dort unter Ubuntu Programme hingehören, die nicht über die eigene Paketquellen installiert wurden. Natürlich können Sie Certbot auch an jedem anderen beliebigen Ort installieren.

Als nächstes kommen wir zur Zertifikatsanforderung. Üblicherweise wird dieses per webroot-Plugin angefordert, bei dem die CA nach einer Datei auf dem Server sucht. Dies erfolgt üblicherweise über den Port 80, d.h. es würde nach einer Datei http://cloud.ionas.com/.well-known/acme-challenge gesucht werden. Da wir jedoch nur den Port 443 (d.h. https://) auf den ionas-Server weitergeleitet und freigegeben haben, wird diese Authentifizierung nicht funktionieren. Deshalb verwenden wir die standalone-Authentifizierung, welche verlangt, dass wir den aktuellen nginx-Webserver für kurze Zeit deaktivieren. Diese Methode startet selber eine Art Webserver und beantwortet nur die Anfrage der CA. Deshalb deaktivieren wir zuerst den Webserver mit den folgenden Befehlen, bevor wir das Zertifikat anfordern.

service nginx stop
./certbot-auto certonly --standalone --rsa-key-size 4096 -d cloud.ionas.com --standalone-supported-challenges tls-sni-01

Im Folgendenden nun die Parameter mit der jeweiliger Erklärung:

• certbot-auto: dies ist der Name des Let’s Encrypt Clients.
• certonly: es wird nur das Zertifikat angefordert. Der Webserver wird nicht automatisch konfiguriert oder verändert.
• –standalone: die von uns gewählte Authentifizierungsmethode.
• –rsa-key-size 4096: erhöht die Sicherheit, indem die Länge für den zu generierenden RSA Private Key auf 4096 Bits festgelegt wird. Standard sind 2048 Bit.
• -d cloud.ionas.com: dies ist die Domain oder Subdomain, für die das Zertifikat beantragt werden soll. Gleichzeitig mehrere Domains und Subdomains anzugeben, ist natürlich möglich.
• –standalone-support-challenges tls-sni-01: dieser Parameter teilt der CA mit, dass die Anfrage auf dem Port 443 und nicht auf dem Port 80 erfolgen soll.

Nach Eingabe Ihrer E-Mailadresse und der einmaligen Zustimmung zu den Nutzungsbedingungen wird das gewünschte Zertifikat vom ACME-Server abgeholt und in dem Verzeichnis /etc/letsencrypt/live/cloud.ionas.com gespeichert. In Summe liegen dort bei einer erfolgreichen Anforderung vier verschiedene Dateien:

• cert.pem (das öffentliche Zertifikat)
• chain.pem (die sogenannte Keychain)
• fullchain.pem (entspricht cert.pem + chain.pem)
• privkey.pem (der private Schlüssel)

Damit haben Sie alles, um Let’s Encrypt in Ihrem Webserver einzubauen.

Schritt 3: Webserver nginx starten und konfigurieren

Nachdem wir nun die Zertifikate erhalten haben, können wir nginx wieder starten.

service nginx start

Nun müssen wir nur noch die erhaltenen Zertifikate einbinden, um eine grüne URL mit vertrauenswürdigem SSL-Zertifikat zu erhalten. Eine Minimalkonfiguration des nginx-Webservers könnte z.B. so aussehen:

server {
  listen 443;
  server_name cloud.ionas.com;
  index index.php;
  allow all;

  ssl on;
  ssl_certificate /etc/letsencrypt/live/cloud.ionas.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/cloud.ionas.com/privkey.pem;
  ssl_session_timeout 5m;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES";
  ssl_prefer_server_ciphers on;

  location / {
    root /var/www;
    index index.php;
  }
}

Sobald der Webserver neu gestartet wurde, können wir überprüfen, ob das Zertifikat richtig eingebunden wurde. Wichtig ist, dass Sie nur beim Aufruf von https://cloud.ionas.com ein grünes Zertifikat sehen können.

1) Wenn Sie die lokale IP-Adresse (z.B. 192.168.7.3) verwenden, werden Sie auch weiterhin einen Zertifikatsfehler erhalten, da das Zertifikat nur für cloud.ionas.com beantragt wurde und eben nicht für die lokale IP-Adresse.

2) Aufgrund der geforderten Domainhoheit merkt man spätestens jetzt, das Let’s Encrypt nicht für lokale IP-Adressen oder DynDNS-Adressen verwendet werden kann. In beiden Fällen kann man die Domainhoheit eben nicht nachweisen.

3) Aus Sicherheitsgründen verweigern die meisten Router den Aufruf von https://cloud.ionas.com aus dem gleichen lokalen Netzwerk. Besitzer einer Fritz!Box können sich freuen, weil diese automatisch die Anfrage richtig im lokalen Netzwerk auflöst. Besitzer anderer Router müssen hier entweder entsprechende Einträge in der jeweiligen HOSTS-Dateien der Clients vornehmen oder prüfen, ob Ihr Router eventuell eine lokale DNS-Auflösung beherrscht. Dieses Thema an dieser Stelle weiter auszuführen, würde definitiv den Rahmen sprengen, aber gerne stehen wir auch für diese Fragen mit Rat und Tat zur Seite.

Schritt 4: Zertifikat automatisch per Cronjob erneuern lassen

Nun haben wir unseren virtuellen Server mit einem vertrauenswürdigen SSL-Zertifikat ausgestattet. Da das Zertifikat nur 90 Tage gültig ist, sollte man dieses automatisch aktualisieren lassen.

Dafür bietet sich der folgende Cronjob-Eintrag an:

0 0 * * * /usr/local/bin/certbot/certbot-auto renew --standalone --pre-hook "service nginx stop" --post-hook "service nginx start" >> /var/log/letsencrypt.log

Der Befehl wird täglich zur Geisterstune ausgeführt. Es wird der certbot mit dem Parameter renew aufgerufen. Gleichzeitig sorgen wir durch die pre-hook und post-hook dafür, dass zum Zeitpunkt der Anfrage der Webserver gestoppt wird.

Das Ergebnis des Befehls schreiben wir dabei fortlaufend in eine Logdatei mit Namen letsencrypt.log. Das schöne an diesem Befehl ist, dass der ACME-Client nur aktiv wird, wenn das Zertifikat in weniger als 30 Tagen abläuft. Wenn das Zertifikat noch länger gültig ist, legt der Certbot sich automatisch wieder schlafen.

Automatisierte Konfiguration mit ionas-Server Cockpit 3.4

Wir sind so begeistert von den Möglichkeiten, dass wir mit dem kommenden Cockpit-Update die Konfiguration von Let’s Encrypt über die Weboberfläche des ionas-Server möglich machen werden. Jeder unser Kunden wird z.B. die eigenen Seafile-Daten mit einem grünen SSL-Zertifikat ins Internet freigeben können. Seien Sie also gespannt auf das nächste ionas-Server Cockpit Update 3.4.