Cert-Manager vs. acme.sh: TLS-Zertifikate fuer Kubernetes und Server automatisieren im Vergleich 2026

Cert-Manager und acme.sh automatisieren TLS-Zertifikate für Kubernetes und Server. Welche Lösung passt für Self-Hoster und DevOps-Teams?

Cert-Manager vs. acme.sh: TLS-Zertifikate automatisieren

TLS-Zertifikate sind heute Pflicht — aber wer verwaltet sie? Cert-Manager und acme.sh sind die beiden beliebtesten Open-Source-Lösungen, um Let's-Encrypt-Zertifikate automatisch zu beantragen und zu erneuern. Cert-Manager läuft als Kubernetes-Operator und integriert sich nahtlos in Cluster-Workflows. acme.sh ist ein Shell-Skript, das auf jedem Linux-Server ohne zusätzliche Abhängigkeiten funktioniert.

Dieser Vergleich zeigt, welches Tool für Self-Hoster, DevOps-Teams und Kubernetes-Betreiber die bessere Wahl ist.

Cert-Manager: Der Kubernetes-native Weg

Cert-Manager ist ein Kubernetes-Operator, der Zertifikate als Custom Resources (Certificate, ClusterIssuer, Issuer) verwaltet. Er unterstützt Let's Encrypt, ZeroSSL, HashiCorp Vault, Venafi und eigene interne CAs.

Installation via Helm

helm repo add jetstack https://charts.jetstack.io
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set installCRDs=true

ClusterIssuer für Let's Encrypt

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
    - http01:
        ingress:
          class: nginx

Automatisches Zertifikat per Annotation

Mit dem NGINX Ingress Controller genügt eine Annotation — Cert-Manager erkennt sie, beantragt das Zertifikat bei Let's Encrypt und speichert es als Kubernetes Secret:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: meine-app
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - example.com
    secretName: example-com-tls
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: meine-app
            port:
              number: 80

Die Erneuerung erfolgt automatisch 30 Tage vor Ablauf — ohne manuellen Eingriff.

Stärken von Cert-Manager

Kubernetes-nativ: Zertifikate als Kubernetes-Ressourcen, vollständig via kubectl verwaltbar
GitOps-ready: Deklarativ, YAML-basiert — lässt sich mit ArgoCD oder Flux CD verwalten
Breite CA-Unterstützung: ACME (Let's Encrypt, ZeroSSL), Vault, Venafi, CFSSL
Wildcard-Zertifikate: Über DNS-01-Challenge möglich (Route53, Cloudflare, Hetzner DNS)
Automatische Erneuerung: 30 Tage vor Ablauf, ohne manuellen Eingriff
Monitoring: Prometheus-Metriken für Ablaufdaten und Erneuerungsstatus

Schwächen von Cert-Manager

Erfordert einen laufenden Kubernetes-Cluster — auf klassischen Servern nicht einsetzbar
Overhead für reine VM- oder Bare-Metal-Server ohne Kubernetes
Komplexere Fehlersuche: Logs in mehreren Pods, CRD-Status prüfen

acme.sh: Der Shell-native Weg

acme.sh ist ein reines POSIX-Shell-Skript ohne externe Abhängigkeiten. Es implementiert das ACME-Protokoll direkt und unterstützt über 150 DNS-Provider für DNS-01-Challenges sowie HTTP-01 und TLS-ALPN-01.

Installation

curl https://get.acme.sh | sh
source ~/.bashrc

Zertifikat für eine Domain beantragen

# HTTP-01 Challenge (Webroot-Modus)
acme.sh --issue -d example.com -w /var/www/html

# DNS-01 Challenge (Cloudflare-Beispiel) für Wildcard
export CF_Token="dein-cloudflare-api-token"
acme.sh --issue --dns dns_cf -d example.com -d "*.example.com"

Zertifikat installieren und Auto-Reload

acme.sh --install-cert -d example.com \
  --cert-file /etc/nginx/ssl/cert.pem \
  --key-file /etc/nginx/ssl/key.pem \
  --fullchain-file /etc/nginx/ssl/fullchain.pem \
  --reloadcmd "systemctl reload nginx"

acme.sh richtet automatisch einen Cronjob ein, der täglich prüft, ob Zertifikate in den nächsten 30 Tagen ablaufen, und sie bei Bedarf erneuert.

Stärken von acme.sh

Kein Kubernetes nötig: Läuft auf jedem Linux-System mit bash oder dash
Leichtgewichtig: Keine Abhängigkeiten außer curl oder wget, kein Daemon
150+ DNS-Provider: AWS Route53, Cloudflare, Hetzner DNS, INWX und viele mehr
Wildcard-Zertifikate: Über DNS-01 einfach und kostenlos möglich
Portabel: Funktioniert auf VMs, Bare-Metal-Servern, Raspberry Pis und NAS-Systemen
ECC-Unterstützung: Zertifikate mit elliptischen Kurven (P-256, P-384) für bessere Performance

Schwächen von acme.sh

Kein Kubernetes-nativer Workflow — Zertifikate müssen manuell als Secrets eingespielt werden
Kein zentrales UI oder Dashboard — Verwaltung ausschließlich via CLI
Fehlersuche rein über Log-Dateien und Shell-Output

Head-to-Head-Vergleich

Merkmal	Cert-Manager	acme.sh
Einsatzbereich	Kubernetes	Server (VM, Bare-Metal)
Kubernetes-Integration	Nativ (CRDs)	Manuell
ACME-Provider	Let's Encrypt, ZeroSSL, Vault	Let's Encrypt, ZeroSSL, 150+ DNS
Wildcard-Zertifikate	Ja (DNS-01)	Ja (DNS-01)
Installation	Helm / kubectl	curl, kein Paketmanager
GitOps-fähig	Ja	Nein
Ressourcenverbrauch	~50–100 MB RAM	Minimal (~0)
Lernkurve	Mittel (Kubernetes-Kenntnisse)	Niedrig (Shell)
Monitoring	Prometheus-Metriken	Cronjob-Log

Wann Cert-Manager, wann acme.sh?

Cert-Manager ist die richtige Wahl, wenn du:

Kubernetes für Produktions-Workloads nutzt
Zertifikate deklarativ per YAML oder GitOps verwalten möchtest
Ingress-Ressourcen mit automatischer TLS-Terminierung benötigst
Vault oder andere interne CAs für Zero-Trust-Architekturen integrieren willst
Den Zertifikatsstatus über Prometheus und Grafana überwachen möchtest

acme.sh ist besser, wenn du:

Einzelne Linux-Server, VMs oder NAS-Systeme betreibst
Wildcard-Zertifikate ohne Kubernetes und DNS-01-Challenge brauchst
Minimalen Overhead und keine Kubernetes-Abhängigkeit willst
Einfache Cronjob-basierte Erneuerung ohne Betriebsteam bevorzugst

Viele Teams nutzen beide Tools parallel: acme.sh für klassische Server und Reverse-Proxy-Hosts, Cert-Manager für Kubernetes-Cluster.

DNS-01-Challenge: Der Schlüssel für Wildcard-Zertifikate

Sowohl Cert-Manager als auch acme.sh unterstützen DNS-01-Challenges — sie sind der einzige Weg, Wildcard-Zertifikate (*.example.com) zu beantragen. Dabei wird ein TXT-Record im DNS gesetzt, der die Domain-Inhaberschaft beweist. Voraussetzung ist ein unterstützter DNS-Provider mit API-Zugang.

Empfohlene DNS-Provider für beide Tools: Cloudflare, Hetzner DNS, Route53, INWX, DigitalOcean DNS.

Alternativen im Überblick

Traefik: Integriert Let's Encrypt direkt in den Reverse Proxy — kein separates Tool nötig
Caddy: Automatisiert TLS-Zertifikate vollständig out-of-the-box ohne manuelle Konfiguration
Smallstep step-ca: Interne PKI mit ACME-Unterstützung für Zero-Trust-Netzwerke
Lego: Go-basierter ACME-Client als Alternative zu acme.sh