30.4 Einmal mit allem und kostenlos bitte: »Let's Encrypt«
Seit Ende 2015 wird das Feld der Zertifikate von einem neuen Spieler ordentlich aufgemischt. Die Rede ist natürlich von Let's Encrypt.
Let’s Encrypt (zu Deutsch Lasst uns verschlüsseln) ist eine Zertifizierungsstelle, die kostenlose X.509-Zertifikate für Transport Layer Security (TLS) anbietet. Dies wird durch einen automatisierten Prozess erreicht, der die komplexen manuellen Vorgänge bei der Erstellung übernimmt, wie die Validierung, die Signierung, die Einrichtung und die Erneuerung von Zertifikaten. Das Projekt verfolgt das Ziel, verschlüsselte Verbindungen im Internet zum Standard zu machen.
Dazu betreibt das Projekt eine Ausgabestelle für Zertifikate. Um es uns Administratoren möglichst leicht zu machen, bietet das Projekt einen Software-Client, der sich um das Erstellen, Signieren, Validieren und das rechtzeitige Erneuern der Zertifikate kümmert. Der originäre Client des Projekts heißt certbot. Auf der Projektseite unter https://letsencrypt.org finden Sie viele Hinweise und eine umfangreiche Dokumentation.
Selbstverständlich sind die Root-CA-Zertifikate von Let's Encrypt in allen gängigen Browsern enthalten, sodass es zu keinerlei Warnmeldungen kommt.
30.4.1 Wie funktioniert das?
Das Prinzip ist relativ simpel. Wie alle Zertifizierungsstellen muss auch Let's Encrypt sicherstellen, dass ein Zertifikat nur an berechtigte Personen ausgestellt wird. Anstatt dies aber kompliziert über Ident-Verfahren zu lösen, haben die Entwickler eine automatisierte Variante erdacht:
-
Der Let's-Encrypt-Client fragt zunächst die CA, was zu tun ist, um zu beweisen, dass die Domäne, für die ein Zertifikat ausgestellt werden soll, auch unter der Kontrolle des Beantragenden ist, und überträgt den öffentlichen Teil des Zertifikats.
-
Die Anwort der CA besteht in zwei Möglichkeiten, den Beweis anzutreten:
-
Einrichtung eines angepassten DNS Resource Records für die Domäne
-
Einrichtung einer HTTP Resource für die Domäne (z. B. http://example.com/4711)
In der Regel wird die zweite Methode verwendet. Gleichzeitig wird ein nonce[ 63 ] übertragen (zum Beispiel abcd), das vom Client mit seinem privaten Schlüssel signiert werden muss.
-
-
Der Client erfüllt nun eine der beiden Anforderungen. Meist die zweite: Er legt also die angeforderte Datei (4711) an und legt dort den mit seinem privaten Schlüssel signierten nonce (abcd) ab.
-
Die CA prüft nun, ob alles mit rechten Dingen zugeht – sprich, ob der nonce (abcd) unter http://example.com/4711 erreichbar ist und korrekt signiert wurde. Wenn ja, gibt die CA Rückmeldung an den Client und stellt das Zertifikat aus.
-
Der Client erhält nun das von der CA signierte Zertifikat, und der Prozess ist abgeschlossen.
Die Kommunikation erfolgt im Übrigen über das Let's-Encrypt-eigene Protokoll ACME.
30.4.2 Einschränkungen
Im Gegensatz zu sonstigen TrustCentern werden Lets-Encrypt-Zertifikate mit einer Laufzeit von »nur« 90 Tagen ausgegeben. Dies dient vor allem der Transparenz und dazu, aktuellen Veränderungen zeitnah Rechnung tragen zu können.
Da Let's Encrypt mit einer Automation arbeitet, wurden ein paar Einschränkungen eingebaut, um Missbrauch zu verhindern. Diese sind aber so großzügig bemessen, dass nichts gegen einen produktiven Einsatz spricht:
-
Namen pro Zertifikate
sind zurzeit auf 100 Namen (oder Webseiten) pro Zertifikat beschränkt. -
Zertifikate pro Domäne
sind auf 20 pro Woche limitiert. Dabei kann eine Anfrage eine oder mehrere Domänen beinhalten. Ausnahme: Wenn ein Zertifikat mit den gleichen Domänen abgefragt wird, greift diese Beschränkung nicht – aber gegebenenfalls die folgende Beschränkung. -
Zertifikate pro FQDN-Set
beschränkt die Anzahl der Zertifikate, die mit der exakt gleichen Anzahl von FQDNs (die als FQDN-Set bezeichnet wird) abgerufen werden dürfen, auf 5 Zertifikate pro Woche. -
Registrierung von IP-Adressen
ist derzeit auf 500 pro 3 Stunden limitiert. -
Ausstehende Autorisierung pro Account
begrenzt die Anzahl an Autorisierungsversuchen, ohne dass diese erfolgreich beendet werden, auf 300 pro Account pro Woche.
Im Regelbetrieb werden diese Werte nicht erreicht werden, auch dann nicht, wenn Sie viele Domänen über ein System verwalten (zum Beispiel auf einem Reverse-Proxy).
30.4.3 Der Client »certbot«
Der certbot wird über GitHub angeboten und besteht im Wesentlichen aus Skripten. Diese sind praktischerweise so konzipiert, dass sie auf allen gängigen Distributionen lauffähig sind und sich sogar selbstständig aktualisieren. Die Installation ist daher äußerst einfach, es genügt der Befehl aus Listing 30.4:
$ cd /opt/
$ git clone https://github.com/certbot/certbot
Listing 30.4 Herunterladen des »certbot«
Anschließend finden Sie im Verzeichnis /opt/certbot den certbot. Darin befinden sich viele Varianten von Skripten und eine umfangreiche Dokumentation. Der eigentliche Client versteckt sich im Skript certbot-auto.
Um ein Zertifikat für die Domain example.com zu erhalten, benutzen Sie das folgende Kommando:
root@mail:~# certbot-auto certonly --standalone --rsa-key-size 4096 --agree-tos \
-m meine@email-adresse.org -d example.com -d www.example.com
Listing 30.5 Zertifikat für »example.com« erstellen
Die E-Mail-Adresse müssen Sie angeben, weil Sie darüber Informationsmails über den Status des Zertifikats bekommen. Der Parameter --agree-tos bedeutet, dass Sie den Geschäftsbedingungen (Terms of Service, TOS) zustimmen. Wenn Sie diese Parameter weglassen, erscheinen Dialogboxen, die die Daten abfragen.
certonly bedeutet, dass die Zertifikate nach dem Erzeugen nur im Filesystem abgelegt werden. Für bestimmte Dienste, etwa den Apache Webserver, kann letsencrypt Ihnen auch etwas Arbeit abnehmen und die Pfade zu den Zertifikaten in die Webserver-Konfiguration einbinden.
Wie Sie in Listing 30.5 sehen, kann man auch direkt mehrere Zertifikate erzeugen lassen, in diesem Fall gleich zwei: example.com und www.example.com.
Wenn der Vorgang erfolgreich war, werden die Zertifikate mit dem ACME-Protokoll abgeholt und unter /etc/letsencrypt/live/<DOMAIN> abgelegt. Für jeden Namen wird also ein Unterverzeichnis angelegt. In dem Unterverzeichnis liegen wiederum die Zertifikatsdateien:
root@mail:~# ls /etc/letsencrypt/live/example.com/
cert.pem
chain.pem
fullchain.pem
privkey.pem
Listing 30.6 Den Inhalt des Zertifikatsarchivs ausgeben lassen
Je nach Webserver, den Sie einsetzen, können Sie nun die benötigten Varianten der Zertifikate an ihren Bestimmungsort bringen. Falls Ihnen das zu mühsam ist, können Sie dem Befehl aus Listing 30.5 noch den Parameter --webroot <PFAD> hinzufügen. Die Zertifikate werden dann von certbot direkt dort abgelegt.
Im Übrigen sind für die gängigsten Webserver auch schon Pfade vordefiniert, sodass Sie certbot auch direkt darauf ansetzen können, die Pfade selbst aus Ihrer Konfiguration zu ermitteln und die Zertifikate entsprechend einzusortieren. Allerdings empfehlen wir Ihnen, dies nicht zu tun – falls ein Automatismus an dieser Stelle sinnvoll ist, sollten Sie ihn lieber selbst in ein Bash-Skript umsetzen, so haben Sie die volle Kontrolle.
Wie bereits erwähnt wurde, haben die Zertifikate von Let's Encrypt nur eine Gültigkeit von 90 Tagen. Daher müssen Sie den Befehl aus Listing 30.5 auch entsprechend häufig ausführen und die neuen Zertifikate direkt an Ihren Webserver (oder dergleichen) weitergeben. Richten Sie dafür am besten einen Cronjob ein, der Ihnen die Arbeit abnimmt. Im Übrigen wird durch das erneute Aufrufen des Befehls das »alte« Zertifikat von der CA zurückgerufen, sodass Sie zwingend das neue verwenden müssen!