Nächste: DNS-Dienste, Vorige: Web-Dienste, Nach oben: Dienste [Inhalt][Index]
Das Modul (gnu services certbot) stellt einen Dienst zur Verfügung,
um automatisch ein gültiges TLS-Zertifikat von der Zertifikatsautorität
Let’s Encrypt zu beziehen. Mit diesen Zertifikaten können Informationen
sicher über HTTPS oder andere TLS-basierte Protokolle übertragen werden, im
Wissen, dass der Client die Authentizität des Servers überprüfen wird
können.
Let’s Encrypt macht das
certbot-Werkzeug verfügbar, mit dem der Zertifizierungsvorgang
automatisiert werden kann. Das Werkzeug erzeugt zunächst auf sichere Weise
einen Schlüssel auf dem Server und stellt dann eine Anfrage an die
Let’s-Encrypt-Zertifikatsautorität („Certificate Authority“, kurz CA), den
Schlüssel zu signieren. Die Zertifikatsautorität prüft mit einem
Challenge-Response-Protokoll, dass die Anfrage auch wirklich vom fraglichen
Rechner (auch „Host“ genannt) kommt, wozu der Server über HTTP seine Antwort
geben muss. Wenn dieses Protokoll erfolgreich befolgt wurde, signiert die
Zertifikatsautorität den Schlüssel, woraus sich ein Zertifikat
ergibt. Dieses Zertifikat ist eine begrenzte Zeit lang gültig, daher muss
der Server für eine andauernde Bereitstellung von TLS-Leistungen immer
wieder neu der Zertifikatsautorität eine Bitte um die Erneuerung der
Signatur zukommen lassen.
Mit dem certbot-Dienst wird dieser Prozess automatisiert. Er sorgt dafür, dass am Anfang Schlüssel erzeugt werden und eine erste Zertifizierungsanfrage an den Dienst von Let’s Encrypt gestellt wird. Weiterhin ist das Challenge-/Response-Verfahren per Web-Server integriert. Das Zertifikat wird auf die Platte geschrieben und automatisch periodisch erneuert und bei der Erneuerung anfallende Aufgaben werden erledigt (z.B. das Neuladen von Diensten und das Kopieren von Schlüsseln mit entsprechenden Berechtigungen).
Certbot wird zweimal täglich zu einer zufälligen Minute der Stunde ausgeführt. Es tut so lange nichts, bis eine Erneuerung Ihrer Zertifikate fällig wird oder sie gesperrt wurden, durch regelmäßige Ausführung bekommen Sie aber die Chance, dass Ihr Server am Netz bleibt, wenn Let’s Encrypt eine Sperrung aus irgendeinem Grund anordnet.
Durch die Nutzung dieses Dienstes stimmen Sie dem „ACME Subscriber Agreement“ zu, das Sie hier finden:: https://acme-v01.api.letsencrypt.org/directory.
Ein Diensttyp für den certbot-Client für Let’s Encrypt. Sein Wert
muss ein certbot-configuration-Verbundsobjekt wie in diesem Beispiel
sein:
(service certbot-service-type
(certbot-configuration
(email "foo@example.net")
(certificates
(list
(certificate-configuration
(domains '("example.net" "www.example.net")))
(certificate-configuration
(domains '("bar.example.net")))))))
Siehe unten für Details zur certbot-configuration.
Datentyp, der die Konfiguration des certbot-Dienstes
repräsentiert. Dieser Typ verfügt über die folgenden Parameter:
package (Vorgabe: certbot)Das certbot-Paket, das benutzt werden soll.
webroot (Vorgabe: /var/www)Das Verzeichnis, aus dem heraus die Dateien für den Challenge-/Response-Prozess von Let’s Encrypt angeboten werden sollen.
certificates (Vorgabe: '())Eine Liste der certificates-configuration-Objekte, für die
Zertifikate und Anfragesignaturen erzeugt werden. Für jedes Zertifikat gibt
es einen name-Eintrag und mehrere domains.
email (Vorgabe: #f)Optional die E-Mail-Adresse, die als Kontakt für die Registrierung und das Wiedererlangen dienen soll. Es wird empfohlen, sie anzugeben, weil Sie darüber wichtige Mitteilungen über Ihr Konto und ausgestellte Zertifikate mitbekommen können.
server (Vorgabe: #f)Optional eine andere URL des ACME-Servers. Wenn sie festgelegt wird, ersetzt sie die Voreinstellung von Certbot, nämlich die URL des Let’s-Encrypt-Servers.
rsa-key-size (Vorgabe: 2048)Wie groß der RSA-Schlüssel sein soll.
default-location (Vorgabe: siehe unten)Die vorgegebene nginx-location-configuration. Weil certbot
„Challenges“ und „Responses“ anbieten muss, muss durch ihn ein Web-Server
ausgeführt werden können. Das tut er, indem er den nginx-Webdienst
mit einer nginx-server-configuration erweitert, die auf den
domains auf Port 80 lauscht und eine
nginx-location-configuration für den URI-Pfad-Teilraum
/.well-known/ umfasst, der von Let’s Encrypt benutzt wird. Siehe
Web-Dienste für mehr Informationen über diese
nginx-Konfigurationsdatentypen.
Anfragen an andere URL-Pfade werden mit der default-location
abgeglichen. Wenn sie angegeben wurde, wird sie zu jeder
nginx-server-configuration hinzugefügt.
Nach Vorgabe stellt die default-location eine Weiterleitung von
http://domain/… nach https://domain/… her. Sie
müssen dann nur noch festlegen, was Sie auf Ihrem Webauftritt über
https anbieten wollen.
Übergeben Sie #f, um keine default-location vorzugeben.
Der Datentyp, der die Konfiguration eines Zertifikats repräsentiert. Dieser Typ hat die folgenden Parameter:
name (Vorgabe: siehe unten)Dieser Name wird vom Certbot intern zum Aufräumen und in Dateipfaden
benutzt; er hat keinen Einfluss auf den Inhalt des erzeugten Zertifikats. Um
Zertifikatsnamen einzusehen, führen Sie certbot certificates aus.
Die Vorgabe ist die erste angegebene Domain.
domains (Vorgabe: '())Die erste angegebene Domain wird als Name des Zertifikatseigentümers („Subject CN“) benutzt und alle Domains werden als alternative Namen („Subject Alternative Names“) auf dem Zertifikat stehen.
challenge (Vorgabe: #f)Welche Art von Challenge durch den Certbot ausgeführt wird. Wenn #f
angegeben wird, wird die HTTP-Challenge voreingestellt. Wenn ein Wert
angegeben wird, wird das Plugin benutzt, das auch bei manuellen Ausführungen
benutzt wird (siehe authentication-hook, cleanup-hook und die
Dokumentation unter https://certbot.eff.org/docs/using.html#hooks),
und Let’s Encrypt wird dazu berechtigt, die öffentliche IP-Adresse der
anfordernden Maschine in seinem Protokoll zu speichern.
csr (Vorgabe: #f)Der Dateiname der Zertifizierungsanfrage („Certificate Signing Request“,
CSR) im DER- oder PEM-Format. Wenn #f angegeben wird, wird kein
solches Argument an den Certbot übermittelt. Wenn ein Wert angegeben wird,
wird der Certbot ihn anstelle einer selbsterstellten CSR verwenden. Die in
domains genannten Domänen müssen dabei konsistent sein mit denen, die
in der CSR-Datei aufgeführt werden.
authentication-hook (Vorgabe: #f)Welcher Befehl in einer Shell zum Antworten auf eine Zertifikats-„Challenge“
einmalig ausgeführt wird. Für diesen Befehl wird die Shell-Variable
$CERTBOT_DOMAIN die Domain enthalten, für die sich der Certbot
authentisiert, $CERTBOT_VALIDATION enthält die
Validierungs-Zeichenkette und $CERTBOT_TOKEN enthält den Dateinamen
der bei einer HTTP-01-Challenge angefragten Ressource.
cleanup-hook (Vorgabe: #f)Welcher Befehl in einer Shell für jede Zertifikat-„Challenge“ einmalig
ausgeführt wird, die vom auth-hook beantwortet wurde. Für diesen
Befehl bleiben die Shell-Variablen weiterhin verfügbar, die im
auth-hook-Skript zur Verfügung standen, und außerdem wird
$CERTBOT_AUTH_OUTPUT die Standardausgabe des auth-hook-Skripts
enthalten.
deploy-hook (Vorgabe: #f)Welcher Befehl in einer Shell für jedes erfolgreich ausgestellte Zertifikat
einmalig ausgeführt wird. Bei diesem Befehl wird die Shell-Variable
$RENEWED_LINEAGE auf das Unterverzeichnis für die aktuelle
Konfiguration zeigen (zum Beispiel
‘"/etc/letsencrypt/live/example.com"’), in dem sich die neuen
Zertifikate und Schlüssel befinden. Die Shell-Variable
$RENEWED_DOMAINS wird eine leerzeichengetrennte Liste der erneuerten
Zertifikatsdomänen enthalten (zum Beispiel ‘"example.com
www.example.com"’.
start-self-signed? (Vorgabe: #t)Ob bei der Aktivierung des Systems für den Anfang ein selbstsigniertes
Zertifikat erzeugt werden soll. Diese Option ist besonders geeignet, weil so
nginx schon in der Lage ist, zu starten, noch bevor certbot
ausgeführt wurde, denn certbot kann nur ausgeführt werden, wenn
nginx läuft und damit HTTP-Challenges beantwortet werden können.
Für jede certificate-configuration wird das Zertifikat in
/etc/certs/name/fullchain.pem und der Schlüssel in
/etc/certs/name/privkey.pem gespeichert.
Nächste: DNS-Dienste, Vorige: Web-Dienste, Nach oben: Dienste [Inhalt][Index]