Das ist aber nicht unbedingt schön, da es viele Abhängigkeiten nachinstalliert und sich eine eigene Python-Umgebung zurecht bastelt.

Daher steht seit längerem auf meiner Todo-Liste, ein möglichst einfaches Shell-Script für die Nutzung der LetsEncrypt-Zertifikate zu verwenden. Heute habe ich das auf einem meiner Server eingerichtet und es soll hier dokumentiert werden.

Verwendet habe ich das Shell-Script acme.sh.

Dies ist kein Howto, wie man LetsEncrypt nutzt; ich gehe davon aus, dass man Webserver usw. bereits darauf eingerichtet hat. Hier geht es nur darum, wie man acme.sh installiert und verwendet.

Installation

Alle Befehle werden als root ausgeführt.

apt-get install socat git
git clone https://github.com/Neilpang/acme.sh.git
cd acme.sh
./acme.sh --install \
--home /root/.acme.sh \
--certhome /etc/acme/certs \
--accountemail "mail@bladomain.tld" \
--nocron

Auf die angegebene E-Mail-Adresse erhält man vor Ablauf eines Zertifikats entsprechende Erinnerungen.

Jetzt kann man das Verzeichnis acme.sh löschen. Das installierte Script hat selbst einen Update-Mechanismus.

Ausloggen und wieder einloggen, damit das Alias nutzbar wird.

Neue(s) Zertifikat(e) beantragen

Wieder alles als root ausführen.

Man muss den Webserver beenden, damit der entsprechende Port vom Standalone-Server (socat) genutzt werden kann.

systemctl stop apache2
acme.sh --tls --issue -d mumble.natenom.com -d m.natenom.com

Die Ausgabe sieht so aus:

[Fri Nov 10 03:56:59 CET 2017] Standalone tls mode.
[...]
[Fri Nov 10 03:57:00 CET 2017] Registering account
[Fri Nov 10 03:57:02 CET 2017] Registered
[Fri Nov 10 03:57:03 CET 2017] Update account tos info success.
[Fri Nov 10 03:57:03 CET 2017] ACCOUNT_THUMBPRINT='xxxxxxxxxxxxxxxxxxxxxxxx'
[Fri Nov 10 03:57:03 CET 2017] Creating domain key
[Fri Nov 10 03:57:04 CET 2017] The domain key is here: /etc/acme/certs/mumble.natenom.com/mumble.natenom.com.key
[Fri Nov 10 03:57:04 CET 2017] Multi domain='DNS:mumble.natenom.com,DNS:m.natenom.com'
[Fri Nov 10 03:57:04 CET 2017] Getting domain auth token for each domain
[Fri Nov 10 03:57:04 CET 2017] Getting webroot for domain='mumble.natenom.com'
[Fri Nov 10 03:57:04 CET 2017] Getting new-authz for domain='mumble.natenom.com'
[Fri Nov 10 03:57:05 CET 2017] The new-authz request is ok.
[...]
[Fri Nov 10 03:57:11 CET 2017] Verifying:mumble.natenom.com
[Fri Nov 10 03:57:11 CET 2017] Starting tls server.
[Fri Nov 10 03:57:11 CET 2017] Multi domain='DNS:xxxxxxxxxxxx.acme.invalid'
[Fri Nov 10 03:57:16 CET 2017] Success
/root/.acme.sh/acme.sh: line 3589: 20206 Terminated $__S_OPENSSL > /dev/null 2>&1
[...]
[Fri Nov 10 03:57:48 CET 2017] Verify finished, start to sign.
[Fri Nov 10 03:57:49 CET 2017] Cert success.
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
[Fri Nov 10 03:57:49 CET 2017] Your cert is in /etc/acme/certs/mumble.natenom.com/mumble.natenom.com.cer
[Fri Nov 10 03:57:49 CET 2017] Your cert key is in /etc/acme/certs/mumble.natenom.com/mumble.natenom.com.key
[Fri Nov 10 03:57:49 CET 2017] The intermediate CA cert is in /etc/acme/certs/mumble.natenom.com/ca.cer
[Fri Nov 10 03:57:50 CET 2017] And the full chain certs is there: /etc/acme/certs/mumble.natenom.com/fullchain.cer
systemctl start apache2

Die Zertifikat relevanten Dateien sind danach im Verzeichnis /etc/acme/certs zu finden und in den entsprechenden Konfigurationsdateien z. B. des Webservers kann darauf verwiesen werden.

Zertifikat(e) erneuern

Eine Liste aller Zertifikate erhält man mit:

acme.sh --list

Und erneuern kann man mit:

systemctl stop apache2
acme.sh --tls --renew-all

# Oder nur bestimmte Certs erneuern
# acme.sh --tls --renew -d mumble.natenom.com -d m.natenom.com

systemctl start apache2

Ohne root-Rechte, fast

Mit etwas mehr Aufwand kann man das ganze auch noch ohne root-Rechte nutzen, zumindest alles bis auf den Standalone-Server. Denn nur root darf auf Ports ≤1023 lauschen.

Damit werde ich mich vielleicht später noch beschäftigen; insgesamt ist acme.sh aber auch mit root-Rechten wesentlich schöner als das alte Python-Script.

Cron/Systemd timer

• Cron, siehe hier (nach cron suchen).
• Systemd timer, siehe hier.

Hilfe

Für alles weitere siehe:

acme.sh --help

Siehe heise.de/security/meldung/TLS-Zertifikate-CAAs-sollen-Zertifizierungsstellen-an-die-Leine-legen.

Habe das nur zufällig gelesen, daher soll das hier abgelegt sein; sonst hat man beim nächsten Zertifikat-Update von LetsEncrypt kein Zertifikat mehr :)

Wenn man das Vertrauen für ein Zertifikat nur auf „Full“ gesetzt hat, dann verweigert KMail das Verschlüsseln damit. Das Zertifikat lässt sich in der Auswahl zwar markieren, aber der OK-Knopf ist ausgegraut.

Damit es funktioniert, muss man das Vertrauen auf „Ultimate“ setzen.

Will man von KMail heraus ein Zertifikat bearbeiten, so öffnet sich per Voreinstellung kleopatra, zumindest bei mir auf Arch Linux. Dort ist es aber gar nicht möglich, „Ultimate“ einzustellen. Und auch der Begleittext zeigt mir was von wegen „machen sie das nur, wenn es sich um ihr eigenes Zertifikat handelt, dessen Passphrase sie haben…“.

Gut, dann machen wir das eben in kgpg, dieses stürzt jedoch reproduzierbar ab, wenn man „Ultimate“ auswählt und auf OK oder Anwenden klickt.

Also setzt man das Vertrauen auf „Ultimate“ in der Shell mit gpg:

gpg --edit-key KEYID

trust

5

q

Danach funktioniert das Verschlüsseln in KMail.

Öffnet man jetzt aber das Zertifikat in kleopatra, dann wird angezeigt, dass das Vertrauen aktuell unbekannt sei.

In kgpg dagegen wird es richtig angezeigt.

Ich hasse es, dass man für solche Dinge immer gleich den ganzen Abend testen muss…

Habe ich da etwas nicht richtig verstanden, oder ist das total beschissen umgesetzt?

Besonders interessant ist das letzte Beispiel, bei dem bei einem bestimmten Zertifikat ein definiertes Kommando ausgeführt wird.

http://www.debian-administration.org/article/685/Restricting_SSH_logins_to_particular_IP_addresses.