© Alexey Poprotsky, 123RF

Was stört an herkömmlichen SSL-Zertifikaten mehr: die Kosten oder die fehlende Automatisierbarkeit? Die Initiative Let’s Encrypt ist angetreten, um beides zu verbessern.

Let’s Encrypt[1] ist ein Projekt der gemeinnützigen Internet Security Research Group (ISRG, [2]), in der sich unter andrem Mozilla und die Electronic Frontier Foundation zusammengeschlossen haben. Ziel des durch Sponsoren finanzierten Projekts ist es, SSL-Verschlüsselung zu verbreiten, ja sogar HTTP als Standard durch HTTPS zu ersetzen.

Um die Hürden für den Einsatz der Verschlüsselung zu senken, haben die Beteiligten das Thema von Grund auf neu überdacht. Herausgekommen ist nicht nur eine neue Zertifizierungsstelle (Certification Authority, CA), sondern auch ein neues Protokoll, das auf dem besten Weg ist, ein RFC-Standard zu werden.

Kostenlose Zertifikate

Sicherere Kommunikation soll Dienstebetreiber nach Möglichkeit kein Geld kosten. Let’s Encrypt stellt deshalb kostenlose SSL-Zertifikate aus. Warum aber brauchte es ein neues Protokoll? Das geht auf ein Sicherheitsproblem zurück: Kompromittierte Zertifikate sollen schnell austauschbar sein. Deshalb beschränken die Aussteller die Gültigkeit der Zertifikate von vornherein auf 90 Tage.

Braucht der Anwender aber alle 90 Tage ein neues Zertifikat, dann muss er den Erneuerungsprozess automatisieren können. Und dafür wiederum hat die ISRG ein eigenes Protokoll entwickelt, das Automatic Certificate Management Environment (ACME). Derzeit liegt ACME als Internet Draft bei der Internet Engineering Task Force (IETF, [3]).

Let’s Encrypt implementiert das ACME-Protokoll als freie Software. Server-seitig läuft die CA-Software Boulder [4], die unter der Mozilla Public License 2.0 steht. Für die Clients der CA – also die Server der Anwender – gibt es bereits eine Vielzahl von ACME-Clients. Der offizielle Client heißt Certbot [5]. Er ist das Nachfolgetool einer Referenzimplementierung von Let’s Encrypt, die das Linux-Magazin früher bereits einmal vorgestellt hat [6].

Das ambitionierte Projekt hat im April 2016 die Betaphase verlassen und im Juni 2016 sein fünfmillionstes Zertifikat ausgestellt. Seit März ist Let’s Encrypt Mitglied des CA/Browser-Forums [7], um in Zukunft als auditierte Zertifizierungsstelle in den gängigen Browsern vorinstalliert zu sein. Momentan sind die Stammzertifikate von Identrust cross-signiert, damit die Browser kein Misstrauen schöpfen. Firefox vertraut seit Kurzem auch direkt dem Let’s-Encrypt-Zertifikat.

Der Funktionsumfang

Eine der wichtigsten Fragen ist, was mit Let’s Encrypt geht und was nicht. Grundsätzlich stellt die CA nur Domain-validierte Zertifikate nach dem X.509-Standard aus. Domain-validiert bedeutet, dass Zertifikatsinhaber lediglich beweisen, dass sie die Domain kontrollieren, für die das Zertifikat gelten soll. Eine Prüfung der tatsächlichen Identität ihrer Person oder Organisation findet jedoch nicht statt.

Wer aber auf SSL-Zertifikate mit einer solchen erweiterten Validierung oder Organisations-Validierung angewiesen ist, der geht vorerst leer aus. Let’s Encrypt ist also vor allem für diejenigen interessant, die verschlüsselte Verbindungen zu ihren Websites, Mailservern oder Ähnlichem anbieten möchten.

Für den deutschsprachigen Kontext ist interessant, dass Let’s Encrypt im Laufe dieses Jahres auch Domainnamen mit Umlauten unterstützen soll. Wildcard-Zertifikate sind zumindest bislang nicht geplant. Wer mehrere Subdomains besitzt, kann bis zu 100 von ihnen mit demselben Zertifikat abdecken oder viele einzelne Zertifikate ausstellen lassen. E-Mails oder Quellcode lassen sich dagegen nicht mit X.509-Zertifikaten signieren.

Let’s Encrypt unterstützt Certificate Transparency nach RFC 6962 [8], befüllt also ein öffentliches Log mit allen ausgestellten Zertifikaten. Browser, die in der Lage sind, die Certificate Transparency abzufragen, können Benutzer bei fehlender Übereinstimmung warnen.

Das ACME-Protokoll

Wer einer Zertifizierungsstelle vertraut, der glaubt, dass sie sicherstellen kann, dass ein Bewerber tatsächlich der legitime Eigentümer einer Domain ist. Der bisher etablierte Prozess hierfür ist nicht automatisierbar: Der Antragsteller generiert lokal einen privaten Schlüssel und einen Certificate Signing Request (CSR), dann meldet er sich im Webinterface der CA an, ruft eine E-Mail zur Validierung ab und kopiert den CSR in die Weboberfläche. Schließlich löst er dort das Zertifikat heraus und befördert es auf den Webserver.

Über das neue ACME-Protokoll ist dieser Prozess automatisierbar: Das Protokoll standardisiert die Kommunikation zwischen Webservern und Zertifizierungsstellen. Es regelt die Verifizierung von Domain-Inhabern sowie die Ausstellung, die Erneuerung und das Widerrufen von Zertifikaten.

Ein ACME-Server läuft bei einer Zertifizierungsstelle und nimmt Zertifizierungsanfragen entgegen. Ein ACME-Client kann in ganz verschiedener Software eingebaut sein, etwa in eine separate Software, die sich ausschließlich um die Zertifikatsbeschaffung kümmert. Ebenso kann ein ACME-Client Bestandteil eines größeren Softwareprojekts sein. Ein Beispiel ist der HTTP/2-Webserver Caddy: Er bietet SSL-Verschlüsselung als Standard an. Der im Webserver eingebaute ACME-Client geht von sich aus zu Let’s Encrypt oder einer anderen Zertifizierungsstelle und holt ein Zertifikat für die Domain, für die er zuständig sein soll. Im Folgenden ist mit Client also jede Software gemeint, die über das ACME-Protokoll eine Zertifizierungsstelle kontaktiert.

Der ACME-Server ist über eine REST-Schnittstelle ansprechbar. Bei der ersten Kontaktaufnahme durch einen ACME-Client informiert er diesen über seine verschiedenen Ressourcen (Tabelle 1). Jedes Anliegen ist im Internet-Draft genau definiert. Ein ACME-Client muss nicht nur beweisen, dass er die Domain kontrolliert, sondern zunächst ein Schlüsselpaar für diese Domain vom Server autorisieren lassen. Bei jeder Kontaktaufnahme muss er seine Anfrage mit dem privaten Schlüssel signieren.

Der Server nimmt Json-over-HTTPS-Anfragen entgegen. Den Request-Body jeder Anfrage versieht der Client mit einer Json Web Signature, die der Server ebenfalls prüfen muss, nur für den Fall, dass die SSL-Verbindung nicht am eigentlichen Webserver terminiert, sondern beispielsweise an einem Content Delivery Network. Der Typ des Request-URI lässt sich so vor Manipulation schützen. Schließlich ist noch ein Schutz gegen Replay-Attacken eingebaut: Der Server übermittelt vor jeder Transaktion einen Einmal-Schlüssel, den der Client mit seiner Antwort zurückschicken muss.

Challenge-Response-Verfahren

Der Webserver kann zwischen drei verschiedenen Challenges auswählen, um die Domain beim ACME-Server zu validieren. Für welche er sich entscheidet, hängt davon ab, welchen Weg der Anwender in der eigenen Umgebung automatisieren kann. Wer automatisiert Nameserver-Einträge vornehmen kann, der entscheidet sich vielleicht für das DNS-01-Verfahren und bestimmte Prüfsummen als TXT-Records im DNS. Beim zweiten Verfahren, dem TLS_SNI-01, lässt man ein selbst signiertes Zertifikat mit zwei Subject Alternative Names generieren, die ebenfalls aus bestimmten Prüfsummen bestehen müssen.

Wer hingegen ein Unterverzeichnis im Document Root der Domains beschreiben kann, der mag stattdessen das HTTP-01-Verfahren wählen. Hier schreibt der Client ein vom Server übermitteltes Token in eine temporäre Datei, die der Server anschließend per »http« abruft. Genau dieser Weg kommt auch bei der weiter unten beschriebenen Umsetzung zum Einsatz.

01 HTTP/1.1 201 Created
02 Content-Type: application/json
03 Location: https://domain.tld/authz/asdf
04 Link: <https://domain.tld/acme/new-cert>;rel="next"
05 Link: <https://domain.tld/acme/some-directory>;rel="directory"
06 {
07   "status": "pending",
08   "identifier": {
09     "type": "dns",
10     "value": "domain.tld"
11   },
12
13   "challenges": [
14     {
15       "type": "http-01",
16       "uri": "https://domain.tld/authz/asdf/0",
17       "token": "IlirfxKKXAsHtmzK29Pj8A"
18     },
19     {
20       "type": "dns-01",
21       "uri": "https://domain.tld/authz/asdf/1",
22       "token": "DGyRejmCefe7v4NfDGDKfA"
23     }
24   ],
25   "combinations": [[0], [1]]
26 }

Konkret sendet der ACME-Client einen »POST« -Request an den New-Authz-URI des Servers. Der Server antwortet darauf mit dem Token, der für das Challenge-Response-Verfahren zu verwenden ist. Er setzt alle drei Challenges auf den Status »pending« (Listing 1). Der Client versucht eine der Challenges zu erfüllen. Listing 2 zeigt als Beispiel das Logfile für die Webroot-Challenge.

01 certbot.auth_handler:http­01 challenge for domain.tld
02 certbot.plugins.webroot:Using the webroot path /var/www/domain.tld for all unmatched domains.
03 certbot.plugins.webroot:Creating root challenges validation dir at /var/www/domain.tld/.well­-known/acme-­challenge
04 certbot.plugins.webroot:Attempting to save validation to /var/www/domain.tld/.well­-known/acme-­challenge/j7191AU6­K5MnrsYLoyCwsiHCU85b3NUT0QH2yBdU_Y

Bei erfolgreichem Bestehen einer Challenge meldet der Server ein »valid« für die entsprechende Challenge. Daraufhin übermittelt der Client seinen CSR und bekommt das Zertifikat. Er legt es ab und schreibt sich die verwendeten Optionen auf, um sie bei der Erneuerung wiederzuverwenden (Listing 3). Bei der Erneuerung wählt er also das gleiche Challenge-Response-Verfahren, verwendet das gleiche Document-Root-Verzeichnis und so weiter.

01 # renew_before_expiry = 30 days
02 version = 0.8.0
02 cert = /etc/letsencrypt/live/domain.tld/cert.pem
04 privkey = /etc/letsencrypt/live/domain.tld/privkey.pem
05 chain = /etc/letsencrypt/live/domain.tld/chain.pem
06 fullchain = /etc/letsencrypt/live/domain.tld/fullchain.pem
07 # Options used in the renewal process
08 [renewalparams]
09 authenticator = webroot
10 rsa_key_size = 4096
11 installer = None
12 account = dx112f5317187420c342510b29xxxxxx
13 webroot_path = /var/www/domain.tld,
14 [[webroot_map]]
15 domain.tld = /var/www/domain.tld
16 domain.tld = /var/www/domain.tld

Die Zertifikate landen im Archiv-Verzeichnis unterhalb von »/etc/letsencrypt« , ihre Dateinamen zählen bei der automatischen Erneuerung hoch. Im Webserver müssen entsprechende Symlinks ins Verzeichnis »/etc/letsencrypt/live« eingetragen werden. Wohin sie zeigen, passt das Renewal dann ebenfalls automatisch an.

Wer andere Anwendungen wie zum Beispiel den Mail- oder Jabber-Server absichern möchte, muss sich eine Lösung für Probleme mit Zugriffsrechten überlegen, etwa über eine Gruppe, die SSL-Zertifikate lesen darf.

Der ACME-Client Certbot

Es gibt inzwischen eine lange Liste von ACME-Clients mit unterschiedlichem Funktionsumfang und in unterschiedlichen Programmiersprachen. Der offizielle Client Certbot ist ein in Python geschriebenes Projekt der EFF. Certbot ist zu allen CAs kompatibel, die das ACME-Protokoll sprechen. Die Projekt-Website bietet ein interaktives Werkzeug, dem der Webserver-Admin seine Distribution und seinen Webserver mitteilt, um eine passende Installations- und Bedienungsanleitung zu erhalten. Pakete gibt es unter anderem für Debian 8, Ubuntu 16.04, Arch Linux, Fedora 23, Centos/RHEL 7. In älteren Betriebssystemversionen lässt sich der Client einfach mit »wget« herunterladen und ausführen.

Die Manpage von Certbot gibt einen Überblick über alle Funktionen. Erwähnenswert ist der Unterschied zwischen zwei Plugins: Installer und Authenticator. Installer übernimmt die Konfiguration des Webservers, was nicht alle zulassen möchten. Authenticator kümmert sich dagegen nur um die Domain-Validierung und die Zertifikatsbeschaffung, er nimmt keine Autokonfiguration vor.

Die Bestellung eines Zertifikats mit »certbot« zeigt Abbildung 1. Dort kommen – als Vorbereitung für die Automatisierung – keine interaktiven Abfragen vor. Das Subkommando »certonly« hält Certbot von der Webserver-Konfiguration fern. Die Schlüssellänge steht standardmäßig nur auf 2048 Bit, was sich über den Schalter »–rsa-key-size« ändern lässt. In die Crontab gehört der Befehl:

certbot renew

Er prüft dann regelmäßig, ob die Zertifikate erneuert werden müssen, und stößt dies gegebenenfalls an.

Abbildung 1: Certbot fordert ein Let’s-Encrypt-Zertifikat mit Domain-Validierung über die Webroot-Challenge an.

Einer der wichtigsten Kritikpunkte an Certbot ist, dass er mit Root-Rechten laufen muss. Der Client installiert selbstständig Abhängigkeiten nach und muss im Stand-alone-Modus zudem dazu in der Lage sein, den privilegierten Port 80 zu öffnen. Wer das nicht hinnehmen möchte, kann den Client in einen Docker-Container sperren oder die Liste der alternativen Client-Implementierungen [9] durchstöbern.

Automatisierung für Shared Webhosting

Für Hoster, die mit Webspace auf einem Shared-Hosting-Cluster die Let’s-Encrypt-Zertifikate anbieten möchten (Abbildung 2), gibt es einen Integration Guide [10] mit interessanten Tipps. Das Dokument beantwortet auch die Frage, wer der Subscriber ist: Der ISP ist als Inhaber des privaten Schlüssels eines SSL-Zertifikats Subscriber von Let’s Encrypt, nicht die Kundschaft. Das Subscriber Agreement gilt also zwischen Hoster und ISRG. Das folgende Szenario beschreibt die Realisierung mit Webroot-Challenges.

Abbildung 2: So sieht das Let’s-Encrypt-Zertifikat im Browser aus.

Ein Let’s-Encrypt-Client läuft auf dem Server, der die Document Roots aller Kundendomains beherbergt. Hier sollen ja die jeweiligen Tokens für die Domain-Validierung temporär hinterlegt werden. Das hat Folgen für die Webserver-Konfiguration dieser Domains: Der Webserver muss das Aufrufen versteckter Verzeichnisse erlauben, denn das Standardverzeichnis für die HTTP-01-Challenge ist ».well-known/acme-challenge« im Document Root. Alle ».well-known« -URIs müssen über HTTP aufrufbar sein und bleiben, sind also von Umleitungen auf SSL und vom ».htpasswd« -Schutz auszunehmen.

Danach gilt es, einen Client auszuwählen. Welcher sich für die eigene Hosting-Umgebung eignet, hängt davon ab, wo und wie man die anfallenden Daten speichern möchte. Im hier vorgestellten Aufbau sollen die Zertifikate und die verwendeten Parameter in einem Dateibaum liegen, der zunächst nach Kunden-Accounts und darunter dann Domain-weise organisiert ist. Zudem liegen die SSL-Zertifikate und Webserver-Konfigurationen in Open LDAP als Attribute der Domains. In der Domain-spezifischen Konfiguration muss also außer dem ».well-known« -URI auch der Distinguished Name des Domain-Objekts stehen.

Jedes Zertifikat soll automatisch auch für die jeweilige Subdomain »www.« gelten. Für die Automatisierung sind daher mehr Informationen vorzuhalten, als der offizielle Certbot vorsieht. Das Rennen hat ein in Bash geschriebener inoffizieller ACME-Client gemacht [11]. Ihn ergänzen zwei eigene Wrapper-Skripte.

Die Kundschaft hat in der Domainverwaltung ein Häkchen, über das sie ein neues LDAP-Attribut »letsencrypt« setzt. Es wertet das erste Wrapper-Skript aus, befüllt die oben beschriebenen Konfigurationsdateien und ruft den ACME-Client auf. Ist die Domain-Validierung erfolgreich, ruft es das zweite Wrapper-Skript auf, das die Zertifikate und SSL-Redirects ins LDAP schreibt. Das Deployment der Webserver-Konfiguration aus Open LDAP übernimmt das Konfigurationsmanagement-System. Ein Cronjob ruft das erste Wrapper-Skript regelmäßig auf.

Je nach Anzahl der Domains ist es sinnvoll, sich die Angaben zu Rate-Limits bei Let’s Encrypt durchzulesen. Wer grundsätzliche Kritik an dem Konzept vertrauenswürdiger Zertifizierungsstellen übt, der wird auch mit Let’s Encrypt nicht glücklich. Wem aber daran liegt, Aufwand und Kosten des regelmäßigen Rollover zu reduzieren, findet mit Let’s Encrypt eine sehr gute Lösung.

Fazit

Für die meisten Domain-Inhaber reicht – besonders im Shared Webhosting – ein Domain-validiertes Zertifikat. Für Hosting-Provider gibt es nicht nur eine große Anzahl freier ACME-Clients, sie können dank des ACME-Protokolls eigene Clientsoftware entwickeln. Das Projekt Let’s Encrypt bringt auch Bewegung in herkömmliche CAs, die teils schon begonnen haben, an ihrem Prozedere und ihren Preisen zu schrauben. Es hat das Potenzial, die Verbreitung von SSL-Verschlüsselung deutlich zu erhöhen.