Bevor Sie loslegen, prüfen Sie diese Checkliste – sie erspart 80 Prozent der typischen Setup-Probleme:
Aktualisieren Sie die Paketlisten und installieren Sie Certbot mit dem Apache-Plug-in:
sudo apt update install
sudo apt install certbot python3-certbot-apache
Starten Sie Certbot im Apache-Modus mit einer oder mehreren Domains. Certbot übernimmt die HTTP-01-Validierung und passt die Apache-Konfiguration automatisch an:
sudo certbot \
--apache \
-d example.com \
-d www.example.com
--apache-dKIDEinmalig: Account registrieren mit EAB
sudo certbot register \
--server https://acme.lemarit.cloud/directory \
--eab-kid <IHRE_KID> \
--eab-hmac-key <IHR_HMAC_KEY> \
--register-unsafely-without-email \
--agree-tos
Anschließend: Zertifikate anfragen (EAB-Parameter entfallen)
sudo certbot \
--apache \
--server https://acme.lemarit.cloud/directory \
--preferred-challenges dns \
--issuance-timeout 600 \
-d example.com \
-d www.example.com
--server
sudo certbot renew \
--dry-run
/etc/apache2/sites-enabled/-le-ssl.confServerNameServerAlias
sudo systemctl reload apache2
sudo apt update
sudo apt install certbot python3-certbot-nginx
sudo certbot \
--nginx \
-d example.com \
-d www.example.com
--nginx-dKID--register-unsafely-without-emailEinmalig: Account registrieren mit EAB
sudo certbot register \
--server https://acme.lemarit.cloud/directory \
--eab-kid <IHR_KID> \
--eab-hmac-key <IHR_HMAC_KEY> \
--register-unsafely-without-email \
--agree-tos
Anschließend: Zertifikate anfragen (EAB-Parameter entfallen)
sudo certbot \
--nginx \
--server https://acme.lemarit.cloud/directory \
--preferred-challenges dns \
--issuance-timeout 600 \
-d example.com \
-d www.example.com
--server
sudo certbot renew \
--dry-run
Wenn der Trockenlauf erfolgreich ist, übernimmt der mit installierte Timer die regelmäßige Verlängerung.
/etc/nginx/sites-enabled/< domain>server_name
sudo systemctl reload nginx
Via Helm:
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--set installCRDs=true
cert-managercert-managerEAB-Secret anlegen
kubectl create secret generic lemarit-eab-secret \
--namespace cert-manager \
--from-literal=secret='<IHR_HMAC_KEY aus LEMARIT.app WebUI>'
Der HMAC-Key wird in der LEMARIT.app-Ansicht bereits im korrekten Format angezeigt und kann direkt in das Secret übernommen werden – eine zusätzliche Konvertierung ist nicht nötig.
ClusterIssuer definieren
solversemail
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: lemarit-issuer
spec:
acme:
server: https://acme.lemarit.cloud/directory
externalAccountBinding:
keyID: <IHR_KID aus LEMARIT.app WebUI>
keySecretRef:
name: lemarit-eab-secret
key: secret
privateKeySecretRef:
name: lemarit-account-key
solvers: []
CertificateCertificate
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-com-wildcard
namespace: default
spec:
secretName: example-com-tls
issuerRef:
name: lemarit-issuer
kind: ClusterIssuer
dnsNames:
- example.com
- "*.example.com"
kubectl get certificate -A
kubectl describe certificate example-com-wildcard
StatusReady: TrueEventsspec.renewBeforeCertificaterenewBefore: 720hcmctl
cmctl renew \
example-com-wildcard \
--namespace default
kubectl annotate certificate \
example-com-wildcard \
cert-manager.io/force-renew=true \
--overwrite
kubectl describe certificate example-com-wildcardEventsFür Setups außerhalb von Kubernetes ist acme.sh besonders minimal invasiv. Im Gegensatz zu Certbot greift es nicht automatisch in Ihre Server-Konfiguration ein, sondern beschränkt sich strikt auf die Zertifikats-Ausstellung und die Ablage der Schlüssel-Dateien. Ihre bestehende Apache- oder Nginx-Konfiguration bleibt unangetastet – ein realer Vorteil in Umgebungen, in denen Config-Änderungen dokumentiert oder review-pflichtig sind und in denen frühere Auto-Anpassungen schon einmal Nacharbeit erzeugt haben.
Die LEMARIT-RFC-2136-Schnittstelle ermöglicht Domainvalidierung via DNS-01 mit acme.sh nativ über den nsupdate-Hook.
curl https://get.acme.sh | sh
~/.acme.sh/sh -s email=admin@example.comnsupdateSchritt 2a – TSIG-Key-Datei anlegen
Die aus dem LEMARIT.app-WebUI exportierte Key-Datei folgt dieser Struktur (die konkreten Werte für Schlüsselname, Algorithmus und Secret erhalten Sie beim Export):
key "example-com-tsig" {
algorithm hmac-sha256;
secret "<Base64-Secret aus LEMARIT.app>";
};
/etc/lemarit/tsig-key.confchmod 600Schritt 2b – Umgebungsvariablen persistent hinterlegen
/etc/lemarit/acme.env
export NSUPDATE_SERVER="ddns.lemarit.cloud"
export NSUPDATE_KEY="/etc/lemarit/tsig-key.conf"
source /etc/lemarit/acme.env
--issue~/.acme.sh/account.confsourceKIDEinmalig: Account registrieren mit EAB
acme.sh --register-account \
--server https://acme.lemarit.cloud/directory \
--eab-kid <IHR_KID> \
--eab-hmac-key <IHR_HMAC_KEY>
Anschließend: Wildcard-Zertifikat ausstellen (EAB-Parameter entfallen)
acme.sh --issue \
--server https://acme.lemarit.cloud/directory \
--dns dns_nsupdate \
-d example.com \
-d '*.example.com'
~/.acme.sh/ca/
acme.sh --install-cert \
-d example.com \
--key-file /etc/nginx/ssl/example.com.key \
--fullchain-file /etc/nginx/ssl/example.com.crt \
--reloadcmd "systemctl reload nginx"
acme.sh --renew \
-d example.com \
--force
Statt einen ACME-Client zu konfigurieren, integrieren Sie LEMARIT direkt aus Ihrem Code oder Skript heraus. Authentifizierung über einen API-Key, optional eingeschränkt über Domain Patterns. Die typischen Operationen sind:
Die vollständige API-Referenz finden Sie in der LEMARIT.app-Dokumentation. Die unten skizzierten Beispiele zeigen das Grundgerüst; für einen produktions-reifen Einstieg stellt LEMARIT zusätzlich eine offizielle Bash-Referenz-Implementation auf GitHub bereit – Details in Schritt 4.
*.example.comapi.example.orgcurl
curl -X POST https://api.lemarit.cloud/v1/certificates \
-H "Authorization: Bearer ${LEMARIT_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"csr": "<base64-encoded CSR>",
"domains": ["example.com", "*.example.com"],
"ca": "default"
}'
order_idissued
curl https://api.lemarit.cloud/v1/certificates/<order_id> \
-H "Authorization: Bearer ${LEMARIT_API_KEY}"
Als Ausgangspunkt für eigene Automatisierungen stellt LEMARIT ein offizielles Bash-Beispiel bereit, das die Bestell- und Abhol-Logik aus Schritt 2 und 3 in eine produktions-reife Struktur verpackt:
LEMARIT Certificate API – Order Certificates (Bash Example)
Das Projekt implementiert insbesondere zwei operative Details, die im Do-It-Yourself-Setup häufig übersehen werden:
Sie können das Repository direkt in Ihre Ansible-/Chef-/Puppet-Pipeline einbinden, an Ihre Umgebung anpassen oder als Blueprint für eine Portierung in Python, Go oder Ihre bevorzugte Sprache verwenden.
Die in dieser Anleitung gezeigten Setups skalieren technisch: Auf einem Server funktionieren sie genauso wie auf hundert oder tausend. Der Konfigurations-Aufwand pro System bleibt der gleiche. Das ist die gute Nachricht.
Die weniger gute: Mit jeder zusätzlichen ACME-Instanz wachsen im reinen Eigenbetrieb drei Blackbox-Risiken.
Governance-Blackbox. Jeder Server interagiert autark mit Let’s Encrypt oder einer anderen öffentlichen CA. Es gibt keine übergreifende Sicht darüber, welche Zertifikate ausgestellt sind, welche Domains eingebunden werden oder welche Configs zwischenzeitlich manuell nachgebessert wurden. Sobald der Admin, der das Setup einmal eingerichtet hat, das Unternehmen verlässt, ist das kollektive Wissen praktisch verloren.
Kompromittierungs-Blindheit. Wird ein einzelner Server kompromittiert, kann ein Angreifer über den lokalen ACME-Client potenziell weitere Zertifikate ausstellen lassen. Weil keine zentrale Ausgabestelle existiert, fällt das erst auf, wenn irgendwo eine Anomalie beobachtet oder ein externes Monitoring anschlägt.
Audit-Silo. ISO 27001, NIS2 und DORA verlangen zunehmend lückenlose Nachweise darüber, wer wann welches Zertifikat für welche Domain ausgestellt hat. In einem Setup ohne zentrale Sammel-Instanz müssen diese Belege aus verstreuten Log-Dateien mühsam rekonstruiert werden.
acme.letsencrypt.orghttps://acme.lemarit.cloud/directoryKurz: Sie ändern nichts am „Wie“ Ihrer Setups – nur am „Wo“ die ACME-Anfragen letztlich landen. Und Sie legen damit die Governance-Ebene ein, die im reinen Do-It-Yourself-Modus strukturell fehlt.
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.
Wählen Sie den passenden ACME-Client für Ihre Umgebung (Certbot für Apache/Nginx, cert-manager für Kubernetes, acme.sh für Wildcard- und Container-Setups), installieren Sie ihn, beantragen Sie das Zertifikat per CLI oder Manifest und prüfen Sie, dass die automatische Verlängerung läuft. Die exakten Befehle finden Sie in den jeweiligen Schritt-Anleitungen oben.
Im Idealfall nichts. Die Clients erneuern Zertifikate automatisch. Empfehlenswert ist allerdings ein externes Monitoring – etwa ein wöchentlicher SSL-Check über einen Drittanbieter oder ein Monitoring-Tool – um sicherzustellen, dass keine Erneuerung verloren geht. Die LEMARIT Roadmap sieht vor, dass dieses Monitoring ebenfalls Teil der Certificate Lifecycle Management Plattform wird.
/.well-known/acme-challenge/*korrekt zum Origin durchreichen. Bei mehreren Origins muss das Token konsistent auf allen verfügbar sein – einfacher ist hier oft die Umstellung auf DNS-01.
https://acme-staging-v02.api.letsencrypt.org/directory), auf dem Sie das Setup beliebig oft testen können, ohne Rate-Limits zu beanspruchen. Die ausgestellten Zertifikate sind nicht produktiv vertrauenswürdig, aber technisch identisch. LEMARIT bietet auf Anfrage ebenfalls eine Test-Umgebung an.
~/.acme.sh/account.keyoder
/etc/letsencrypt/accounts/). Bei cert-manager sind die Account-Keys als Kubernetes-Secrets gespeichert und sollten Teil Ihres Cluster-Backups sein.
Dagegen brauchen Sie die aktuellen Zertifikats- und Schlüsseldateien selbst nicht zu sichern. Fällt ein System aus, stellt der ACME-Client über den gesicherten Account einfach neue Zertifikate aus – da diese seit der Laufzeit-Umstellung nicht als einzelne Einheit, sondern als Teil eines Abonnements über einen Zeitraum bezogen werden, entstehen dadurch keine zusätzlichen Kosten. Eine gezielte Wiederherstellung alter Zertifikate ist damit strukturell überflüssig.
