Am 15. Januar 2026 hat Let’s Encrypt eine Änderung scharf geschaltet, die jeden Linux-Admin, jeden Windows-Server-Betreiber und jedes DevOps-Team betrifft: Zertifikate mit einer Laufzeit von nur noch 160 Stunden, also gut sechs Tagen, sind seitdem allgemein verfügbar. Wer seine TLS-Zertifikate bisher halbjährlich von Hand erneuert hat, kommt mit dieser Taktung nicht mehr hinterher. Ohne einen zuverlässigen ACME-Client geht ab sofort nichts mehr. Drei Namen tauchen in fast jeder Serverkonfiguration auf, sobald es um automatisierte TLS-Zertifikate geht: Certbot, acme.sh und win-acme. Alle drei sprechen das gleiche ACME-Protokoll, alle drei holen kostenlose Zertifikate von Let’s Encrypt, aber sie unterscheiden sich in Architektur, Plattform-Support und Plugin-Tiefe erheblich. Dieser Vergleich zeigt anhand von GitHub-Daten, offiziellen Release-Notes und Herstellerangaben, welcher Client zu welcher Infrastruktur passt.

Was ist ein ACME-Client und warum ist er 2026 unverzichtbar?

Ein ACME-Client ist die Software, die zwischen einem Server und einer Zertifizierungsstelle wie Let’s Encrypt vermittelt. Er beweist per HTTP- oder DNS-Challenge, dass der Antragsteller tatsächlich die Kontrolle über eine Domain besitzt, fordert anschließend das Zertifikat an und kümmert sich um die fristgerechte Erneuerung. Das Automated Certificate Management Environment-Protokoll (ACME) ist dabei offener Standard, den jeder Client implementieren kann, solange er sich an die Spezifikation hält.

Standardisiert ist ACME seit 2019 als RFC 8555 bei der IETF. Davor war das Protokoll bereits Grundlage von Let’s Encrypt, das die gemeinnützige Internet Security Research Group (ISRG) im Jahr 2015 gestartet hat, um kostenlose TLS-Verschlüsselung für das gesamte Web verfügbar zu machen. Wer die manuelle, clientlose Ausstellung eines einzelnen Zertifikats einmal nachvollziehen möchte, findet die Grundlagen dazu in unserer Schritt-für-Schritt-Anleitung zur Einrichtung eines Let’s-Encrypt-Zertifikats. Certbot war von Anfang an der offizielle Referenzclient dazu, acme.sh und win-acme entstanden kurz danach als unabhängige Community-Projekte für Nutzergruppen, die Certbot aus technischen Gründen nicht einsetzen konnten oder wollten.

Bis vor Kurzem war das ein eher gemütliches Geschäft. Zertifikate liefen 90 Tage, eine monatliche Cronjob-Prüfung reichte locker aus. Das hat sich geändert. Nach eigenen Angaben stellt Let’s Encrypt mittlerweile rund 10 Millionen Zertifikate pro Tag aus, und mit der allgemeinen Verfügbarkeit der 6-Tage- und IP-Adress-Zertifikate seit Januar 2026 wächst der Automatisierungsdruck spürbar. Wer das optionale “shortlived”-Profil nutzt, bekommt Zertifikate mit einer Gültigkeit von 160 Stunden statt 90 Tagen. Und das ist erst der Anfang: Laut der offiziellen Roadmap von Let’s Encrypt wird das tlsserver-Profil ab dem 13. Mai 2026 standardmäßig nur noch 45 Tage gültige Zertifikate ausstellen, das reguläre Standardprofil folgt im Februar 2027 mit 64 Tagen und soll bis 2028 ebenfalls auf 45 Tage sinken. Ein manuell gepflegter Zertifikatsbestand wird in diesem Takt zum Risiko. Genau hier setzen Certbot, acme.sh und win-acme an.

Certbot im Detail: Der Platzhirsch der Electronic Frontier Foundation

Certbot wird von der Electronic Frontier Foundation (EFF) entwickelt, derselben Organisation, die auch hinter Let’s Encrypt steht. Das Tool ist in Python geschrieben, steht unter der Apache License 2.0 und gilt seit Jahren als Referenzimplementierung für Linux-Server. Laut der offiziellen GitHub-Seite von Certbot zählt das Projekt aktuell 33.256 Sterne und 3.504 Forks. Die aktuelle Version ist v5.8.0, veröffentlicht am 1. September 2026, und die Entwicklung bleibt aktiv: Ende September 2026 gingen noch Commits wie die Ergänzung eines neuen DNS-Plugins für enum-dns in den Hauptzweig ein.

Certbot bringt native Plugins für Apache und Nginx mit, die Konfigurationsdateien direkt anpassen können, inklusive automatischer HTTPS-Weiterleitung. Wer das nicht möchte, nutzt den Webroot-Modus oder den Standalone-Modus für Server ohne laufenden Webserver. Im offiziellen Repository liegen 13 eigenständige DNS-Plugins für Anbieter wie Cloudflare, DigitalOcean, Google Cloud, Route53, OVH und RFC2136-kompatible Nameserver, über die Wildcard-Zertifikate per DNS-01-Challenge möglich sind. Mit Version 5.3.0 im März 2026 kam die Option --ip-address hinzu, mit 5.4.0 folgte die Unterstützung für IP-Adress-Zertifikate auch im Webroot-Plugin. Certbot ist damit einer der ersten großen Clients, der die neuen Let’s-Encrypt-Funktionen offiziell abbildet.

sudo certbot certonly --nginx -d example.de -d www.example.de
sudo certbot renew --dry-run

Für Container-Umgebungen stellt das Projekt ein offizielles Docker-Image bereit. Laut Docker Hub kommt certbot/certbot auf 336.242.996 Downloads, eine Zahl, die kein anderer der drei Clients auch nur annähernd erreicht. Wer Certbot in Kubernetes einsetzt, trifft außerdem häufig auf cert-manager, das ACME-Anfragen im Hintergrund an eine kompatible Infrastruktur weiterreicht.

Installation und Paketpflege

Auf Debian und Ubuntu liegt Certbot in den offiziellen Paketquellen, allerdings häufig in einer älteren Version als auf GitHub. Die EFF selbst empfiehlt deshalb die Installation über snapd, um automatisch die jeweils aktuelle Version mit allen Sicherheitsupdates zu erhalten. Alternativ lässt sich Certbot über pip in einer eigenen virtuellen Python-Umgebung installieren, was vor allem auf Systemen ohne snapd oder in minimalistischen Container-Images sinnvoll ist. Die Paketvielfalt ist zugleich eine Fehlerquelle: Wer Certbot über drei verschiedene Wege parallel installiert, läuft Gefahr, dass sich Konfigurationsdateien und Zertifikatsablagen in unterschiedlichen Verzeichnissen ansammeln.

acme.sh im Detail: Der Shell-Script-Champion mit den meisten Sternen

acme.sh verfolgt einen radikal anderen Ansatz. Das gesamte Tool ist ein reines POSIX-Shell-Skript, das außer curl oder wget sowie OpenSSL für die eigentliche Schlüssel- und Zertifikatsverarbeitung keine weiteren Abhängigkeiten braucht. Keine Python-Laufzeitumgebung, kein .NET, kein Paketmanager-Ballast. Gerade auf schlanken Alpine-Containern oder alten Embedded-Linux-Systemen ist das ein handfester Vorteil. Laut der GitHub-Seite des Projekts acmesh-official steht acme.sh bei 47.776 Sternen und 5.678 Forks, womit es beide anderen Clients bei dieser Kennzahl klar hinter sich lässt. Lizenziert ist das Projekt unter der GNU General Public License v3.0, die aktuelle Version 3.1.6 erschien am 20. September 2026.

Der eigentliche Trumpf von acme.sh liegt im DNS-Bereich. Im Ordner dnsapi des Repositorys liegen 198 einzelne Skripte für DNS-Anbieter, von großen Namen wie Route53 oder Cloudflare bis zu kleineren regionalen Registraren, die sonst kaum ein Tool unterstützt. Für Teams, die Wildcard-Zertifikate über mehrere Dutzend Domains bei unterschiedlichen Registraren verwalten, ist diese Breite oft das entscheidende Argument.

curl https://get.acme.sh | sh -s [email protected]
acme.sh --issue --dns dns_cf -d example.de -d "*.example.de"

Nach erfolgreicher Ausstellung lässt sich mit dem Parameter --reloadcmd ein beliebiger Befehl hinterlegen, der den Webserver oder Mail-Server automatisch neu lädt, sobald ein neues Zertifikat vorliegt. Dieser Hook-Mechanismus macht acme.sh auch für Dienste jenseits klassischer Webserver interessant, etwa für Mailserver, VPN-Gateways oder interne APIs, die TLS-Zertifikate benötigen, aber kein eigenes ACME-Plugin mitbringen. Weil acme.sh keine kompilierte Binärdatei ist, lässt sich der komplette Quellcode in wenigen Minuten lesen und auditieren, ein Argument, das sicherheitsbewusste Admins schätzen. Der Nachteil dieser Schlankheit: Es gibt keine zentrale Organisation wie die EFF im Hintergrund, Support läuft über die Community und GitHub Issues. Ein offizielles Docker-Hub-Image mit vergleichbarer Download-Zählung wie bei Certbot existiert nicht, Nutzer binden das Skript meist direkt in eigene Images ein.

Automatisierung ohne zusätzlichen Cronjob-Aufwand

Ein praktischer Unterschied zu Certbot zeigt sich direkt bei der Installation: Das Setup-Skript von acme.sh trägt standardmäßig selbst einen Cronjob für die tägliche Erneuerungsprüfung ein, ohne dass Admins diesen Schritt manuell nachholen müssen. Auf Systemen mit systemd lässt sich derselbe Mechanismus über einen Timer abbilden. Dieser eingebaute Automatismus erklärt mit, warum acme.sh gerade auf Systemen beliebt ist, die ohne viel manuelle Nacharbeit laufen sollen, etwa auf NAS-Geräten oder in schlanken Cloud-Instanzen, die nur für einen einzigen Zweck existieren.

win-acme im Detail: Die Windows- und IIS-Referenz

Während Certbot und acme.sh in erster Linie für Linux gebaut sind, besetzt win-acme eine Nische, die sonst kaum jemand bedient: Windows Server mit Internet Information Services (IIS). Das Tool ist in C# auf .NET geschrieben und steht unter der Apache License 2.0. Laut dem offiziellen Repository zählt win-acme 5.805 Sterne und 870 Forks, deutlich weniger als die beiden Linux-Clients, was aber auch an der kleineren Zielgruppe liegt. Die GitHub-Projektbeschreibung bringt es auf den Punkt: “Automate SSL/TLS certificates on Windows with ease.”

Bei den formalen Release-Tags wirkt win-acme auf den ersten Blick eingefroren: Der letzte getaggte GitHub-Release ist v2.2.9.1701 vom 25. Mai 2024. Wer sich jedoch die Commit-Historie ansieht, sieht ein anderes Bild. Am 9. Juni 2026 korrigierte das Team noch eine fehlerhafte ZeroSSL-URL, im Dezember 2025 gab es Dokumentations-Updates. Die Entwicklung läuft also weiter, nur eben nicht im klassischen GitHub-Release-Rhythmus, sondern über eigene Installer und die Projekt-Website.

Funktional deckt win-acme DNS-, HTTP- und TLS-ALPN-Validierung ab und bringt laut Repository-Beschreibung Plugins für Azure, Route53, Cloudflare und acme-dns mit, dazu Dutzende weitere Validierungs-Plugins für kleinere Anbieter. Für IIS-Administratoren, die Zertifikate automatisch in den Windows-Zertifikatsspeicher einbinden und IIS-Bindings aktualisieren wollen, bleibt win-acme praktisch ohne ernsthafte Alternative. Das interaktive Menü führt auch weniger erfahrene Admins Schritt für Schritt durch die Einrichtung, ganz ohne Kommandozeilen-Flags auswendig lernen zu müssen.

Interaktiver Modus und unbeaufsichtigter Betrieb

win-acme unterscheidet klar zwischen zwei Betriebsarten. Der interaktive Modus startet ein textbasiertes Menü, über das Admins Schritt für Schritt Quelle, Validierungsmethode und Installationsziel auswählen, ideal für die erste Einrichtung oder gelegentliche manuelle Anpassungen. Für den Produktivbetrieb empfiehlt sich dagegen der unbeaufsichtigte Modus, bei dem sämtliche Parameter über Kommandozeilen-Flags oder eine Konfigurationsdatei vorgegeben werden, sodass der Windows-Taskplaner das Tool ohne jede Nutzerinteraktion periodisch aufrufen kann. Dieser doppelte Ansatz macht win-acme sowohl für IIS-Einsteiger als auch für automatisierte Infrastruktur-Rollouts praktikabel.

Technische Daten im direkten Vergleich

Die folgende Tabelle fasst die wichtigsten technischen Eckdaten zusammen, Stand Oktober 2026, jeweils auf Basis der offiziellen Repositories und Herstellerangaben.

MerkmalCertbotacme.shwin-acme
EntwicklerElectronic Frontier Foundationacmesh-official (Community)win-acme-Team (Community)
ProgrammiersprachePythonPOSIX-ShellC# (.NET)
LizenzApache License 2.0GNU GPL v3.0Apache License 2.0
GitHub-Sterne33.25647.7765.805
GitHub-Forks3.5045.678870
Aktuelle Versionv5.8.0 (1.9.2026)3.1.6 (20.9.2026)v2.2.9.1701 (zuletzt getaggt 5/2024)
BetriebssystemLinux, experimentell macOSLinux, macOS, BSDNur Windows
Native Webserver-PluginsApache, NginxKeine, arbeitet dateibasiertIIS
Offizielle DNS-Plugins13198 DNS-API-SkripteDutzende laut Repository
AbhängigkeitenPython-Laufzeitumgebungcurl/wget, OpenSSL.NET-Laufzeitumgebung
Offizielles Docker-ImageJa, 336.242.996 DownloadsNein, nur Community-ImagesNicht zutreffend (Windows-only)
IP-Adress-Zertifikate laut ChangelogJa, seit v5.3.0/5.4.0Nicht im Detail öffentlich dokumentiertNicht im Detail öffentlich dokumentiert

Auffällig ist die Verteilung der GitHub-Sterne: Nicht das EFF-eigene Certbot führt dieses Ranking an, sondern das schlanke acme.sh. Das lässt sich am ehesten mit der Zielgruppe erklären, viele Entwickler schätzen Tools ohne Laufzeitabhängigkeiten, und ein einzelnes Shell-Skript lässt sich leichter in CI/CD-Pipelines und Container-Builds integrieren als ein Python-Paket mit eigenem virtuellen Environment.

Die letzte Zeile der Tabelle verdient besondere Aufmerksamkeit, weil sie die Zukunftsfähigkeit der drei Clients betrifft. Certbot hat mit den Versionen 5.3.0 und 5.4.0 öffentlich dokumentiert nachgezogen und unterstützt die neuen IP-Adress-Zertifikate von Let’s Encrypt bereits produktiv. Für acme.sh und win-acme liegt dazu keine vergleichbar detaillierte, öffentlich einsehbare Dokumentation vor, was nicht zwangsläufig bedeutet, dass die Funktion fehlt, aber bei einer Entscheidung für zukunftssichere Infrastruktur berücksichtigt werden sollte. Wer auf IP-Adress-Zertifikate oder das shortlived-Profil angewiesen ist, sollte vor dem produktiven Einsatz die aktuelle Dokumentation des jeweiligen Clients direkt prüfen.

Preise und Gesamtkosten: Was ACME-Clients wirklich kosten

Bei der reinen Software-Lizenz ist die Antwort schnell gegeben: Certbot, acme.sh und win-acme kosten alle drei 0 Euro, ebenso wie die Zertifikate von Let’s Encrypt selbst. Wie groß der Preisunterschied zu kostenpflichtigen SSL-Zertifikaten ausfallen kann, zeigt unser separater Vergleich von Let’s Encrypt und kostenpflichtigen SSL-Zertifikaten. Die eigentlichen Kosten entstehen woanders, nämlich beim Betrieb, beim Support und bei der Frage, wie viel Enterprise-Absicherung ein Team wirklich braucht. Wer zusätzlich zu den freien ACME-Clients ein kommerzielles Zertifikats-Lifecycle-Management mit SLA, Audit-Trail und zentraler Steuerung für Tausende Zertifikate benötigt, landet schnell bei Anbietern wie Venafi, Keyfactor oder Sectigo. Wie unser Vergleich dieser drei Plattformen zeigt, kann Enterprise-Zertifikatsmanagement dort von kostenlosen Einstiegsstufen bis zu 500.000 US-Dollar pro Jahr reichen, je nach Zertifikatsvolumen und Compliance-Anforderungen.

LösungLizenzkostenZertifikatskostenSupport-Modell
Certbot0 €0 € (Let’s Encrypt)Community, EFF-Diskussionsforum
acme.sh0 €0 € (Let’s Encrypt)Community, GitHub Issues
win-acme0 €0 € (Let’s Encrypt)Community, GitHub Issues
Enterprise-PKI (z. B. Venafi/Keyfactor)Bis zu 500.000 $/Jahr*Oft inklusiveEnterprise-SLA mit Reaktionszeiten

*Werte laut unserem separaten Vergleich von Sectigo, Keyfactor und Venafi, nicht herstellerseitig als Fixpreis veröffentlicht. Für die große Mehrheit der Websites und internen Server reicht einer der drei kostenlosen ACME-Clients völlig aus. Der Umstieg auf eine kostenpflichtige Plattform lohnt sich meist erst ab einigen Hundert Zertifikaten mit unterschiedlichen Verantwortlichkeiten und Compliance-Pflichten.

Ein Kostenfaktor, der in reinen Lizenzvergleichen gerne untergeht, ist die Einrichtungszeit. Certbot lässt sich auf einem Standard-Nginx- oder Apache-Server meist in fünf bis zehn Minuten produktiv einrichten, weil die nötigen Plugins bereits mitgeliefert werden. acme.sh braucht für einfache HTTP-01-Setups ähnlich wenig Zeit, bei DNS-01-Konfigurationen mit API-Schlüsseln kommen je nach Anbieter weitere zehn bis zwanzig Minuten hinzu. win-acme benötigt durch das geführte Menü in der Regel ebenfalls nur wenige Minuten, allerdings nur, wenn IIS bereits sauber konfiguriert ist. Bei komplexeren Szenarien mit mehreren Dutzend Domains relativiert sich dieser anfängliche Zeitvorteil schnell, dann zählt vor allem, wie gut sich die Konfiguration automatisieren und in bestehende Deployment-Pipelines einbetten lässt.

DNS-Validierung und Plugin-Ökosystem im Vergleich

Das ACME-Protokoll kennt im Kern drei Challenge-Typen, mit denen ein Client die Kontrolle über eine Domain nachweist. Die HTTP-01-Challenge legt eine Antwortdatei unter einem festen Pfad auf dem Webserver ab und eignet sich für einzelne Domains mit offenem Port 80. Die TLS-ALPN-01-Challenge läuft komplett über Port 443 und ist eine Alternative, wenn Port 80 aus Sicherheitsgründen gesperrt bleibt. Für Wildcard-Zertifikate oder Server ohne direkten Port-80-Zugriff führt dagegen kein Weg an der DNS-01-Challenge vorbei. Dabei legt der ACME-Client einen TXT-Eintrag bei der Domain ab, den die Zertifizierungsstelle abfragt. Genau hier trennt sich die Spreu vom Weizen: Certbot deckt mit 13 offiziellen Plugins die großen Namen ab, von Cloudflare über Google Cloud DNS bis Route53. Wer einen exotischeren Anbieter nutzt, braucht ein Drittanbieter-Plugin oder einen generischen RFC2136-Ansatz.

acme.sh spielt in einer anderen Liga: 198 DNS-API-Skripte im offiziellen Repository decken praktisch jeden relevanten Registrar und DNS-Hoster ab, auch kleinere europäische und deutsche Anbieter, die in Certbot oft fehlen. Für Teams, die Domains über mehrere Registrare verteilt verwalten, spart das spürbar Integrationsaufwand. win-acme bringt laut Projektbeschreibung Unterstützung für Azure, Route53, Cloudflare und acme-dns sowie zahlreiche weitere Validierungs-Plugins mit, bleibt aber naturgemäß auf das Windows-Ökosystem fokussiert, in dem Azure DNS besonders häufig vorkommt.

Ein praktischer Nebeneffekt der DNS-01-Challenge: Sie funktioniert auch für interne Server ohne öffentliche IP-Adresse, solange die Domain öffentlich auflösbar ist. Gerade in deutschen Unternehmen mit internen Diensten hinter einer Firewall ist das oft der einzige praktikable Weg zu einem gültigen, von Browsern akzeptierten Zertifikat.

Eine Herausforderung bleibt bei allen drei Clients gleich: die DNS-Propagationszeit. Nachdem der TXT-Eintrag gesetzt wurde, muss er erst bei den weltweit verteilten Resolvern der Zertifizierungsstelle ankommen, bevor die Validierung erfolgreich läuft. Certbot und win-acme warten dafür eine feste, konfigurierbare Zeitspanne ab, bevor sie die Prüfung anstoßen. acme.sh bietet für viele DNS-API-Skripte zusätzlich eine aktive Abfrage, die den eigenen DNS-Eintrag so lange testet, bis er tatsächlich sichtbar ist, was unnötige Wartezeit reduziert, aber bei sehr langsam propagierenden Anbietern trotzdem fehlschlagen kann. Wer wiederholt Timeouts bei der DNS-01-Validierung erlebt, sollte zuerst die Propagationszeit des eigenen DNS-Hosters prüfen, bevor er den ACME-Client für das Problem verantwortlich macht.

Plattform- und Webserver-Unterstützung

Die Plattformfrage entscheidet in der Praxis oft schon vorab, welcher Client überhaupt infrage kommt. Certbot läuft nativ unter Linux-Distributionen wie Debian, Ubuntu oder RHEL und wird dort meist direkt aus den offiziellen Paketquellen installiert. macOS-Unterstützung gilt als experimentell. Für Apache und Nginx gibt es fertige Plugins, die Konfigurationsdateien automatisch anpassen, alle anderen Webserver laufen über den Webroot- oder Standalone-Modus.

acme.sh ist plattformunabhängiger, weil es nur eine POSIX-kompatible Shell voraussetzt. Linux, macOS und BSD-Systeme funktionieren gleichermaßen, auch auf NAS-Systemen von Synology oder QNAP ist acme.sh häufig im Einsatz, da dort oft keine vollständige Python-Umgebung vorhanden ist. win-acme wiederum ist bewusst auf Windows Server beschränkt und dort auf IIS zugeschnitten, inklusive automatischer Aktualisierung der IIS-Site-Bindings und Ablage im Windows-Zertifikatsspeicher. Wer einen gemischten Serverpark aus Linux und Windows betreibt, kommt in der Praxis selten mit nur einem der drei Tools aus.

Auch innerhalb von Container-Orchestrierung zeigt sich ein Unterschied. In Kubernetes-Clustern übernimmt meist nicht Certbot direkt, sondern das Projekt cert-manager die Zertifikatsausstellung, wobei dessen eigener ACME-Client sich konzeptionell eng an Certbot anlehnt und über ingress-nginx oder Traefik automatisch TLS-Secrets erzeugt. acme.sh lässt sich ebenfalls in Init-Container einbauen, wird dafür aber seltener eingesetzt, weil cert-manager inzwischen der De-facto-Standard für Kubernetes-natives Zertifikatsmanagement ist. win-acme spielt in Container-Umgebungen praktisch keine Rolle, da Windows-Container für TLS-Terminierung in der Praxis selten zum Einsatz kommen.

Kennzahlen im Vergleich: Sterne, Downloads und Update-Tempo

Unabhängige Labor-Benchmarks zu Erneuerungsgeschwindigkeit oder Ressourcenverbrauch existieren für diese drei Kommandozeilen-Tools nicht in belastbarer, vergleichbarer Form, da die Erneuerung ohnehin nur alle paar Tage bis Wochen läuft und in Sekunden abgeschlossen ist. Aussagekräftiger sind drei andere, öffentlich nachprüfbare Quellen: die GitHub-API, Docker Hub und die jeweiligen Release-Changelogs.

Nach GitHub-Sternen führt acme.sh mit 47.776 vor Certbot mit 33.256 und win-acme mit 5.805. Nach Docker-Hub-Downloads liegt Certbot mit 336.242.996 Pulls uneinholbar vorn, weil es als einziges der drei Projekte ein offizielles, breit genutztes Container-Image pflegt. Beim Update-Tempo zeigt sich ein differenziertes Bild: Certbot brachte zwischen März und September 2026 mehrere Versionssprünge mit neuen Funktionen wie der IP-Adress-Unterstützung, acme.sh folgte im September 2026 mit Version 3.1.6, während win-acme zwar laufend Commits erhält, aber seit Mai 2024 keinen offiziellen GitHub-Release-Tag mehr veröffentlicht hat. Für IIS-Admins ist das kein Totalausfall, da win-acme eigene Installer über die Projekt-Website bereitstellt, es erschwert aber die automatisierte Versionsprüfung über die GitHub-API.

Dokumentation und Lernkurve im Vergleich

Neben reiner Funktionalität entscheidet die Qualität der Dokumentation oft darüber, wie schnell ein Team produktiv wird. Certbot profitiert hier klar von der EFF-Unterstützung: Die offizielle Dokumentation ist strukturiert, enthält für jedes unterstützte Betriebssystem eigene Anleitungen und wird bei neuen Funktionen wie den IP-Adress-Zertifikaten zeitnah aktualisiert. Für Einsteiger ohne Linux-Erfahrung ist das ein spürbarer Vorteil gegenüber den beiden anderen Tools.

acme.sh dokumentiert die meisten Funktionen direkt im GitHub-Wiki und in den Kommentaren der einzelnen DNS-Skripte. Das ist technisch präzise, setzt aber voraus, dass Nutzer bereit sind, sich durch Rohtext und Skriptkommentare zu arbeiten, statt eine durchgestylte Dokumentationsseite zu durchsuchen. win-acme wiederum punktet mit einer eigenen Dokumentationswebsite und dem bereits erwähnten interaktiven Menü, das viele Entscheidungen direkt im Tool erklärt, sodass Nutzer seltener externe Dokumentation konsultieren müssen als bei den beiden anderen Clients.

Sicherheit und bekannte Schwachstellen

Für Certbot, acme.sh und win-acme liegen nach aktuellem Rechercheergebnis keine öffentlich dokumentierten, schwerwiegenden CVE-Einträge für den Zeitraum 2024 bis 2026 vor, die gezielt eines dieser drei Tools betreffen. Alle drei verlassen sich für die eigentlichen kryptografischen Operationen ohnehin auf externe Bibliotheken wie OpenSSL, über deren Sicherheit unser separater Vergleich von OpenSSL, BoringSSL und wolfSSL einen tieferen Einblick gibt. Das bedeutet nicht automatisch absolute Sicherheit, sondern vor allem, dass die eigentliche Angriffsfläche meist woanders liegt: bei den Zugangsdaten für DNS-APIs. Wer über ein DNS-01-Plugin automatisiert TXT-Einträge setzt, hinterlegt zwangsläufig ein API-Token mit Schreibrechten auf die eigene DNS-Zone. Gerät dieses Token in falsche Hände, kann ein Angreifer theoretisch eigene Zertifikate für fremde Domains ausstellen lassen.

Certbot und win-acme profitieren hier von einer vergleichsweise kleinen, überschaubaren Codebasis mit offizieller Pflege durch die EFF beziehungsweise das win-acme-Kernteam. acme.sh wiederum punktet mit vollständiger Transparenz: Da es sich um ein einziges, lesbares Shell-Skript handelt, lässt sich jede Zeile ohne Compiler oder Build-Pipeline nachvollziehen, ein Argument, das in sicherheitskritischen Umgebungen durchaus Gewicht hat. Grundsätzlich gilt für alle drei Tools dieselbe Empfehlung: DNS-API-Tokens mit möglichst eng begrenzten Rechten versehen, Secrets niemals im Klartext in Versionskontrolle ablegen und Renewal-Logs regelmäßig auf fehlgeschlagene Versuche prüfen.

Ein weiterer, oft unterschätzter Punkt ist die Dateiberechtigung der privaten Schlüssel. Alle drei Clients legen die Schlüsseldateien standardmäßig mit eingeschränkten Leserechten ab, trotzdem lohnt sich eine regelmäßige Kontrolle, insbesondere nach manuellen Eingriffen oder Backup-Wiederherstellungen, bei denen Berechtigungen schnell versehentlich zurückgesetzt werden. Zusätzlich sollte der ACME-Konto-Schlüssel, der die Berechtigung zur Verwaltung aller Zertifikate eines Kontos bündelt, getrennt von den einzelnen Domain-Zertifikaten gesichert werden. Geht dieser Schlüssel verloren oder wird er kompromittiert, lassen sich im schlimmsten Fall sämtliche über dieses Konto ausgestellten Zertifikate vorzeitig widerrufen oder missbraucht.

Fünf Praxisbeispiele aus echten Infrastrukturen

Wie sich die drei Clients in der Praxis unterscheiden, zeigt sich am besten an typischen Einsatzszenarien, wie sie in deutschen IT-Abteilungen und Hosting-Umgebungen regelmäßig vorkommen.

  • Webagentur mit Debian-Servern: Eine Agentur hostet zwanzig Kunden-Websites auf einem Nginx-Server unter Debian. Certbot übernimmt hier Ausstellung und Nginx-Konfiguration vollautomatisch über das native Plugin, ein Cronjob prüft täglich auf anstehende Erneuerungen.
  • Windows-Server mit Shopware-Shop: Ein mittelständischer Online-Händler betreibt seinen Shop auf einem Windows Server mit IIS. Da Certbot und acme.sh dort nicht nativ funktionieren, übernimmt win-acme die komplette Zertifikatsverwaltung inklusive automatischer IIS-Bindings.
  • Kubernetes-Cluster mit cert-manager: Ein SaaS-Anbieter betreibt Dutzende Microservices in Kubernetes. Das offizielle Certbot-Docker-Image mit seinen 336 Millionen Downloads dient dort als Referenz für eigene Init-Container, die Zertifikate vor dem Start der eigentlichen Anwendung bereitstellen.
  • Multi-Registrar-Setup mit Wildcard-Zertifikaten: Ein Unternehmen verteilt seine fünfzig Domains über sieben verschiedene DNS-Anbieter. Nur acme.sh deckt mit seinen 198 DNS-API-Skripten alle sieben Anbieter ohne Drittanbieter-Plugins ab.
  • NAS-Backup-System im Keller: Ein Synology-NAS für Backups soll per HTTPS erreichbar sein, ohne dass eine vollständige Python-Umgebung installiert werden soll. acme.sh läuft dort direkt über die integrierte Shell des NAS-Betriebssystems.
  • Kommunale IT mit zentralisiertem Rollout: Eine Stadtverwaltung verwaltet mehrere Dutzend interne Linux-Server über Ansible. Certbot lässt sich dabei als Paket in bestehende Playbooks einbinden, sodass neue Server automatisch mit funktionierender Zertifikatsverwaltung ausgerollt werden.
  • Freiberufler mit mehreren kleinen Projekten: Ein einzelner Entwickler betreut fünf private und berufliche Domains bei unterschiedlichen Hostern. acme.sh erlaubt die Verwaltung aller fünf Zertifikate über ein einziges, portables Skript ohne zusätzliche Serversoftware.

Migrationsleitfaden: Den ACME-Client wechseln in sieben Schritten

Ein Wechsel des ACME-Clients klingt nach einem heiklen Eingriff in die Produktivumgebung, lässt sich aber mit der richtigen Reihenfolge ohne Ausfallzeit durchführen. Typische Anlässe für eine Migration sind ein Umzug von Windows auf Linux, die Konsolidierung mehrerer DNS-Anbieter unter einem Client mit breiterer Plugin-Abdeckung oder der Wunsch, von einem Python-basierten Setup auf ein abhängigkeitsfreies Shell-Skript umzusteigen, etwa um ein Container-Image schlanker zu halten.

  1. Bestehende Zertifikate, private Schlüssel und Konfigurationsdateien des alten Clients vollständig sichern.
  2. Den neuen Client installieren, ohne den alten bereits zu deinstallieren, beide können parallel koexistieren.
  3. Einen neuen ACME-Account beim neuen Client registrieren, idealerweise mit derselben Kontakt-E-Mail-Adresse wie zuvor.
  4. Eine Testanfrage gegen die Let’s-Encrypt-Staging-Umgebung stellen, um Rate Limits der Produktivumgebung zu schonen.
  5. Prüfen, ob die DNS- oder HTTP-Challenge mit der neuen Konfiguration tatsächlich erfolgreich durchläuft.
  6. Das erste echte Zertifikat parallel zum alten ausstellen lassen und den Webserver erst nach erfolgreicher Validierung umschalten.
  7. Den alten Client und dessen automatische Erneuerung (Cronjob, systemd-Timer oder Windows-Taskplaner) erst deaktivieren, nachdem die erste reguläre Erneuerung mit dem neuen Client erfolgreich war.

Besonders der letzte Schritt wird häufig übersprungen und sorgt dann Wochen später für ein überraschend abgelaufenes Zertifikat, wenn zwei konkurrierende Cronjobs sich gegenseitig ausbremsen oder der alte Client versehentlich weiterläuft und widersprüchliche Zertifikate ausstellt. Wer mehrere Dutzend Server migriert, sollte den Prozess zusätzlich in Wellen aufteilen, etwa zehn Server pro Woche, statt alle Systeme am selben Tag umzustellen. So lässt sich ein unerwartetes Problem bei den ersten Servern beheben, bevor es sich auf die gesamte Infrastruktur ausweitet, und die Rate Limits von Let’s Encrypt werden auch bei größeren Umgebungen nicht überschritten.

Vor- und Nachteile im direkten Überblick

Certbot ist die Wahl mit dem größten offiziellen Rückhalt und der tiefsten Webserver-Integration.

  • Vorteil: Offizielle Pflege durch die Electronic Frontier Foundation mit regelmäßigen, klar dokumentierten Releases.
  • Vorteil: Native Plugins für Apache und Nginx inklusive automatischer Konfigurationsanpassung.
  • Vorteil: Mit 336.242.996 Downloads das mit Abstand meistgenutzte Docker-Image unter den drei Clients.
  • Nachteil: Python-Abhängigkeit bedeutet zusätzlichen Platzbedarf und Pflegeaufwand auf sehr schlanken Systemen.
  • Nachteil: Mit 13 offiziellen Plugins deutlich geringere DNS-Provider-Abdeckung als acme.sh.

acme.sh ist die Wahl für maximale Flexibilität bei minimalem Fußabdruck.

  • Vorteil: Keine Laufzeitabhängigkeiten außer curl oder wget und OpenSSL.
  • Vorteil: Vollständige Code-Transparenz als einzelnes, lesbares Shell-Skript.
  • Vorteil: Mit 198 DNS-API-Skripten die größte Provider-Abdeckung aller drei Tools.
  • Nachteil: Keine große Organisation im Hintergrund, Support ausschließlich über die Community.
  • Nachteil: Dokumentation stellenweise knapper als bei Certbot, Einstieg für Shell-Einsteiger etwas steiler.

win-acme ist die einzige ernstzunehmende Wahl für Windows- und IIS-Umgebungen.

  • Vorteil: Praktisch konkurrenzlose native IIS-Integration inklusive automatischer Bindings.
  • Vorteil: Interaktives Menü senkt die Einstiegshürde für weniger erfahrene Windows-Admins.
  • Vorteil: Unbeaufsichtigter Modus erlaubt vollautomatisierte Rollouts über den Windows-Taskplaner.
  • Nachteil: Außerhalb von Windows vollständig nutzlos, keine Linux- oder macOS-Unterstützung.
  • Nachteil: Seit Mai 2024 kein offizieller GitHub-Release-Tag mehr, was automatisierte Versionsprüfungen erschwert.

Für wen eignet sich welcher ACME-Client? Use-Case-Empfehlungen

Die technischen Daten und die Kostenübersicht ergeben zusammen ein klares Bild, aber erst der Abgleich mit dem eigenen Einsatzszenario macht daraus eine konkrete Empfehlung. Die folgende Liste ordnet die drei Clients sieben typischen Infrastruktur-Situationen zu, wie sie in deutschen Unternehmen und bei Einzelentwicklern regelmäßig vorkommen.

  • Linux-Server mit Apache oder Nginx und kleinem Team: Certbot, wegen der nativen Plugins und der offiziellen EFF-Dokumentation.
  • Windows Server mit IIS, wie in vielen deutschen KMUs üblich: win-acme, da es als einziges Tool native IIS-Integration bietet.
  • Multi-Cloud-Infrastruktur mit vielen DNS-Anbietern: acme.sh wegen der 198 verfügbaren DNS-API-Skripte.
  • Container- und Kubernetes-Deployments: Certbot wegen des etablierten, breit genutzten Docker-Images und der guten cert-manager-Kompatibilität.
  • Schlanke Systeme wie NAS-Geräte oder Embedded-Linux: acme.sh wegen der fehlenden Laufzeitabhängigkeiten.
  • IT-Dienstleister mit gemischtem Kundenstamm: Eine Kombination aus win-acme für Windows-Kunden und Certbot oder acme.sh für Linux-Kunden.
  • Sicherheitskritische Umgebungen mit Audit-Anspruch: acme.sh wegen der vollständigen Code-Transparenz als einzelnes, überprüfbares Shell-Skript.

Das Let’s-Encrypt-Update 2026 und was es für die Client-Wahl bedeutet

Die Verkürzung der Zertifikatslaufzeiten verändert die Anforderungen an ACME-Clients grundlegend. Bis 2028 soll die Standardlaufzeit laut offizieller Dokumentation von Let’s Encrypt von 90 auf 45 Tage sinken, parallel dazu zieht das CA/Browser Forum branchenweit nach und senkt die maximal erlaubte Zertifikatslaufzeit ab dem 15. März 2029 auf 47 Tage. Clients, die bisher nur einmal im Monat per Cronjob nach dem Rechten schauen, müssen ihre Prüfintervalle entsprechend verkürzen. Certbot hat mit den Versionen 5.3.0 und 5.4.0 bereits konkret auf die neuen IP-Adress-Zertifikate reagiert, für acme.sh und win-acme ist der Umgang mit den neuen ACME-Profilen öffentlich noch nicht im Detail dokumentiert, was bei der Tool-Auswahl für zukunftssichere Setups mit einzubeziehen ist.

In der Praxis bedeutet das: Wer heute neu plant, sollte nicht nur auf aktuelle Funktionen schauen, sondern auch auf das Update-Tempo des jeweiligen Projekts. Ein Client, der schnell auf neue ACME-Profile reagiert, erspart in zwei Jahren eine ungeplante Migration unter Zeitdruck.

Der Grund für die kürzeren Laufzeiten ist technisch nachvollziehbar. Je länger ein Zertifikat gültig bleibt, desto länger bleibt auch ein kompromittierter privater Schlüssel ein Problem, selbst wenn eine Zertifizierungsstelle den Widerruf technisch sofort einleitet. Revocation-Mechanismen wie CRLs oder OCSP gelten in der Praxis als unzuverlässig, weil viele Browser und Clients Sperrlisten nicht konsequent prüfen. Kürzere Laufzeiten verkleinern dieses Zeitfenster automatisch, ganz ohne dass sich Admins auf einen funktionierenden Widerruf verlassen müssen. Der Preis dafür ist höhere Automatisierungsabhängigkeit, und genau das macht die Wahl des richtigen ACME-Clients zu einer Sicherheitsfrage und nicht nur zu einer Komfortfrage.

Monitoring und Ausfallsicherheit bei ACME-Abhängigkeit

Mit kürzeren Zertifikatslaufzeiten steigt auch die Abhängigkeit von der Verfügbarkeit der Zertifizierungsstelle selbst. Fällt Let’s Encrypt für mehrere Stunden aus, während ein Zertifikat kurz vor Ablauf steht, wird aus einem theoretischen Risiko schnell ein echtes Problem. Alle drei hier verglichenen Clients unterstützen deshalb grundsätzlich auch alternative ACME-Zertifizierungsstellen wie ZeroSSL oder Buypass, die dasselbe Protokoll sprechen und sich als Fallback-CA konfigurieren lassen. Certbot und acme.sh erlauben den CA-Wechsel über einen einfachen Serverparameter, win-acme bietet die Auswahl direkt im interaktiven Menü an.

Unabhängig vom gewählten Client gehört ein externes Monitoring des tatsächlichen Ablaufdatums zur Grundausstattung jeder TLS-Automatisierung. Ein ACME-Client kann aus den unterschiedlichsten Gründen scheitern, von einem abgelaufenen DNS-API-Token über eine geänderte Firewall-Regel bis zu einem schlicht vergessenen Cronjob nach einem Systemupdate. Ein separater Check, der unabhängig vom Client das tatsächliche Zertifikat auf dem Server abfragt und bei Unterschreiten einer Mindestlaufzeit Alarm schlägt, fängt genau solche stillen Fehler ab, bevor Nutzer eine Browserwarnung zu Gesicht bekommen. Bei 160-Stunden-Zertifikaten verkürzt sich das Reaktionsfenster für ein verpasstes Monitoring-Signal erheblich gegenüber den bisherigen 90 Tagen, weshalb sich eine tägliche statt wöchentliche Prüfung empfiehlt.

Unser Urteil: Die beste Wahl nach Einsatzszenario

Einen einzelnen Sieger gibt es bei diesem Vergleich nicht, weil die drei Tools für unterschiedliche Plattformen gebaut wurden. Für die größte Gruppe der Leser, nämlich Betreiber von Linux-Servern mit Apache oder Nginx, bleibt Certbot die solideste Standardwahl: offizielle EFF-Pflege, native Webserver-Plugins, das mit 336 Millionen Downloads mit Abstand am häufigsten genutzte Docker-Image und die schnellste offiziell dokumentierte Reaktion auf die neuen Let’s-Encrypt-Zertifikatsprofile. Wer DNS-Automatisierung über viele verschiedene Registrare hinweg braucht oder ein möglichst schlankes, auditierbares Tool sucht, fährt mit acme.sh und seinen 198 DNS-API-Skripten sowie 47.776 GitHub-Sternen besser. Und wer auf Windows Server mit IIS angewiesen ist, kommt ohnehin kaum an win-acme vorbei, da es dort schlicht keine ernsthafte Alternative gibt. Die Zahlen sprechen eine klare Sprache: Jedes der drei Tools gewinnt in seiner eigenen Kategorie, und die Entscheidung fällt meist schon mit der Wahl des Betriebssystems.

Wer unsicher ist, kann auch pragmatisch vorgehen und mit dem Client starten, der zur bestehenden Infrastruktur passt, statt lange zwischen allen drei Optionen abzuwägen. Ein späterer Wechsel ist dank des offenen ACME-Standards jederzeit möglich, ohne die Zertifizierungsstelle wechseln zu müssen. Entscheidend ist am Ende weniger, welches der drei Tools auf dem Papier mehr Sterne oder Plugins mitbringt, sondern ob die Erneuerung im Alltag zuverlässig und ohne manuelles Eingreifen läuft. Angesichts der auf 160 Stunden geschrumpften Mindestlaufzeit ist genau diese Zuverlässigkeit 2026 wichtiger als jedes einzelne Komfort-Feature. Weitere Hintergründe zu TLS, Zertifikaten und angrenzenden Sicherheitsthemen finden sich in unserer Rubrik Cybersicherheit.

Häufig gestellte Fragen

Was ist ein ACME-Client und wozu wird er gebraucht?
Ein ACME-Client ist eine Software, die automatisiert TLS-Zertifikate bei einer Zertifizierungsstelle wie Let’s Encrypt beantragt, die Domain-Kontrolle per HTTP- oder DNS-Challenge nachweist und die Erneuerung vor Ablauf übernimmt. Ohne einen solchen Client müsste jede Erneuerung manuell über ein Webinterface angestoßen werden, was bei mehreren Domains oder kurzen Zertifikatslaufzeiten schnell unpraktikabel wird.

Ist Certbot wirklich komplett kostenlos?
Ja. Certbot steht unter der Apache License 2.0 und ist für private wie kommerzielle Nutzung kostenlos, ebenso wie die Zertifikate von Let’s Encrypt selbst.

Kann ich acme.sh ohne Root-Rechte nutzen?
Ja, acme.sh lässt sich im Nutzerkontext ausführen, solange der Zielordner für Zertifikate und der jeweilige Webserver-Reload-Befehl entsprechend konfiguriert sind. Für Port-80-Challenges auf Standardports sind allerdings in der Regel erhöhte Rechte nötig.

Unterstützt win-acme auch Linux oder macOS?
Nein. win-acme ist laut offiziellem Repository ausschließlich für Windows Server und Windows-basierte IIS-Umgebungen konzipiert.

Was bedeuten die neuen 6-Tage-Zertifikate von Let’s Encrypt für meinen ACME-Client?
Seit Januar 2026 sind Zertifikate mit 160 Stunden Gültigkeit als optionales Profil allgemein verfügbar. Wer dieses Profil nutzt, braucht einen Client mit zuverlässiger, möglichst täglicher Erneuerungsprüfung, da eine verpasste Erneuerung deutlich schneller zu einem abgelaufenen Zertifikat führt als bei den bisherigen 90 Tagen.

Welcher Client unterstützt die meisten DNS-Provider für Wildcard-Zertifikate?
acme.sh mit 198 offiziellen DNS-API-Skripten im Repository, deutlich vor Certbot mit 13 offiziellen DNS-Plugins. win-acme deckt laut eigener Projektbeschreibung ebenfalls eine zweistellige Zahl an Anbietern ab, bleibt dabei aber auf das Windows-Ökosystem fokussiert.

Kann ich mehrere ACME-Clients parallel auf demselben Server betreiben?
Technisch ja, solange beide auf unterschiedliche Zertifikatsdateien und Challenge-Pfade zugreifen. Für eine saubere Migration empfiehlt sich dennoch, den alten Client erst nach erfolgreicher erster Erneuerung durch den neuen Client vollständig zu deaktivieren.

Was passiert, wenn mein ACME-Client eine Erneuerung verpasst?
Läuft das Zertifikat ab, zeigen Browser eine Sicherheitswarnung, und verschlüsselte Verbindungen zum betroffenen Dienst schlagen fehl. Deshalb sollte jede Client-Einrichtung mit einer zusätzlichen externen Überwachung des Ablaufdatums kombiniert werden, etwa über einen separaten Monitoring-Check.