🛖 LetsEncrypt automatisiert mit RFC2136

Einleitung

Für Sicherheit von Schlüsseln einfach die 3 🐷 Schweinchen merken:

🛖 LetsEncrypt-CA mit Internet auf nicht-freier Maschine

🏚️ LetsEncrypt-CA mit Internet auf freier Maschine

🏰 eigene ED25519-CA ohne Internet auf freier Maschine

Wir behandeln hier 🛖 und 🏚️, zur 🏰 eigenen ED25519-CA geht es hier

Installieren Sie für LetsEncrypt im Idealfall auf dem Server der das Zertifikat braucht direkt certbot mit RFC2136 Support.

Sie haben auf lokalen Diensten / Servern i.d.R. keinen Webserver unter der Sub-Domain laufen um ACME-Challenges automatisch zu halten, daher können Sie zumindest auf Krei.se-Nameservern Ihren RFC2136-Zugang für die Aktualisierung von DNS-Einträgen nutzen um lokale Server zu authentifizieren.

Dafür ist im DNS-Server hinterlegt, dass ihr certbot-rndc-key allen Einträgen für subdomain.krei.se einen TXT-Eintrag hinzufügen darf - und mehr braucht certbot nicht.

Diesen Schlüssel können Sie also halbwegs bedenkenlos für certbot nutzen - er kann keine IPs verändern, das darf nur ihr Haupt-rfc2136-Schlüssel

Für Krei.se-Subdomains sieht diese Konfiguration mit Schlüssel wie folgt aus:

# Target DNS server (IPv4 or IPv6 address, not a hostname)
# 116.202.31.141 -- ns1.krei.se
dns_rfc2136_server = 116.202.31.141
# Target DNS port
dns_rfc2136_port = 53
# TSIG key name
dns_rfc2136_name = subdomain-krei-se-certbot_rndc-key
# TSIG key secret
dns_rfc2136_secret = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==
# TSIG key algorithm
dns_rfc2136_algorithm = HMAC-SHA512
# TSIG sign SOA query (optional, default: false)
dns_rfc2136_sign_query = false

🧑‍🔧 Installation und erstes Zertifikat

apt install certbot python3-certbot-dns-rfc2136

Speichern Sie jetzt die Konfiguration unter /etc/letsencrpt/ns1.krei.se.rfc2136.ini ab.

chown 600 ns1.krei.se.rfc2136.ini stellt sicher, dass nur root / certbot die .ini lesen darf.

Starten Sie einmalig certbot certonly und wählen Sie

1: Obtain certificates using a DNS TXT record (if you are using BIND for DNS). (dns-rfc2136)

Mail-Adresse eingeben an die Benachrichtigungen gehen sollen wenn Zertifikate abzulaufen drohen (certbot@domain.tld)

Domain für das Haupt-Zertifikat / das erste was Sie brauchen angeben, z.B. mail.domain.tld

Bedingungen akzeptieren.

Pfad zur Konfiguration angeben: /etc/letsencrypt/ns1.krei.se.rfc2136.ini

Das wars schon. Der Krei.se-Nameserver sollte Ihren Schlüssel schon kennen, wenn Sie selbst einen nameserver betreiben hilft die Dokumentation des Plugins weiter: https://certbot-dns-rfc2136.readthedocs.io/en/stable/

Certbot merkt sich diese Einstellungen unter /etc/letsencrypt/renewal, solange Sie also keine neuen Domains brauchen oder nur hinzufügen sparen Sie sich den Verweis auf die RFC2136-Konfiguration

🗝️ weitere LetsEncrypt-Schlüssel hinzufügen

Ihr Zertifikat können Sie um weitere Domains und auch wildcard-Zertifikate erweitern:

certbot certonly -d mail.domain.tld,*.domain.tld --expand

⏳ Zertifikate automatisch verteilen

LetsEncrypt speichert alle Schlüssel nur für root lesbar, Zertifikate sind für alle Nutzer lesbar - bitte bedenken. Wenn Sie Schlüssel für nicht-root Nutzer lesbar brauchen empfehle ich renewal-hooks, hier ein Beispiel für chown, denn der Chat-Server ejabberd braucht die Schlüssel z.B. für die Gruppe ejabberd lesbar:

/etc/letsencrypt/renewal-hooks/deploy/ejabberd.sh

#!/bin/bash

# $RENEWED_DOMAINS enthält die aktualisierten Domains mit Leerzeichen getrennt (i.d.R. nur eine)
# $RENEWED_LINEAGE enthält den Pfad zu /etc/letsencrypt/live/domain.tld

if grep --quiet "chat.domain.tld" <<< "$RENEWED_DOMAINS"; then
cp -L $RENEWED_LINEAGE/fullchain.pem /etc/ejabberd/ssl.fullchain.pem
cp -L $RENEWED_LINEAGE/privkey.pem /etc/ejabberd/ssl.privkey.pem
chown root:ejabber /etc/ejabberd/ssl.*.pem
chmod 660 /etc/ejabberd/ssl.*.pem
systemctl restart ejabberd

fi

und ein Beispiel um Schlüssel auf openwrt-Router zu übertragen. acme-acmesh-dnsapi kann das übrigens auch direkt auf den Routern (Punkt 7. in der README: https://github.com/acmesh-official/acme.sh/wiki/dnsapi#7-use-nsupdate-to-automatically-issue-cert)

/etc/letsencrypt/renewal-hooks/deploy/openwrt.sh

#!/bin/bash

# $RENEWED_DOMAINS enthält die aktualisierten Domains mit Leerzeichen getrennt (i.d.R. nur eine)
# $RENEWED_LINEAGE enthält den Pfad zu /etc/letsencrypt/live/domain.tld

if grep --quiet "router.domain.tld" <<< "$RENEWED_DOMAINS"; then
    scp -O $RENEWED_LINEAGE/cert.pem root@router.domain.tld:/etc/uhttpd.crt
    scp -O $RENEWED_LINEAGE/privkey.pem root@router.domain.tld:/etc/uhttpd.key
    ssh root@router.domain.tld "/etc/init.d/uhttpd restart"
fi

Checken, dass es auf eine neue Zeile endet und das Skript mit chmod +x script.sh ausführbar machen.

📝 Wer den Deploy testen will braucht unter Debian Bookworm mit Certbot 2.1.0 derzeit noch certbot certonly -d 'service.domain.tld'

📝 Ab Certbot 3 gibt es wohl --run-deploy-hooks in Verbindung mit --dry-run um einen Deploy-Hook zu testen. Da sich certbot manuell nur über pip updaten lässt lassen wir diesen Edge-Case hier weg.

Hinweis zu 🗝️ ECDSA und 🔑 ED25519 Schlüsseln

ECDSA ist relativ sicher und wird von allen modernen Browsern und Client-Software akzeptiert. Solange Sie nicht Angst vor der CIA oder der Regierung haben und nur Transport-Verschlüsselung brauchen die Mitlesen erschwert genügen diese Schlüssel vollauf.

Jetzt das große Aber:

Wichtig ist vielmehr WO Sie die Schlüssel generieren, ob LetsEncrypt die nun signiert oder welcher Algorithmus genutzt wird ist nebensächlich. Für sichere Schlüssel empfehle ich immer eine lokale CA die auf einem 🦌 Libreboot-System (gern ohne Netzwerk) läuft und nur dort Schlüssel generiert.

ED25519 stellt zudem sicher, dass auch Implementierungsfehler und kompromittierte Zufallsgeneratoren kein Problem darstellen, denn ED25519 braucht keine Zufallszahlen.

ECDSA benötigt immer eine frische Zufallszahl k, die PlayStation 3 wurde z.B. auf diese Art geknackt. Mit einem 🦌 Libreboot-System können Sie bis zum BIOS herunter sicherstellen, dass der Zufallsgenerator nicht vorhersehbare Zahlen ausgibt.

ED25519 braucht keine Zufallszahlen und hängt nur von ihrem Passwort ab. Signieren Sie hier Schlüssel lokal brauchen Sie also nur eine Maschine ohne Netzwerk um halbwegs sicher zu sein, dass der Schlüssel nicht mitgeschrieben wird.

Am nähesten zu 100% Sicherheit kommen Sie daher mit einem 🦌 Libreboot-System ohne Internet, was eine 🏰 ED25519-CA nutzt und Schlüssel nur über ein Speichermedium verteilt. Da ich Ihnen ohnehin wenigstens 1 Libreboot-System einrichte, ob nun als Server, Workstation, Laptop oder Router, etc. macht es Sinn wenigstens für den internen Datenverkehr und das VPN diesen Algorithmus zu nutzen.

Der Unterschied ist schwer zu erklären, Sie brauchen dafür das Setup daheim - man schläft damit einfach ruhiger :)