Die wichtigsten ACME-Clients im Überblick: Certbot, acme.sh, cert-manager & Co.

Ein ACME-Client ist die Software, die das ACME-Protokoll auf Ihrem Server oder Cluster umsetzt und automatisiert SSL-/TLS-Zertifikate beantragt, validiert und installiert. Welcher Client der richtige ist, hängt von Ihrem Betriebssystem, Ihrem Webserver und Ihrem Skalierungsbedarf ab. Dieser Guide vergleicht die neun relevantesten ACME-Clients – inklusive Certbot, acme.sh, cert-manager, win-acme, lego, Caddy, Traefik, dehydrated und Posh-ACME – und zeigt, wo deren Grenzen im Enterprise-Betrieb liegen.

Sie wollen sich nicht mit Client-Wartung beschäftigen?

LEMARIT bietet eine Plattform mit vier Integrations-Modellen

LEMARIT Certificate Automation
Inhalte

Was ist ein ACME-Client?

Ein ACME-Client ist die Software-Komponente, die das ACME-Protokoll (RFC 8555) auf der Seite des Domain-Inhabers implementiert. Konkret übernimmt der Client drei Aufgaben: Er kommuniziert mit dem ACME-Endpoint der Certificate Authority, führt die gewählte Challenge (HTTP-01, DNS-01 oder TLS-ALPN-01) aus und installiert das ausgestellte Zertifikat im Zielsystem.

Die Wahl des Clients ist nicht trivial: Sie entscheidet maßgeblich über Wartungsaufwand, Sicherheitsniveau und Skalierbarkeit der gesamten Automatisierung. Ein ungeeigneter Client wird im Enterprise-Betrieb schnell zum Bottleneck.

Die wichtigsten ACME-Clients im Detail

Certbot – der De-facto-Standard

Certbot ist der von der Electronic Frontier Foundation (EFF) entwickelte Referenz-Client und der mit Abstand am häufigsten eingesetzte ACME-Client. Er ist in Python geschrieben, läuft auf nahezu allen Linux-Distributionen und unterstützt sowohl HTTP-01 als auch DNS-01.

Stärken: Umfassend dokumentiert, große Community, Plug-in-Architektur für viele DNS-Provider, integrierte Apache- und Nginx-Konfigurations-Anpassung.

Grenzen: Python-Abhängigkeiten erfordern gepflegte Runtime-Umgebung, schwere Installation auf minimalen Images, kein nativer Windows-Support.

Geeignet für: Linux-basierte Webserver mit Apache oder Nginx, Single- und Multi-Domain-Setups, klassische Hosting-Umgebungen.

Lizenz: Open Source (Apache 2.0).

acme.sh – der flexible Alleskönner

acme.sh ist ein ACME-Client, der vollständig in Shell-Script geschrieben ist. Er hat keine Runtime-Abhängigkeiten außer einer üblichen Bash-Umgebung und unterstützt eine außergewöhnlich breite Liste von DNS-Providern – aktuell deutlich über 150.

Stärken: Keine Python- oder anderen Runtime-Abhängigkeiten, läuft auf jedem Unix-System inklusive minimaler Container, sehr breite DNS-API-Unterstützung, einfache Erweiterbarkeit.

Grenzen: Komplexere Konfiguration als Certbot für Einsteiger, Shell-Script ist für sicherheitskritische Reviews aufwendiger zu auditieren als kompilierte Software.

Geeignet für: Container-Umgebungen, Embedded-Systeme, Setups mit exotischen DNS-Providern, DevOps-Teams mit hoher Shell-Affinität.

Lizenz: Open Source (GPL v3).

cert-manager – der Kubernetes-Standard

cert-manager ist der etablierte Kubernetes-native ACME-Controller. Er läuft als Operator im Cluster, verwaltet Zertifikate als CRDs (
Certificate
, 
Issuer
, 
ClusterIssuer
) und integriert sich nahtlos in den Kubernetes-Lifecycle. Für moderne Cloud-Native-Architekturen ist er die selbstverständliche Wahl.

Stärken: Tiefe Kubernetes-Integration, deklarative Konfiguration als YAML, vielfältige DNS-01-Solver (Cloud-Provider, RFC 2136, Webhooks), automatische Erneuerung über CronJob.

Grenzen: Kubernetes-spezifisch – außerhalb von K8s-Clustern nicht einsetzbar. Komplexere Initial-Konfiguration (ClusterIssuer + Secrets) als bei Standalone-Clients.

Geeignet für: Kubernetes-Cluster aller Größen, GitOps-Workflows, Microservice-Architekturen, Multi-Cluster-Setups.

Lizenz: Open Source (Apache 2.0).

win-acme (WACS) – der Windows-Standard

win-acme, häufig WACS abgekürzt, ist der populärste ACME-Client für Windows-Umgebungen. Er ist in .NET geschrieben und integriert sich nahtlos in IIS und das Windows-Zertifikatsspeicher-System.

Stärken: Nahtlose IIS-Integration, automatische Zuweisung von Zertifikaten zu IIS-Bindungen, GUI- und CLI-Modus, Windows-Task-Scheduler-Anbindung.

Grenzen: Nur Windows, kleinere Community als Certbot, kein offizieller Support für Linux-basierte Webserver auf Windows.

Geeignet für: Windows-Server mit IIS, hybride Microsoft-Umgebungen, Exchange-Server, Lync/Skype-Server.

Lizenz: Open Source (Apache 2.0).

lego – der Go-basierte Client

lego ist ein ACME-Client, der in Go geschrieben ist und als statisch kompilierte Binary daherkommt. Damit eignet er sich besonders gut für Container-Umgebungen und CI/CD-Pipelines.

Stärken: Single-Binary ohne Abhängigkeiten, starke DNS-Provider-Abdeckung, gut für Embedded-Use als Library in eigene Go-Anwendungen, hoch performant.

Grenzen: Weniger umfangreich dokumentiert als Certbot, kleinere Plug-in-Landschaft als acme.sh.

Geeignet für: Container-Workloads, CI/CD-Pipelines, Go-basierte Eigenentwicklungen.

Lizenz: Open Source (MIT).

Caddy – der Webserver mit integriertem ACME

Stärken: Zero-Configuration HTTPS, automatische Verlängerung, native Unterstützung für HTTP-01, DNS-01 und TLS-ALPN-01, gut für Mikroservices.

Grenzen: Setzt voraus, dass Caddy als Webserver verwendet wird – kein Add-on für bestehende Apache- oder Nginx-Setups.

Geeignet für: Greenfield-Projekte, Mikroservice-Architekturen, Teams, die einen Webserver mit eingebauter SSL-Automatisierung suchen.

Lizenz: Open Source (Apache 2.0).

Caddy ist kein klassischer ACME-Client, sondern ein Webserver, der ACME nativ integriert hat. Wer Caddy als HTTP/HTTPS-Server einsetzt, bekommt Zertifikatsautomatisierung praktisch geschenkt – inklusive automatischer Verlängerung und ohne separate Tool-Installation.

Traefik – der Reverse Proxy mit ACME

Traefik ist ein moderner Reverse Proxy und Load Balancer, der ACME ebenfalls nativ integriert. Besonders in Docker- und Kubernetes-Umgebungen ist er weit verbreitet, weil er Routing-Regeln dynamisch aus Container-Labels generiert und Zertifikate automatisch beantragt.

Stärken: Tiefgehende Docker- und Kubernetes-Integration, dynamische Konfiguration aus Container-Labels, integrierter ACME mit DNS-01- und HTTP-01-Support.

Grenzen: Komplexere Konfiguration als Caddy, in nicht-Container-Umgebungen weniger natürliche Wahl.

Geeignet für: Docker- und Kubernetes-Cluster, Service-Mesh-nahe Setups, Microservices-Routing.

Lizenz: Open Source (MIT).

dehydrated – der minimale Bash-Client

Stärken: Minimal-Code-Base, leicht zu auditieren, gute Hook-Architektur für eigene Skripte, gut für sicherheitsbewusste Umgebungen.

Grenzen: Funktionsumfang bewusst begrenzt, weniger DNS-Provider-Integration als acme.sh.

Geeignet für: Security-fokussierte Setups, Server mit minimalen Installationen, Setups, in denen Code-Audits Pflicht sind.

Lizenz: Open Source (MIT).

dehydrated ist ein extrem schlanker ACME-Client, der wie acme.sh in Bash geschrieben ist, aber bewusst minimalistisch gehalten wurde. Er hat einen sehr fokussierten Funktionsumfang und ist dadurch einfach zu auditieren.

Posh-ACME – der PowerShell-Client

Posh-ACME ist ein ACME-Client, der vollständig in PowerShell geschrieben ist und damit die natürliche Wahl für Windows-Admins darstellt, die PowerShell als Automatisierungssprache nutzen.

Stärken: Native PowerShell-Integration, gute Anbindung an Microsoft-Ökosystem (Azure Key Vault, Active Directory), einfache Einbindung in PowerShell-DSC und -Pipelines.

Grenzen: Geringere Community-Größe als Certbot oder acme.sh, primär auf Windows fokussiert.

Geeignet für: Windows-Admins mit PowerShell-Workflows, Azure-Workloads, Microsoft-zentrierte Infrastrukturen.

Lizenz: Open Source (MIT).

SSL-Zertifikate automatisch verlängern

ACME-Clients im direkten Vergleich

Client

Certbot

acme.sh

cert-manager

win-acme

lego

Caddy

Traefik

dehydrated

Posh-ACME

Sprache

Phyton

Shell

Go (CRDs)

.NET

Go

Go (eingebaut)

Go (eingebaut)

Bash

PowerShell

OS

Linux, macOS

Unix-like, Container

Kubernetes

Windows

plattformübergreifend

plattformübergreifend

plattformübergreifend

Unix-like

Windows

Webserver/Cluster-Integration

Apache, Nginx

manuell/Hook

nativ (Kubernetes-Controller)

IIS

manuell/Hook

nativ (Caddy ist Webserver)

nativ (Traefik ist Proxy)

manuell/Hook

manuell/Hook

DNS-Provider

breit (Plug-in-System)

sehr breit (>150)

breit (Solver + Webhooks)

breit

breit

breit

breit

begrenzt

breit

Best Fit

klassische Linux-Webserver

DevOps, Container

Kubernetes-Cluster

Windows-Server

Container, CI/CD

Greenfield-Projekte

Docker, Kubernetes

sicherheits-/audit-fokussiert

Windows + PowerShell

Welcher ACME-Client passt zu welcher Umgebung?

Die Auswahl folgt in den meisten Fällen einer einfachen Heuristik:

Linux + Apache/Nginx, Standard-Setup → Certbot. Der Klassiker funktioniert hier mit den wenigsten Stolpersteinen und hat die beste Dokumentation.

Kubernetes-Cluster → cert-manager. Es ist die Kubernetes-native Standardlösung; CRD-basierte Konfiguration, automatisches Renewal, breite Solver-Unterstützung.

Container, Docker, klassisch ohne Kubernetes → lego oder Traefik. Beide kompilieren zu einer einzigen Binary, integrieren sich gut in Orchestrierung und vermeiden Runtime-Abhängigkeiten.

Windows-Server mit IIS → win-acme. Es gibt schlicht keine wirklich gute Alternative auf Windows mit der gleichen IIS-Integration.

Windows mit PowerShell-Workflows → Posh-ACME. Wenn das gesamte Infrastruktur-Management auf PowerShell läuft, ist dies die natürlichste Wahl.

Greenfield-Projekt mit eigenem Webserver → Caddy. Die geringste Komplexität, weil ACME bereits eingebaut ist.

Exotische DNS-Provider oder Embedded-Systeme → acme.sh. Die breiteste DNS-API-Abdeckung und das schlankste Footprint.

Security-fokussierte Umgebung mit Audit-Pflicht → dehydrated. Die kleinste Code-Base ist die einfachste zu prüfen.

Grenzen der Standard-Clients im Enterprise-Betrieb

Alle vorgestellten Clients sind hervorragende Werkzeuge – auf ihrem jeweiligen Server oder Cluster. Im Enterprise-Betrieb, wo Sie nicht zwei oder drei, sondern Hunderte oder Tausende Zertifikate über heterogene Umgebungen hinweg verwalten müssen, stoßen sie an strukturelle Grenzen:

Keine zentrale Inventarisierung. Ein Client weiß nur, was er selbst beantragt hat. Eine konsolidierte Sicht über das gesamte Zertifikats-Portfolio fehlt.

Keine übergreifende Eskalation. Wenn ein Renewal auf einem einzelnen Server scheitert, muss die Fehlerbehandlung dort lokal passieren. Ein systemweites Alerting mit definierten Eskalationspfaden ist nicht vorgesehen.

Limitiertes Audit-Logging. Die meisten Clients schreiben lokale Logs, die für Compliance-Reports nicht ausreichen. ISO-27001-Audits erwarten zentrale, revisionssichere Protokollierung.

Multi-CA-Strategien sind aufwendig. Wer parallel mit mehreren CAs arbeitet, muss die Logik in eigenen Skripten implementieren und in jeder Client-Konfiguration nachpflegen.

Wartung der Client-Infrastruktur. Python-Updates, .NET-Runtime-Updates, Bash-Versions-Inkompatibilitäten, Kubernetes-Operator-Upgrades – die Pflege der Clients selbst wird in großen Setups schnell zur Daueraufgabe.

Granulare Berechtigungen fehlen. Wer ACME-Clients in Multi-Tenant-Umgebungen einsetzt (Hosting-Agenturen, Konzerne mit dezentralen Marken), kann den Zugriffsbereich pro Client kaum strukturell einschränken.

LEMARIT Certificate Automation: die Plattform-Antwort

Genau hier setzt LEMARIT Certificate Automation an: als Zertifikatsautomatisierungs-Plattform mit vier Integrations-Modellen, die alle vorgenannten Lücken strukturell schließt – ohne dass Sie Ihre Endsysteme oder die eingesetzten ACME-Clients austauschen müssen.

Offiziell unterstützte ACME-Clients

Drei Clients sind offiziell getestet und dokumentiert:

  • Certbot – für Linux-Webserver mit Apache und Nginx
  • acme.sh – für Unix-like und Container-Umgebungen
  • cert-manager – für Kubernetes-Cluster

Andere RFC-2136-fähige ACME-Clients können technisch ebenfalls auf unsere Schnittstelle zugreifen, gehören aber nicht zur Standard-Support-Matrix.

REST-API als Alternative zu ACME

Für Umgebungen, in denen kein ACME-Client zur Verfügung steht oder generell keine sinnvolle Option ist – etwa Legacy-Software, eigene CertOps-Tooling oder Multi-Tenant-Plattformen – bietet LEMARIT zusätzlich eine entwicklerfreundliche REST-API. Damit lassen sich Bestellung und Erneuerung auch ohne ACME-Stack vollständig automatisieren.

Domain Patterns für granulare Multi-Tenant-Governance

Pro API-User können Sie eine Liste von Domain Patterns konfigurieren – feste Domainnamen oder Wildcard-Muster. Bei jeder Anfrage prüft die Plattform, ob der angefragte Domainname erlaubt ist. Damit reduzieren Sie den Schaden bei kompromittierten Keys, bilden Multi-Tenant-Setups präzise ab und erfüllen das Least-Privilege-Prinzip aus Audit-Anforderungen.

Zentrale Konsole im LEMARIT.app-WebUI

Inventar, Multi-CA-Konfiguration, Monitoring, Audit-Trail und Reporting laufen über eine zentrale Oberfläche. Sie behalten Ihre lokalen ACME-Clients (oder Custom-REST-API-Integrationen), gewinnen aber die Plattform-Sicht über alle Zertifikate hinweg.

ACME-Clients und die 200-Tage-Regel

Mit der Verkürzung der Zertifikatslaufzeit auf 200 Tage – und perspektivisch auf 100 und 47 Tage – wird die Zuverlässigkeit der Clients zum kritischen Faktor. Ein Client, der gelegentlich Renewals verpasst, war bei jährlichen Laufzeiten lästig, aber tolerierbar. Bei sechs Renewals pro Jahr und Zertifikat führt jeder Ausfall zu einem produktiven Vorfall.

Drei Dinge werden damit unverhandelbar: Robustheit der Client-Software (gepflegte Open-Source-Projekte mit aktiver Community), systemisches Monitoring über alle Clients hinweg und Eskalations-Mechanismen mit klaren Verantwortlichkeiten. LEMARIT Certificate Automation liefert genau diese drei Komponenten als integriertes Paket – unabhängig davon, ob Ihre Endsysteme über ACME oder REST-API angebunden sind.

SSL-Zertifikate automatisch verlängern

Häufige Fragen (FAQ) zu ACME-Clients

Was ist ein ACME-Client?

Ein ACME-Client ist die Software auf Seiten des Domain-Inhabers, die das ACME-Protokoll (RFC 8555) implementiert. Sie kommuniziert mit der Certificate Authority, führt die gewählte Challenge aus und installiert das ausgestellte SSL-/TLS-Zertifikat auf dem Zielsystem. Bekannte ACME-Clients sind Certbot, acme.sh, cert-manager, win-acme, lego, Caddy und Traefik.

Es gibt keinen universellen Sieger. Für Linux-Webserver ist Certbot der Klassiker, für Kubernetes ist cert-manager der Standard, für Container-Umgebungen außerhalb von Kubernetes lego oder acme.sh, für Windows-Server win-acme. Die Wahl hängt von Betriebssystem, Webserver oder Cluster, DNS-Provider und gewünschtem Wartungsmodell ab.
cert-manager ist die etablierte Kubernetes-native Lösung. Sie wird als Operator installiert und verwaltet Zertifikate als CRDs (
Certificate
, 
Issuer
, 
ClusterIssuer
). Alternativ kann auch Traefik mit eingebautem ACME genutzt werden, wenn der Cluster Traefik als Ingress-Controller einsetzt.
Auf Windows-Servern ist win-acme (WACS) der Quasi-Standard, weil er sich nahtlos in IIS integriert. Für PowerShell-orientierte Admins ist Posh-ACME die natürliche Wahl. Auch lego und acme.sh laufen unter Windows (z. B. via WSL), sind dort aber weniger verbreitet.
Für Einsteiger ist Certbot auf Linux die einfachste Wahl, weil die Dokumentation am vollständigsten ist und die meisten Tutorials darauf basieren. Wer einen Webserver neu aufsetzt, kann auch Caddy nutzen – hier passiert die SSL-Automatisierung praktisch unsichtbar im Hintergrund.
acme.sh hat mit über 150 unterstützten DNS-Providern die breiteste Abdeckung. Certbot folgt mit einer großen Plug-in-Landschaft, lego mit nativer Go-Integration vieler Provider. cert-manager bietet eingebaute Solver für die wichtigsten Cloud-Provider sowie generisches RFC 2136 und ein Webhook-System für individuelle DNS-Backends.
Die etablierten Open-Source-Clients (Certbot, acme.sh, cert-manager, win-acme, lego, Caddy, Traefik) gelten als sicher, sofern sie aktuell gehalten werden. Wichtig sind drei Punkte: regelmäßige Updates, sicheres Handling der DNS-API-Tokens oder TSIG-Keys (bei DNS-01) und eine saubere Trennung von Webserver- und ACME-Rechten.
Ja, in heterogenen Umgebungen ist das üblich – z. B. Certbot auf Linux-Webservern, win-acme auf Windows-IIS und cert-manager im Kubernetes-Cluster. Wichtig ist, dass die Clients dieselben Domains nicht parallel beanspruchen (das würde zu Konflikten beim Renewal führen). Ein zentraler Inventar-Service hilft, solche Konflikte zu vermeiden.
Offiziell unterstützt und getestet sind Certbot, acme.sh und cert-manager. Andere RFC-2136-fähige Clients können technisch ebenfalls auf unsere Schnittstelle zugreifen, gehören aber nicht zur Standard-Support-Matrix. Für Umgebungen ohne ACME-Client steht zusätzlich unsere REST-API zur Verfügung.
Nein. Für Enterprise-Umgebungen ist die LEMARIT Certificate Automation als Zertifikatsautomatisierungs-Plattform meist wirtschaftlicher als der Eigenbetrieb. Sie behalten Ihre Server-Topologie und die eingesetzten Clients, aber die Orchestrierung, das Monitoring und die Compliance-Reports laufen über die Plattform.

Vom Tool-Vergleich zur Plattform-Entscheidung

Die Wahl des richtigen ACME-Clients ist nur ein Baustein. Im professionellen Betrieb brauchen Sie Inventar, Multi-CA-Orchestrierung, Monitoring, Audit-Trail, granulare Berechtigungen über Domain Patterns – und einen Ansprechpartner, der das Ganze versteht.

LEMARIT Certificate Automation liefert diesen Plattform-Rahmen über jeden Client, den Sie bereits einsetzen.

LEMARIT Certificate Automation
©SARIPICTURE Sarah Domandl LEMARIT Stockfotos 0201 20260219

Weiterführende Inhalte

SSL-Zertifikate automatisch verlängern

LEMARIT Certificate Automation

Was ist ACME? Bedeutung, Funktionsweise & Vorteile

ACME-Challenges erklärt: DNS-01, HTTP-01, TLS-ALPN-01/

ACME-Anbieter im Vergleich: Let’s Encrypt, SSL.com, Cloudflare & Co.

ACME einrichten: Schritt-für-Schritt-Anleitung

Close
Suchen