Noch vor einigen Jahren war das Erhalten eines TLS-Zertifikats ein bürokratischer Albtraum. Ein Systemadministrator musste manuell einen Certificate Signing Request (CSR) erzeugen, ihn über ein Webportal einreichen, die domainbasierte Validierung per E-Mail abwarten, das Zertifikat herunterladen, den Webserver konfigurieren und — entscheidend — daran denken, denselben Prozess 12 Monate später vor dem Ablaufdatum zu wiederholen. Multipliziert man dies mit Hunderten oder Tausenden von Endpunkten in einer modernen Unternehmensumgebung, ergibt sich ein Rezept für kaskadierte Ausfälle, abgelaufene Zertifikate und erschöpfte Betriebsteams.

Das Automated Certificate Management Environment — kurz ACME — wurde entwickelt, um genau dieses Problem zu lösen. Standardisiert in RFC 8555, ist ACME ein Protokoll, das Clients und Zertifizierungsstellen (CAs) eine programmatische Kommunikation ermöglicht und jede Phase des Zertifikatslebenszyklus automatisiert: Ausstellung, Erneuerung und Widerruf. Let’s Encrypt, 2014 von der Internet Security Research Group (ISRG) gestartet, brachte ACME im großen Maßstab ins öffentliche Internet und gab damit Hunderte von Millionen kostenloser, vertrauenswürdiger TLS-Zertifikate aus — mit nachhaltiger Wirkung auf die Sicherheit des Webs.

Doch ACME ist nicht nur für öffentliche Webserver. Sein klar strukturiertes, gut dokumentiertes Protokollmodell hat es zu einer attraktiven Wahl für Enterprise-PKI-Deployments, private CAs, IoT-Geräteregistrierung und Protokollübersetzungsschichten gemacht, die Altsysteme mit modernen Zertifikatsverwaltungsworkflows verbinden. Dieser Artikel beleuchtet ACME aus der Perspektive von PKI-Ingenieuren — und analysiert Protokollmechaniken, Vertrauensmodell, Challenge-Typen, Implementierungsdetails und die Integration in bestehende Enterprise-PKI-Ansätze.

Die ACME-Protokollarchitektur: RFC 8555 unter der Lupe

Im Kern ist ACME ein JSON-over-HTTPS-Protokoll, das authentifizierte, zustandsbehaftete Interaktionen zwischen einem ACME-Client und einem ACME-Server (der CA) erzwingt. Jede relevante Operation wird mit JSON Object Signing and Encryption (JOSE) signiert — konkret im JSON Web Signature (JWS)-Format. Damit wird sichergestellt, dass Anfragen während der Übertragung nicht manipuliert werden und kryptografisch an das anfragende Konto gebunden sind.

Das Directory- und Nonce-Modell

Das Protokoll beginnt mit einem Directory-Endpunkt — einer bekannten URL (typischerweise /.well-known/acme/directory), die die Ressourcen-URLs der CA als JSON-Objekt bereitstellt. Clients ermitteln daraus die Endpunkte für Kontoerstellung, Auftragsübermittlung, Nonce-Abruf und Widerruf. Dieses Design ermöglicht versionsunabhängige Client-Implementierungen: Clients beginnen immer mit der Abfrage des Verzeichnisses, anstatt Ressourcenpfade fest zu kodieren.

Der Schutz vor Replay-Angriffen wird durch Nonces durchgesetzt. Jede POST-Anfrage muss einen frischen Replay-Nonce-Headerwert enthalten, der entweder über eine HEAD /new-nonce-Anfrage oder aus dem Replay-Nonce-Header der vorherigen Serverantwort bezogen wird. Der Server weist jede Anfrage zurück, die eine bereits verwendete Nonce trägt — damit wird verhindert, dass eine abgefangene JWS-signierte Nachricht durch einen Angreifer erneut verwendet werden kann, um eine unbeabsichtigte Zertifikatsausstellung auszulösen.

In einer realen Implementierung (wie etwa bei Enterprise-ACME-Servern auf Basis von ASP.NET Core) wird der Nonce-Pool als Concurrent Dictionary im Arbeitsspeicher verwaltet und nach der ersten Verwendung invalidiert. Der Server gibt in jeder Antwort eine neue Nonce im Header zurück, um den Vorrat des Clients kontinuierlich aufzufüllen.

Kontoverwaltung und External Account Binding

ACME-Konten werden über eine POST /new-account-Anfrage erstellt, deren Inhalt — signiert mit dem Schlüsselpaar des Clients — den öffentlichen Schlüssel, die Zustimmung zu den Nutzungsbedingungen und Kontaktinformationen enthält. Der Server antwortet mit einer Konto-URL und einem Kontoobjekt, das als dauerhafte Identität für nachfolgende Operationen dient.

Für private oder unternehmenseigene CA-Deployments ist External Account Binding (EAB) eine kritische Sicherheitserweiterung. EAB erfordert, dass der ACME-Client den Besitz eines MAC-Schlüssels nachweist, der von dem CA-Betreiber außerhalb des Protokolls ausgegeben wurde, bevor ein Konto erstellt werden kann. Der Client bettet ein JWS-signiertes EAB-Token in die Kontoerstellungsanfrage ein, und der Server validiert die MAC-Signatur gegen seinen gespeicherten Schlüssel. Dies versieht die Kontoerstellung mit einem administrativen Genehmigungsschritt — unverzichtbar für CAs, die Registrierungsrichtlinien durchsetzen, Zertifikate abrechnen oder ACME-Konten mit Organisationsidentitäten in einem IAM-System verknüpfen müssen.

In Enterprise-Implementierungen sind EAB-Delimiter und MAC-Schlüssel typischerweise an einen bereitgestellten externen Kontodatensatz gebunden, wobei die organisatorischen Attribute des Kontos (Abteilung, Kostenstelle, Geräteeigentümer) über richtliniengesteuerte Mapping-Engines in den Subject Distinguished Name oder die Subject Alternative Names des Zertifikats einfließen.

Der Order-Lebenszyklus: Vom CSR zum signierten Zertifikat

Der ACME-Order-Lebenszyklus ist der zentrale Workflow des Protokolls. Ein präzises Verständnis davon ist essenziell für jeden, der eine ACME-Implementierung aufbaut oder debuggt.

Schritt 1 — Auftrag einreichen

Der Client sendet eine new-order-Anfrage mit den Identifikatoren, für die er Zertifikate beantragt — in der Regel DNS-Namen, wobei ACME-Erweiterungen auch IP-Adressen und E-Mail-S/MIME unterstützen. Der Server erstellt ein Order-Objekt im Zustand pending und gibt dessen URL zusammen mit einer Liste von Authorization-URLs (eine pro Identifikator) und einer finalize-URL zurück.

Schritt 2 — Autorisierungen und Challenges abschließen

Für jeden Identifikator stellt der Server ein Authorization-Objekt bereit, das ein oder mehrere Challenge-Objekte enthält. Der Client muss mindestens eine Challenge pro Autorisierung erfüllen, um die Kontrolle über den Identifikator nachzuweisen. Die drei Standard-Challenge-Typen sind:

• HTTP-01: Der Client platziert ein Key-Authorization-Token unter http://<domain>/.well-known/acme-challenge/<token>. Die CA ruft diese URL über Port 80 ab und prüft, ob die Antwort dem erwarteten SHA-256-Fingerabdruck des Kontoschlüssels entspricht.
• DNS-01: Der Client provisioniert einen _acme-challenge.<domain> TXT-Eintrag mit einem base64url-kodierten SHA-256-Digest der Key Authorization. Die CA führt eine DNS-Abfrage zur Verifizierung durch. Dieser Typ unterstützt Wildcard-Zertifikate und funktioniert auch für Domains, die vom öffentlichen Internet nicht erreichbar sind.
• TLS-ALPN-01: Der Client stellt ein selbstsigniertes Zertifikat auf Port 443 bereit, das über einen speziellen ALPN-Protokollidentifikator (acme-tls/1) ausgehandelt wird und die Key Authorization in einer benutzerdefinierten X.509-Erweiterung enthält. Die CA stellt eine Verbindung her und inspiziert das Zertifikat.

Der Client signalisiert Bereitschaft durch eine POST-Anfrage an die Challenge-URL. Der Server versetzt die Challenge in den Zustand processing, führt die Validierung durch und markiert bei Erfolg sowohl die Challenge als auch die übergeordnete Autorisierung als valid. Schlägt die Validierung fehl, wechselt die Autorisierung zu invalid, und der Auftrag muss mit einer neuen Nonce und frischen Challenge-Tokens wiederholt werden.

Enterprise-ACME-Server unterstützen typischerweise konfigurierbare Challenge-Typ-Sets — zum Beispiel nur DNS-01 für Wildcard-Aufträge und sowohl HTTP-01 als auch DNS-01 für Einzelnamen-Zertifikate. Wildcard-DNS-Namen (*.beispiel.de) erfordern DNS-01, da die HTTP-01-Validierung grundsätzlich mit Wildcard-Semantik unvereinbar ist.

Schritt 3 — Auftrag finalisieren

Sobald alle Autorisierungen gültig sind, erzeugt der Client einen PKCS#10-CSR für die beantragten Identifikatoren und sendet ihn an die finalize-URL. Der Server validiert den CSR — prüft, ob die Identifikatoren mit den autorisierten übereinstimmen, ob Schlüsselalgorithmus und -länge den Richtlinienanforderungen entsprechen und ob keine unzulässigen Erweiterungen vorhanden sind — und leitet die Anfrage dann zur Signierung an die zugrundeliegende CA weiter.

Der Auftrag wechselt über processing zu valid, woraufhin eine certificate-URL im Auftragsobjekt erscheint. Der Client lädt das signierte Zertifikat (und optional die Vertrauenskette) über eine POST-as-GET-Anfrage an diese URL herunter.

Zertifikatsauslieferungsformat

Ein korrekt implementierter ACME-Server gibt Zertifikate im PEM-Format zurück. Bei der Kettenauslieferung wird das End-Entity-Zertifikat dem ausstellenden CA-Zertifikat vorangestellt und durch Zeilenumbrüche getrennt. Clients, die DER-Kodierung benötigen, müssen clientseitig konvertieren. In Implementierungen, die auf BouncyCastle oder .NETs X509Certificate2 aufsetzen, kann die PEM-Kodierung zuverlässig mit PemEncoding.Write(„CERTIFICATE“, cert.RawData) erzeugt werden.

Let’s Encrypt: ACME im Internetmaßstab

Let’s Encrypt ist gleichzeitig die bekannteste ACME-CA und der Beweis dafür, dass die kommerzielle Zertifikatsindustrie ihr Monopol auf grundlegende Web-Sicherheit verloren hat. Als gemeinnützige Organisation betrieben, hat Let’s Encrypt seit seiner Gründung über drei Milliarden Zertifikate ausgestellt und sichert etwa die Hälfte aller HTTPS-fähigen Websites im Internet ab.

Was Let’s Encrypt technisch auszeichnet

Mehrere Designentscheidungen machen die Implementierung von Let’s Encrypt aus PKI-Sicht besonders interessant:

Kurze Zertifikatslaufzeiten. Let’s Encrypt stellt 90-Tage-Zertifikate aus — absichtlich kürzer als der damalige Branchenstandard von 1–2 Jahren. Die Begründung ist sicherheitshygienisch: Kürzere Laufzeiten verringern das Zeitfenster für kompromittierte private Schlüssel und fördern die Automatisierung, denn kein vernünftiger Administrator möchte alle 90 Tage manuell erneuern. Diese Designentscheidung hat das CA/Browser Forum beeinflusst, die maximale Zertifikatsgültigkeit schrittweise zu verkürzen — nach aktuellen Vorschlägen könnte sie bis 2027 auf 47 Tage sinken.

Certificate Transparency (CT) Logging. Jedes von Let’s Encrypt ausgestellte Zertifikat wird vor der Auslieferung in mehrere CT-Logs eingetragen. Dies macht die Ausstellung öffentlich prüfbar — jeder Domaininhaber kann CT-Logs auf nicht autorisierte Zertifikatsausstellungen für seine Domains überwachen, etwa mit Tools wie crt.sh oder Googles CT Monitor.

Cross-signiertes Root-Vertrauen. Let’s Encrypts Root-CA (ISRG Root X1) wurde anfangs nicht von allen Gerätezertifikatsspeichern vertraut, insbesondere nicht von älteren Android-Versionen. Um breite Kompatibilität zu erreichen, wurden Let’s Encrypts Intermediate-Zertifikate von IdenTrusts DST Root CA X3 cross-signiert. Die Verwaltung dieses Vertrauenskettenübergangs — insbesondere als DST Root CA X3 im September 2021 ablief — wurde zu einem weithin bekannten Vorfall, der Millionen älterer Android-Geräte betraf und eine anschauliche Lektion in PKI-Vertrauenskettenmanagement darstellte.

Boulder — die Open-Source-CA. Let’s Encrypt betreibt Boulder, einen vollständig quelloffenen ACME-Server, der in Go geschrieben ist. Boulder setzt Rate-Limits durch (50 Zertifikate pro registrierter Domain pro Woche, 5 fehlgeschlagene Validierungsversuche pro Konto pro Hostname pro Stunde usw.) und dient als Referenzimplementierung für ACME-Server-Konformität.

Beliebte ACME-Clients für Let’s Encrypt

Das Client-Ökosystem rund um Let’s Encrypt ist vielfältig:

• Certbot — der kanonische Let’s Encrypt-Client, gepflegt von der EFF. Unterstützt HTTP-01 und DNS-01 mit Dutzenden DNS-Provider-Plugins.
• acme.sh — ein reines POSIX-Shell-Skript mit umfangreichem DNS-Provider-Support, beliebt in Linux/Unix-Umgebungen.
• win-acme — der führende Windows-Client mit IIS-Integration und Unterstützung für ACME-EAB bei Enterprise-CAs.
• LEGO — ein Go-basierter Client mit starker DNS-Challenge-Unterstützung, häufig in Kubernetes- und Container-Umgebungen eingesetzt.
• cert-manager — der Kubernetes-native Zertifikatsverwaltungscontroller, der Let’s Encrypt und private ACME-CAs über ein deklaratives CRD-Modell unterstützt.

ACME im Enterprise-PKI: Private CAs und Protokollübersetzung

Während Let’s Encrypt die Stärke von ACME für öffentliche Internetanwendungsfälle demonstriert hat, ist das saubere Protokolldesign ebenso überzeugend für Enterprise-PKI-Umgebungen, in denen Organisationen private oder verwaltete CAs betreiben.

Warum Unternehmen ACME intern einsetzen

Enterprise-PKI hat traditionell auf Protokolle wie SCEP (Simple Certificate Enrollment Protocol), CMP (Certificate Management Protocol) oder proprietäre Hersteller-APIs gesetzt. ACME bietet gegenüber diesen Ansätzen mehrere Vorteile:

• Standardisierung: RFC 8555 ist eindeutig und gut gepflegt. Clients und Server verschiedener Hersteller sind zuverlässig interoperabel.
• Reichhaltiges Client-Ökosystem: Unternehmen können vorhandene ACME-Clients nutzen, anstatt eigene Registrierungsagenten zu entwickeln.
• Automatisierungsorientiertes Design: ACME’s zustandsbehafteter Order-Lebenszyklus und das Challenge-Modell sind für Maschine-zu-Maschine-Betrieb konzipiert — sie fügen sich natürlich in CI/CD-Pipelines, Infrastructure-as-Code-Workflows und Service Meshes ein.
• EAB für Richtliniendurchsetzung: External Account Binding ermöglicht es Enterprise-CAs, die Registrierung hinter organisatorischer Authentifizierung zu sichern — ACME-Konten können an LDAP-Identitäten, IAM-Rollen oder Gerätezertifizierungsdatensätze gebunden werden.

Protokollübersetzungsschichten

Ein anspruchsvolles Muster in Enterprise-ACME-Deployments ist die Protokollübersetzungsschicht — eine Middleware-Komponente, die eine RFC 8555-konforme ACME-Server-Schnittstelle für Clients bereitstellt und Anfragen dabei in das native Protokoll eines zugrundeliegenden CA-Backends übersetzt. Dies ermöglicht es Organisationen, moderne ACME-Clients (Certbot, cert-manager, win-acme) gegen Legacy-CA-Infrastruktur einzusetzen, die ACME nicht nativ spricht.

In solchen Architekturen pflegt der ACME-Provider seine eigene Auftragszustandsmaschine — mit Verfolgung von Konten, Autorisierungen, Challenges und Auftragsstatus in einem konkurrenten Transaktionsspeicher — während die eigentliche Zertifikatssignierung über die native API an das Backend-CA delegiert wird (CMP, proprietäres REST, PKCS#12-Auslieferung usw.). Der Protokollübersetzer übernimmt JWS-Validierung, Nonce-Verwaltung, Challenge-Orchestrierung und Zertifikatsformat-Konvertierung unabhängig von den Fähigkeiten der Backend-CA.

Die wichtigsten technischen Herausforderungen bei einer Protokollübersetzungsschicht umfassen:

• Zustandssynchronisierung: Die ACME-Auftragszustandsmaschine muss konsistent bleiben, auch wenn die Backend-CA-Anfrage asynchron fehlschlägt. Dies erfordert typischerweise einen persistenten Auftragsspeicher mit Transaktionssemantik — kein reines In-Memory-Dictionary.
• CSR-Validierung und Richtliniendurchsetzung: Bevor ein CSR an die Backend-CA weitergeleitet wird, muss der Übersetzer Benennungsrichtlinien durchsetzen — Prüfung, ob angeforderte Subject-DN-Attribute und SANs den organisatorischen Regeln entsprechen, ob verbotene OIDs fehlen und ob Schlüsselalgorithmus- und Längenbeschränkungen eingehalten werden.
• Challenge-Delegation: Für HTTP-01 und DNS-01 Challenges muss der Übersetzer entweder selbst validieren oder mit der DNS/HTTP-Infrastruktur koordinieren, die er kontrolliert. In privaten Netzwerken, in denen der ACME-Server Client-Endpunkte nicht aus dem öffentlichen Internet erreichen kann, ist häufig der Einsatz von Challenge-Responder-Agenten innerhalb des privaten Netzwerks erforderlich.
• Zertifikatsketten-Assemblierung: Das ACME-Protokoll liefert das End-Entity-Zertifikat und seine Kette als PEM-kodierte Daten. Der Übersetzer muss die Kette aus Backend-CA-Antworten korrekt zusammenstellen, die Zertifikate möglicherweise im DER-, PKCS#7- oder CMC-Format liefern, und dabei bei Bedarf Formatkonstantierung durchführen.

Sicherheitsaspekte: Was schiefgehen kann

Die Automatisierungsvorteile von ACME gehen mit einem spezifischen Bedrohungsmodell einher, das Implementierer tiefgreifend verstehen müssen.

Schlüsselkompromittierung und Kontosicherheit

Das ACME-Konto wird durch das Schlüsselpaar des Clients gesichert. Wird der private Schlüssel kompromittiert, erhält ein Angreifer die Möglichkeit, Zertifikate für alle zuvor unter diesem Konto autorisierten Identifikatoren anzufordern und zu empfangen. Gegenmaßnahmen umfassen:

• Schlüsselrotation: ACME unterstützt Schlüsselwechsel über eine signierte key-change-Anfrage, die den Kontoschlüssel atomar ersetzt.
• Hardware Security Module (HSMs): Das Speichern des ACME-Kontoschlüssels in einem HSM verhindert die Extraktion, selbst wenn das Client-System kompromittiert wird.
• EAB-Schlüsselverwaltung: EAB-MAC-Schlüssel sollten wie Zugangsdaten behandelt und regelmäßig rotiert werden. Ihre Kompromittierung erlaubt die unbefugte Kontoerstellung.

Challenge-Validierungsrisiken

HTTP-01 und DNS-01 Challenges haben unterschiedliche Angriffsflächen. HTTP-01 ist anfällig, wenn ein Angreifer Inhalte unter dem Challenge-Pfad auf Port 80 bereitstellen kann — etwa durch Ausnutzung einer Open-Redirect- oder Cache-Poisoning-Schwachstelle auf dem Zielwebserver. DNS-01 ist anfällig für DNS-Hijacking-Angriffe, insbesondere in Umgebungen mit schwacher DNSSEC-Akzeptanz.

Multi-Perspective Issuance Validation (MPIC), von Let’s Encrypt eingeführt und zunehmend durch die CA/Browser-Forum-Richtlinie gefordert, mindert DNS-basierte Angriffe, indem die Challenge-Validierung gleichzeitig von mehreren Netzwerk-Vantage-Points aus durchgeführt wird. Ein Angreifer müsste DNS-Antworten von mehreren geografisch und topologisch verschiedenen Standorten gleichzeitig übernehmen, um Erfolg zu haben.

Rate-Limiting und Missbrauchsschutz

Öffentliche ACME-CAs setzen Rate-Limits durch, um Missbrauch zu verhindern. Let’s Encrypts Limits sind gut dokumentiert, können aber legitime Nutzer bei großangelegten Deployments überraschen. Ingenieure, die ACME-Automatisierung für viele Subdomains einrichten, sollten ihre Registrierungsworkflows so gestalten, dass sie deutlich unterhalb der Rate-Limits bleiben, bei Fehlern exponentielles Backoff implementieren und die ACME-Staging-Umgebung (mit entspannten Limits) für Tests verwenden.

Zertifikatswiderruf in ACME

Der Widerruf in ACME erfolgt über eine POST /revoke-cert-Anfrage, bei der der Client das base64url-kodierte DER-Zertifikat und einen Widerrufsgrund-Code übermittelt. Der Server überprüft, ob der Antragsteller entweder den privaten Schlüssel des Zertifikats oder das zugehörige ACME-Konto kontrolliert, und leitet den Widerruf dann an das CA-Backend weiter.

ACMEs Widerrufsgrundcodes entsprechen direkt den X.509-CRLReason-Werten aus RFC 5280 — darunter keyCompromise, caCompromise, affiliationChanged, superseded, cessationOfOperation und unspecified. Die Semantik ist wichtig: keyCompromise (Grundcode 1) löst typischerweise einen sofortigen Widerruf aus und unterdrückt die Berechtigung zum Zertifikatssperren, während superseded (Code 4) je nach CA-Richtlinie unterschiedliche Auswirkungen auf das Verhalten des OCSP-Responders haben kann.

Ein kritisches operatives Problem ist die Widerruf-Propagationsverzögerung. Selbst nachdem eine ACME-CA eine Widerrufsanfrage verarbeitet hat, können OCSP-Responder bis zum Ablauf ihres nextUpdate-Intervalls — typischerweise mehrere Stunden — weiterhin gecachte good-Antworten liefern. CRL-Verteilungspunkte werden von vertrauenden Parteien möglicherweise ebenso lange nicht aktualisiert. Dies bedeutet, dass ein Widerruf im PKI niemals sofort wirksam ist — eine Tatsache, die Betriebsteams klar kommuniziert und in Incident-Response-Playbooks berücksichtigt werden muss.

Fazit: ACME ist die Zukunft der Zertifikatsautomatisierung

ACME hat sich von einer Let’s Encrypt-spezifischen Innovation zum dominierenden Standard für automatisiertes Zertifikatslebenszyklusmanagement sowohl in öffentlichen als auch in privaten PKI-Umgebungen entwickelt. Seine klar definierten Protokollsemantiken, das robuste Sicherheitsmodell, das reichhaltige Client-Ökosystem und die Erweiterbarkeit durch Mechanismen wie EAB und ACME ARI (Automated Certificate Renewal Information — ein Standardentwurf, der eine CA-gesteuerte proaktive Erneuerung ermöglicht) machen es zur richtigen Grundlage für jede Organisation, die Zertifikatsautomatisierung ernst nimmt.

Für PKI-Ingenieure und Architekten sind die wichtigsten Erkenntnisse klar: Das JWS/JOSE-Vertrauensmodell muss tief verstanden werden — jede Sicherheitsgarantie von ACME basiert auf der Integrität der Kontoschlüsselverwaltung. Challenge-Typen sollten bewusst gewählt werden — DNS-01 für Wildcards und interne Namen, HTTP-01 für Einfachheit wo Port-80-Zugang zuverlässig ist. EAB ist für jede private CA, die Registrierungsrichtlinien durchsetzen muss, als obligatorisch zu behandeln. Widerrufsworkflows müssen mit Propagationsverzögerungen im Hinterkopf gestaltet werden. Und kurze Zertifikatslaufzeiten sollten nicht als Last, sondern als Treiber für die Automatisierungsdisziplin betrachtet werden, die moderne Infrastruktur verlangt.

Let’s Encrypt hat bewiesen, dass kostenlose, automatisierte und allgegenwärtige TLS-Verschlüsselung erreichbar ist. ACME — als Protokollstandard unabhängig von einer einzelnen CA — stellt sicher, dass die von Let’s Encrypt eingeleitete Automatisierung für jede Organisation verfügbar ist, ob sie Zertifikate für öffentliche Webseiten, private Microservices, Maschinenidentitäten in einer Zero-Trust-Architektur oder IoT-Geräte ausstellt, die ab Werk registriert werden. Die Ära des manuellen Zertifikatsmanagements ist vorbei. Die Ära von ACME hat längst begonnen.