Anmelden
Neue Hetzner DNS API und acme.sh
Wenn Sie Ihre Domains bei Hetzner verwalten, wurden Sie in den vergangenen Monaten dazu aufgefordert, die Domains in ein neues DNS-Verwaltungstool zu migrieren. Das gelingt zumeist problemlos (zumindest in meinen Fällen).
Allerdings hat Hetzner nun auch die alte API zur DNS-Administration ausgeschaltet. Falls Sie bei der Ausstellung von Let’s-Encrypt-Zertifikate die alte DNS-API verwendet haben, scheitert die Erneuerung der Zertifikate mit unspezifischen Fehlern (invalid domain).
Ich verwende zur Zertifikatsausstellung normalerweise acme.sh und bin auf das Problem erst aufmerksam geworden, als das erste Zertifikat auf einem meiner Server abgelaufen ist. (Ein ordentliches Monitoring hätte dieses Hoppala natürlich verhindert. Es war nicht die wichtigste Domain …)
Ich habe keinen Weg gefunden, den Zertifiktaserneuerungsmechanismus von acme.sh irgendwie zu aktualisieren, also gewissermaßen die vorhandene Konfiguration auf die neue API zu migrieren. Die Lösung bestand darin, in der Hetzner-Console einen neuen API-Key einzurichten und dann mit acme.sh die Zertifikate neu auszustellen. Falls Sie viele Server administrieren, ist das, gelinde formuliert, unbequem …
Hinweis: Sie sind von diesem Problem NICHT betroffen, wenn die Domain-Validierung mit anderen Verfahren erfolgt, z.B. durch das Ablegen einer Datei in
/var/www/html. Dieser Blog-Artikel bezieht sich explizit auf den Zertifikatserneuerungsprozess, wenn Sie bisher die alte Hetzner-DNS-API in Kombination mitacme.shverwendet haben!
API-Key
Zuerst brauchen Sie einen neuen API-Key. Den erstellen Sie in der Hetzner-Konsole unter Security / API-Tokens. Der Token muss read/write sein, weil acme.sh für die Validierung Ihrer Domain vorübergehend eine zusätzlichen DNS-Eintrag hinzufügt. Den vollständigen Token-Code können Sie nur einmal ansehen/kopieren. Hetzner bietet aktuell keine Möglichkeit, die Gültigkeit des Keys irgendwie einzuschränken.
Ein RW-Key vermittelt damit weit mehr Rechte, als zur DNS-Administration erforderlich wären. Das ist mir ein wenig unheimlich, aber aktuell nicht zu ändern.
acme.sh aktualisieren, Zertifikate neu erstellen und einrichten
acme.sh muss das Verfahren Hetzner Cloud DNS API unterstützen. Dieses ist verhältnismäßig neu. Eventuell müssen Sie Ihre vorhandene acme.sh-Installation aktualisieren:
acme.sh --upgrade
Mit acme.sh --list gewinnen Sie einen Überblick, welche Zertifikate es auf dem Server gibt (Output verkürzt):
acme.sh --list
Main_Domain SAN_Domains CA Created Renew
eine-firma.de www.eine-firma.de LetsEncrypt.org 2026-05-12 2026-07-11
mail.eine-firma.de smtp.eine-firma.de,... LetsEncrypt.org 2026-05-12 2026-07-11
Jetzt speichern Sie das Token in einer Umgebungsvariablen und wiederholen die Kommandos zur Zertifikatsausstellung sowie zum Kopieren der Zertifikate an den Zielort, wobei Sie die bisherige acme.sh-Option --dns dns-hetzner durch --dns dns-hetznercloud ersetzen.
Die folgenden Beispielkommandos zeigen die Neuausstellung der Zertifikate und deren Deployment. Sofern Sie exakt die gleichen Namen/Pfade wie bei der ursprünglichen Zertifikatsausstellung verwenden, sollte danach alles wieder funktionieren (d.h. der Webserver verwendet die neuen Zertifikate).
export HETZNER_Token='oqCF...'
# wichtig ist die geänderte Option --dns dns_hetznercloud
acme.sh --issue --dns dns_hetznercloud --server letsencrypt \
-d eine-firma.de -d www.eine-firma.de
# Zertifikate in /etc/letsencrypt speichern (setzt voraus, dass
# Apache so konfiguriert ist, dass das Programm die Zertifikate
# von dort liest)
acme.sh --install-cert -d eine-firma.de \
--cert-file /etc/letsencrypt/eine-firma.de.cert \
--key-file /etc/letsencrypt/eine-firma.de.key \
--fullchain-file /etc/letsencrypt/eine-firma.de.fullchain \
--reloadcmd 'systemctl restart apache2'
Sie müssen die Kommandos natürlich an Ihre Gegebenheiten anpassen.
