ADMIN
2021
05
2021-05-01T12:00:00
Hybrid Cloud
PRAXIS
058
Hybrid Cloud
Cloud
Zertifikat mittels acme.sh beziehen
Einfach ausgestellt
von Thorsten Scherf
Veröffentlicht in Ausgabe 05/2021 - PRAXIS
Das ACME-Protokoll wird zumeist im Zusammenhang mit der Zertifizierungsstelle Let's Encrypt genannt, da sich mit diesem digitale Zertifikate für TLS-Verschlüsselung einfach ausstellen lassen. Mittlerweile unterstützen allerdings immer mehr Systeme ACME. Der Open-Source-Tipp nimmt das Protokoll unter die Lupe und stellt mit acme.sh einen leichtgewichtigen Client dafür vor.

Werden Daten im Internet übertragen, sollten diese im Idealfall verschlüsselt sein. Die Organisation Let's Encrypt [1] hat einen wesentlichen Anteil dazu beigetragen, diesen Vorsatz umzusetzen. War es bis vor wenigen Jahren ein recht komplexer Vorgang, ein X.509-Zertifikat zu beziehen, wurde dieser Workflow durch die Let's-Encrypt-Zertifizierungsstelle in Zusammenhang mit dem ACME-Protokoll (Automatic Certificate Management Environment) stark vereinfacht. Somit ist es nun für jedermann möglich, ein Zertifikat für den eigenen Webdienst oder auch andere Services zu beziehen, um einen sicheren TLS-Kommunikationskanal anzubieten.
Grundsätzlich sind beim Einsatz von ACME zwei Komponenten unabdingbar: Ein ACME-Server und -Client. Das Protokoll basiert darauf, dass der Client nachweisen kann, Kontrolle über die Domäne zu besitzen, wofür der Server ein Zertifikat ausstellen soll. Kann der Client den Nachweis erbringen, stellt der Server ein sogenanntes Domain Validated Certificate (DV) aus und sendet dieses an den Client. Anders als beispielsweise bei den Zertifikatstypen Organization Validation (OV) oder Extended Validation (EV) ist keine Validierung des Antragstellers notwendig. Es sind also optimale Voraussetzungen gegeben, um den Prozess von der Antragstellung bis zur Ausstellung des Zertifikats zu automatisieren.
Unterschiedliche Challenge-Typen
Um den Nachweis zu erbringen, dass der Client die Kontrolle über eine Domäne besitzt, sendet der Server eine sogenannte Challenge an den Client. Für diese Challenges existieren unterschiedliche Typen: http-01, dns-01 und tls-alpn-01. Während die ersten beiden Typen bereits seit Anfang an Teil des ACME-Protokolls sind und somit auch im RfC8555 [2] dokumentiert sind, kam tls-alpn-01 erst im letzten Jahr als Erweiterung des Protokolls hinzu. Dieser Challenge-Typ ist im RfC 8737 beschrieben [3].
Werden Daten im Internet übertragen, sollten diese im Idealfall verschlüsselt sein. Die Organisation Let's Encrypt [1] hat einen wesentlichen Anteil dazu beigetragen, diesen Vorsatz umzusetzen. War es bis vor wenigen Jahren ein recht komplexer Vorgang, ein X.509-Zertifikat zu beziehen, wurde dieser Workflow durch die Let's-Encrypt-Zertifizierungsstelle in Zusammenhang mit dem ACME-Protokoll (Automatic Certificate Management Environment) stark vereinfacht. Somit ist es nun für jedermann möglich, ein Zertifikat für den eigenen Webdienst oder auch andere Services zu beziehen, um einen sicheren TLS-Kommunikationskanal anzubieten.
Grundsätzlich sind beim Einsatz von ACME zwei Komponenten unabdingbar: Ein ACME-Server und -Client. Das Protokoll basiert darauf, dass der Client nachweisen kann, Kontrolle über die Domäne zu besitzen, wofür der Server ein Zertifikat ausstellen soll. Kann der Client den Nachweis erbringen, stellt der Server ein sogenanntes Domain Validated Certificate (DV) aus und sendet dieses an den Client. Anders als beispielsweise bei den Zertifikatstypen Organization Validation (OV) oder Extended Validation (EV) ist keine Validierung des Antragstellers notwendig. Es sind also optimale Voraussetzungen gegeben, um den Prozess von der Antragstellung bis zur Ausstellung des Zertifikats zu automatisieren.
Unterschiedliche Challenge-Typen
Um den Nachweis zu erbringen, dass der Client die Kontrolle über eine Domäne besitzt, sendet der Server eine sogenannte Challenge an den Client. Für diese Challenges existieren unterschiedliche Typen: http-01, dns-01 und tls-alpn-01. Während die ersten beiden Typen bereits seit Anfang an Teil des ACME-Protokolls sind und somit auch im RfC8555 [2] dokumentiert sind, kam tls-alpn-01 erst im letzten Jahr als Erweiterung des Protokolls hinzu. Dieser Challenge-Typ ist im RfC 8737 beschrieben [3].
Die meisten ACME-Clients setzen standardmässig auf die http-01-Challenge, da diese die geringsten Anforderungen aufweist. Der Antragsteller muss über einen Webserver verfügen, der aus dem Internet auf Port 80 erreichbar ist und für die Domäne konfiguriert ist, für die das ACME ein Zertifikat ausstellen soll. Zu Testzwecken kann auch der ACME-Client selbst einen temporären Webserver starten.
Wird die Anforderung nicht erfüllt, weil beispielsweise der Zugang zum Port 80 nicht möglich ist, kann entweder der Challenge-Typ dns-01 oder tls-alpn-01 zum Einsatz kommen. Im ersten Fall müssen Sie in der Lage sein, einen DNS-TXT-Record innerhalb der eigenen Domäne zu provisionieren. Alternativ lässt sich auch der Challenge-Typ tls-alpn-01 einsetzen. Hierfür verwendet der Client die Application Layer Protocol Negotiation (ALPN) und erzeugt ein temporäres Zertifikat, das für den Zeitraum der Provisionierung zum Einsatz kommt und später durch das vom ACME-Server ausgestellte Zertifikat ausgetauscht wird. Die Kommunikation zwischen ACME-Server und -Client findet in diesem Fall über Port 443 statt.
Verifizierung der Kontrolle über eine Domäne
Unabhängig vom verwendeten Challenge-Typ ist es immer wichtig, dem ACME-Server den Zugang zu einer bestimmten Ressource zu ermöglichen, die er für jede Challenge neu erzeugt und sie dann zur Provisionierung an den Client sendet. Diese Ressource steht auf dem Client beim Einsatz des Challege-Typs http-01 als Datei zur Verfügung, die der Server dann versucht abzufragen. Wird hingegen der Challege-Typ dns-01 genutzt, versucht der Server die Ressource über eine DNS-Abfrage zu verifizieren.
Mehrstufiger Workflow
Zur Kommunikation zwischen ACME-Client und -Server kommen JSON-Nachrichten (JavaScript Object Notation) zum Einsatz. Der Workflow sieht vor, dass ein Client zuerst eine Registrierung auf dem Server durchführt und dann das gewünschte Zertifikat beantragt. Anschließend erbringt der Client mithilfe des gewünschten Challenge-Typs den Nachweis, Kontrolle über die im Zertifikat verwendete Domäne zu besitzen. Vor der Registrierung muss der Client ein asymmetrisches Schlüsselpaar generieren, um die zwischen dem Client und dem Server ausgetauschten Nachrichten zu signieren beziehungsweise zu verifizieren.
Jeder ACME-Server stellt ein Directory-JSON-Object zur Verfügung, mit dem ACME-Clients die angebotenen Dienste des Servers abfragen können. Dies geht auch ganz einfach mithilfe von "curl" oder einem vergleichbaren Tool. Der Befehl lautet:
curl -s https://server.example.com/acme/directory | python -m json.tool.
Die zuvor angesprochene Ressource besteht aus einem Token, den der Server an den Client sendet, und einem Hash, der aus Ihrem öffentlichen Schlüssel erzeugt wird. Verwenden Sie den Challenge-Typ http-01, muss der ACME-Client dafür sorgen, dass der Server diese Ressource unter dem Pfad "/.well-known/acme-challenge/" mithilfe von HTTP abfragen kann. Setzten Sie hingegen den Challenge-Typ dns-01 ein, erwartet der Server die Zeichenkette in einem DNS-TXT-Record, der wie folgt aussieht:
_acme-challenge.www.example.org. 300 IN TXT "Y5YvkzC_4qh9gKj6...jxAjEuX1"
Daneben bietet das Protokoll mithilfe von Nonces Schutz vor Replay-Attacken und sieht auch einen Workflow vor, um ausgestellte Zertifikate zu sperren, falls dies notwendig ist. Nähere Informationen hierzu sind dem RfC 8555 [2] zu entnehmen. Für den täglichen Betrieb ist es nicht erforderlich, alle Protokolldetails zu kennen, allerdings hilft es oftmals beim Troubleshooting.
Mittels acme.sh ein Zertifikat beziehen
Im Folgenden beschreiben wir nun den einfachsten Weg, ein Zertifikat von einem ACME-Server zu bekommen. Da der certbot-Client [4] im Internet gut dokumentiert ist, möchten wir an dieser Stelle das Tool acme.sh [5] vorstellen. Hierbei handelt es sich um ein Shell-Skript, das im Gegensatz zu certbot nur wenige Abhängigkeiten zu anderen Softwarepaketen besitzt. Trotzdem ist es vom Funktionsumfang nahezu identisch.
Anstatt das Tool zusammen mit der Let's-Encrypt-Zertifizierungsstelle zu verwenden, können Sie natürlich auch jeden anderen ACME-konformen Server einsetzen. So unterstützen beispielsweise Dogtag [6] oder auch das Identity Management Framework FreeIPA [6] das ACME Protokoll. In diesem Fall müssen Sie allerdings darauf achten, den ACME-Server mithilfe der Option "--server" explizit zu benennen.
Den ACME-Client können Sie unter [5] herunterladen oder ganz einfach wie folgt installieren:
curl https://get.acme.sh | sh -s email=user@example.com
Die Konfiguration finden Sie anschließend unter "~/.acme.sh/" bereits fertig eingerichtet. Um nun für Ihren Account eine Registrierung auf dem ACME-Server zu starten, rufen Sie das Tool wie folgt auf:
acme.sh --register-account
Die eigentliche Zertifikatsanfrage erstellen Sie dann wie im folgenden Befehl. Hierfür wird auf das Tool socat zurückgegriffen, um einen einfachen Webserver auf dem Port 80 zu starten, über den der ACME-Server mit dem Client kommunizieren kann:
acme.sh --issue --standalone -d www.example.com
Hat alles geklappt, lassen sich die Details zu dem soeben ausgestellten Zertifikat mithilfe von openssl
anzeigen:
openssl x509 -in /home/tscherf/.acme.sh/www.example.com/www.example.com.cer -noout -issuer -subject -dates -serial
issuer= /C=US/O=Let's Encrypt/CN=R3
subject= /CN=www.example.com
notBefore=Feb 21 13:00:28 2021 GMT
notAfter=May 22 13:00:28 2021 GMT
serial=03B46ADF0F26B94C19443669ABD0C5100356
Im nächsten Schritt müssen Sie nur noch die vollständige Zertifikatskette in den gewünschten Service einbinden. Um das Tool auch mit anderen Challenge-Typen oder in komplexeren Setups zu verwenden, empfiehlt sich wie immer ein Blick in die Dokumentation [5] der Software.
Fazit
Das ACME-Protokoll erfreut sich immer größerer Beliebtheit. Eine ganze Reihe von Produkten setzt es mittlerweile ein, was dabei hilft, den Einsatz von X.509 weiter zu verbreiten. Mit acme.sh steht ein sehr leichtgewichtiger ACME-Client zur Verfügung, der sich nicht hinter bekannten Clients wie beispielsweise certbot verstecken muss.
(jm)
Link-Codes
[1] Let's-Encrypt-Projektseite:
https://letsencrypt.org/[4] ACME-Certbot-Client:
https://certbot.eff.org/