Let’s Encrypt ACME: Zertifikate automatisieren und Erneuerungen sicher steuern

ACME-Ablauf und getrennte Schlüsselrollen

ACME standardisiert die Kommunikation zwischen einem Client und der Zertifizierungsstelle, nicht die gesamte Betriebsumgebung. Der Client verwendet zunächst ein ACME-Konto und legt anschließend eine Order für einen oder mehrere Domainnamen an. Für jeden Identifier verlangt der Server eine Autorisierung. Erst wenn diese erfolgreich ist, kann der Client die Order mit einer Certificate Signing Request, kurz CSR, finalisieren und das ausgestellte Zertifikat abrufen.

1. Kontoschlüssel erzeugen oder vorhandenes ACME-Konto verwenden und die Order anlegen.
2. Für jeden angeforderten Identifier die vorgegebene Challenge bereitstellen und die Autorisierung abwarten.
3. Ein separates Schlüsselpaar für das Zertifikat erzeugen, daraus die CSR bilden und die Order finalisieren. Der öffentliche Schlüssel in der CSR darf nicht mit dem Kontoschlüssel übereinstimmen, der den Finalisierungsauftrag authentisiert.
4. Zertifikat und Zertifikatskette abrufen, geschützt ablegen und an die vorgesehenen TLS-Endpunkte verteilen.

De ACME-Kontoschlüssel authentisiert den Client für das Konto gegenüber dem ACME-Server und signiert die Protokollnachrichten. Der in der CSR verwendete private Schlüssel gehört dagegen zur späteren TLS-Identität. RFC 8555 verlangt zwei unterschiedliche Schlüsselklassen: Der öffentliche Schlüssel der CSR darf nicht einem bekannten Kontoschlüssel entsprechen und insbesondere nicht mit dem Kontoschlüssel identisch sein, der den Finalisierungsauftrag authentisiert. Client und Server müssen diese Trennung prüfen.

Bei DNS-01 kommt eine dritte sensible Komponente hinzu: die Berechtigung für die DNS-API. Let’s Encrypt weist darauf hin, dass vollständige DNS-API-Zugangsdaten auf einem Webserver die Folgen eines Angriffs deutlich vergrößern. Als betriebliche Sicherheitsmaßnahme sollte das Token deshalb möglichst nur die benötigten Challenge-Records ändern dürfen; alternativ kann die DNS-Validierung auf einem getrennten System erfolgen.

Kontoschlüssel, Zertifikatsschlüssel und DNS-Zugang bilden unterschiedliche Vertrauensbereiche. Für Konto und Zertifikat verschiedene Schlüsselpaare zu verwenden, ist eine Protokollanforderung; ihre getrennte Ablage, eng begrenzte Zugriffsrechte und unabhängige Rotationsprozesse sind darüber hinaus wichtige betriebliche Maßnahmen. So muss ein kompromittiertes DNS-Token weder Zugriff auf den privaten Zertifikatsschlüssel noch auf das ACME-Konto bedeuten.

Automatisierung beseitigt keine fehlerhaften Voraussetzungen. Ein nicht erreichbarer Port, falsches Routing, eine unpassende DNS-Delegation oder zu weit reichende Zugriffsrechte bleiben Betriebsprobleme, auch wenn die Order-Erstellung automatisiert ist. ACME beschleunigt den wiederholbaren Ablauf; ein Rechtekonzept, die vorgeschriebene Trennung von Konto- und Zertifikatsschlüssel, sichere Ablage sowie die Kontrolle der tatsächlich ausgelieferten Zertifikate müssen Betreiber in ihrer Umgebung zuverlässig umsetzen.

Die passende Challenge für die Infrastruktur

Die Challenge bestimmt, wie eine Zertifizierungsstelle die Kontrolle über einen Identifier prüft. Sie sollte daher aus Netzweg, DNS-Verwaltung und TLS-Terminierung abgeleitet werden, nicht aus einer pauschalen Präferenz für ein Client-Werkzeug. HTTP-01, DNS-01 und TLS-ALPN-01 belegen unterschiedliche Arten der Kontrolle und stellen entsprechend andere Anforderungen an Infrastruktur und Berechtigungen.

Für eine einzelne, öffentlich erreichbare Website ist HTTP-01 meist der direkteste Weg. Der Client stellt eine Ressource unter /.well-known/acme-challenge/ bereit, die Let’s Encrypt über Port 80 abruft. Zeigt eine Domain auf mehrere A- oder AAAA-Ziele, muss diese Ressource auf allen Systemen erreichbar sein, die der Validierungsabruf treffen kann. Andernfalls entsteht ein nur gelegentlich auftretender Validierungsfehler.

Wildcard-Zertifikate für *.example.org erfordern dagegen zwingend DNS-01. Der Client veröffentlicht dafür einen TXT-Record unter _acme-challenge.example.org. Das passt zu vielen dynamischen Subdomains, verteilten Webservern oder einem Load Balancer, weil keine einzelne HTTP-Instanz die Validierungsdatei ausliefern muss. Voraussetzung ist jedoch eine verlässliche, automatisierbare DNS-Änderung.

Ein Reverse Proxy ohne nutzbaren Port 80 kann TLS-ALPN-01 einsetzen, sofern er die TLS-Terminierung auf Port 443 kontrolliert und der verwendete Client diese Challenge unterstützt. Die Validierung erfolgt über eine spezielle TLS-Verbindung, nicht über eine normale Webdatei. Das Verfahren eignet sich damit besonders für spezialisierte Proxy- oder Hosting-Infrastruktur, aber nicht als allgemeiner Ersatz für HTTP-01. Wildcards werden auch hier nicht unterstützt.

Keine Methode ist generell überlegen: HTTP-01 reduziert bei einer einfachen Website den DNS-Zugriff, DNS-01 ermöglicht Wildcards und entkoppelt die Validierung vom Webpfad, TLS-ALPN-01 nutzt gezielt vorhandene TLS-Kontrolle. Entscheidend ist, dass die gewählte Challenge unter realen Failover-, IPv4- und IPv6-Pfaden funktioniert und ihre Berechtigungen zum jeweiligen Betriebsmodell passen.

ARI, Profile und kürzere Laufzeiten

Met ACME Renewal Information (ARI) verschiebt sich die Erneuerungslogik von einem lokal festgelegten Stichtag zu einem vom ACME-Server empfohlenen Zeitfenster. Der Client fragt diese Information für ein vorhandenes Zertifikat ab und wählt innerhalb des Fensters einen zufälligen Zeitpunkt. Dadurch können Erneuerungen zeitlich verteilt und bei besonderen Ereignissen gezielt vorgezogen werden.

ARI ist eine standardisierte Erweiterung, aber keine automatische Eigenschaft jedes installierten Clients oder Hosting-Panels. Let’s Encrypt kann neue rückwärtskompatible ACME-Funktionen am bestehenden Endpunkt anbieten; ob eine konkrete Installation sie nutzt, hängt von deren Version und Implementierung ab. Für größere Bestände ist daher zu prüfen, ob der Client ARI abfragt, das Zeitfenster respektiert und Erneuerungen nicht wieder synchronisiert.

Let’s Encrypt ordnet Orders außerdem Zertifikatsprofilen zu. Ohne ausdrückliche Profilwahl ist das klassische Profil der Standard und hat derzeit 90 Tage Laufzeit. Das Profil tlsserver hat 45 Tage Laufzeit, kürzere Fristen für offene Autorisierungen und Orders sowie höchstens 25 DNS-Namen. shortlived verwendet ebenfalls kurze Objektfristen, ist rund 160 Stunden gültig und unterstützt DNS- sowie IP-Identifier.

Die Profilauswahl setzt ebenfalls Client-Unterstützung voraus; sie sollte nicht allein aus der Serverdokumentation abgeleitet werden. Profile unterscheiden sich neben Laufzeit und Identifiern auch in weiteren Eigenschaften. Anwendungen und Inventarisierungswerkzeuge dürfen daher weder einen einheitlichen Ablauf noch das Vorhandensein eines Common Name in jedem Zertifikat stillschweigend voraussetzen.

Rechnerisch liegen zwischen 90 Tagen und rund 160 Stunden etwa Faktor 13,5 in der Laufzeit. Daraus folgt keine gemessene Last, aber eine klare Planungsfolge: Jede Störung bei Bestellung, Verteilung oder Reload wird bei kurzlebigen Zertifikaten viel früher kritisch. Sie sind nur für Systeme sinnvoll, deren vollständige Lieferkette überwacht ist und deren Erneuerung nicht von manuellen Eingriffen abhängt. Für ARI-koordinierte Erneuerungen gelten bei Let’s Encrypt unter dokumentierten Voraussetzungen besondere Regeln zu Rate Limits.

Challenge-Matrix und sichere DNS-Delegation

Die Wahl der Challenge folgt der erreichbaren Infrastruktur, nicht einer allgemeinen Rangfolge. HTTP-01 verlangt eine öffentlich erreichbare Antwort über Port 80, DNS-01 einen kontrollierbaren TXT-Eintrag und TLS-ALPN-01 die Kontrolle über die TLS-Terminierung auf Port 443. Wildcard-Namen sind ausschließlich mit DNS-01 validierbar.

Eine Website mit einem einzigen Webserver ist daher häufig mit HTTP-01 gut bedient. Zeigen DNS-A- oder AAAA-Records jedoch auf mehrere Systeme, muss jedes tatsächlich erreichte Ziel die erwartete Ressource ausliefern. Andernfalls hängt das Ergebnis davon ab, welchen Endpunkt die Validierung erreicht. Ein Load Balancer oder eine zentral synchronisierte Challenge-Ablage beseitigt dieses Problem nur, wenn sie alle Wege abdeckt.

Für DNS-01 ist als Minimalberechtigung anzustreben, dass der ACME-Client nur die benötigten Challenge-Einträge verändern kann. Welche Einschränkung tatsächlich möglich ist, hängt von der API und dem Berechtigungsmodell des DNS-Anbieters ab; nicht jeder Dienst erlaubt Rechte für einen einzelnen TXT-Namen. Bleibt nur ein weitreichender Zugang, sollten die Validierung auf ein getrenntes System verlagert oder eine gesonderte Challenge-Zone delegiert werden. Zugangsdaten gehören getrennt von Zertifikats- und ACME-Kontoschlüsseln in eine geschützte Ablage.

Bei umfangreichen Zonen kann eine separate Challenge-Zone die Rechte weiter eingrenzen. Die Delegation von _acme-challenge per CNAME oder NS verlagert die Validierungsdaten in einen eigenen Verwaltungsbereich. Der Client erhält dann nur dort Änderungsrechte. Vor der Produktivnutzung müssen TXT-Inhalt und DNS-Auflösung geprüft werden: Eine korrekte API-Antwort genügt nicht, wenn Resolver die Delegation oder den Record noch nicht sehen.

Erneuerung und Verteilung zuverlässig automatisieren

Belastbares Certificate Management endet nicht mit dem Abruf eines Zertifikats. In einer verteilten Umgebung löst ein zentraler ACME-Worker die Validierung aus und legt Zertifikat sowie privaten Schlüssel geschützt ab. Erst danach werden die Artefakte an die TLS-Endpunkte verteilt, dort geprüft und kontrolliert aktiviert. Der in der CSR verwendete Zertifikatsschlüssel muss sich vom authentisierenden ACME-Kontoschlüssel unterscheiden; wie beide Schlüssel anschließend getrennt gespeichert, berechtigt und rotiert werden, ist im Betriebskonzept festzulegen.

Die folgende Tabelle beschreibt ein empfohlenes Betriebskonzept für die Lieferkette. RFC 8555 verlangt, dass der öffentliche Schlüssel der CSR keinem bekannten Kontoschlüssel entspricht und insbesondere nicht mit dem zur Authentisierung des Finalisierungsauftrags verwendeten Kontoschlüssel übereinstimmt. Die konkrete organisatorische Trennung von Ablage, Zugriffsrechten und Rotation baut auf dieser Protokollanforderung auf. Der Deploy Hook von Certbot ist für Aktionen nach erfolgreicher Ausstellung vorgesehen. Übertragungsabsicherung, Zielprüfung und externe TLS-Prüfung müssen zur jeweiligen Infrastruktur passen.

Für Änderungen an Panel- oder DNS-Integrationen sollte die produktive Kette nicht als Einzelsystem betrachtet werden. Insbesondere bei einer Verwaltung über Plesk-Updates für Hosting-Anbieter hängen verfügbare Funktionen von Panelstand, Erweiterung und angebundenen Diensten ab. Die konkrete ACME-Client-Fähigkeit, etwa für zusätzliche Protokollerweiterungen, ist ebenfalls versionsabhängig und muss in der eingesetzten Kombination geprüft werden.

Bei Certbot kann ein Deploy Hook den letzten Schritt auslösen, weil er nur nach einer erfolgreichen Erneuerung läuft. Das folgende Muster setzt voraus, dass der lokale Pfad ein geprüftes, ausführbares Skript ohne Zugangsdaten ist. Das Skript sollte idempotent arbeiten, Fehler protokollieren und ausschließlich Dienste neu laden, die das erneuerte Zertifikat verwenden.

certbot renew --deploy-hook /usr/local/sbin/reload-tls-services

Der Exit-Status von certbot renew ist kein Nachweis für ein neues Zertifikat: Auch wenn nichts zu erneuern war, kann der Befehl mit Status 0 enden. Die Überwachung muss daher unabhängig feststellen, welches Zertifikat der öffentliche Endpunkt tatsächlich ausliefert, wann es abläuft und ob der Reload erfolgreich war.

CAA, Profile und Zertifikate für IP-Adressen

Ein CAA-Record ist ein Ausstellungs-Geländer: Er legt fest, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen. Zusätzlich kann die Richtlinie die erlaubte Validierungsmethode und über den Parameter accounturi das vorgesehene ACME-Konto festlegen. Der aktuelle Kontoschlüssel authentisiert den Zugriff auf dieses Konto, kann jedoch über den ACME-Key-Change-Prozess gewechselt werden. Die Kontobindung ersetzt daher weder den Schutz des aktuellen Kontoschlüssels noch ein umfassendes Berechtigungskonzept.

Die folgende Record-Zeile erlaubt Let’s Encrypt für die Domain nur bei DNS-01-Validierung. Sie passt nur, wenn DNS-01 automatisiert eingerichtet ist und die Challenge-Zone zuverlässig verwaltet wird. Wer später HTTP-01 für eine einzelne Website oder TLS-ALPN-01 für einen Reverse Proxy nutzen will, blockiert diese Ausstellung mit der gezeigten Einschränkung bewusst.

example.org. CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

Die einzelne Zeile beschreibt nicht zwangsläufig die vollständige CAA-Policy der Zone. Mehrere Records desselben Typs wirken additiv: Erlaubt einer davon die Ausstellung, kann diese Erlaubnis trotz engerer weiterer Records bestehen. Für Wildcard-Zertifikate ist außerdem zu prüfen, ob issuewild-Records vorhanden sind. Ohne solche Records gilt issue auch für Wildcards; vorhandene issuewild-Einträge steuern die Wildcard-Ausstellung dagegen gesondert. Maßgeblich ist deshalb immer der vollständige wirksame Record-Satz am geprüften Namen.

Zertifikate für öffentliche IP-Adressen sind ein anderer Fall als Domain-Zertifikate. Let’s Encrypt unterstützt IP-Identifier im Profil shortlived; als Validierung kommen HTTP-01 und TLS-ALPN-01 infrage. DNS-01 kann keine IP-Adresse validieren. Die kurze Gültigkeit von ungefähr 160 Stunden setzt deshalb eine durchgängige automatisierte Erneuerung, Verteilung und Auslieferungskontrolle voraus.

Das shortlived-Profil eignet sich damit etwa für direkt per IP erreichbare Schnittstellen nur dann, wenn jeder Schritt ohne manuelle Eingriffe funktioniert. Es ist keine verkürzte Variante für gelegentlich gepflegte Systeme. Außerdem müssen eingesetzter ACME-Client und Zielumgebung die Profilwahl sowie die gewählte Challenge unterstützen; die Verfügbarkeit am ACME-Dienst belegt keine Unterstützung durch jede Client-Version.

Monitoring und Fehlersuche zuerst im Staging

Fehlersuche bei ACME beginnt mit dem tatsächlich verwendeten Validierungsverfahren, nicht mit einem erneuten Zertifikatsauftrag. Für Änderungen an Client, Routing, Firewall oder DNS eignet sich der getrennte Staging-Endpunkt von Let’s Encrypt. Die Staging-Umgebung hat eigene, deutlich höhere Limits, ist aber nicht unbegrenzt; die dort ausgestellten Testzertifikate sind nicht öffentlich vertrauenswürdig. Neue Protokollfunktionen können zwar am ACME-Endpunkt verfügbar sein, die Unterstützung des installierten Clients muss dennoch gesondert geprüft werden.

Bei HTTP-01 ist zuerst zu prüfen, ob die betroffene Domain öffentlich über Port 80 erreichbar ist und die angeforderte Datei unter /.well-known/acme-challenge/ am Zielsystem ausliefert. Mehrere A- oder AAAA-Records machen den Test anspruchsvoller: Jeder tatsächlich erreichbare Endpunkt muss die passende Challenge-Datei bereitstellen. Typische Ursachen sind ein abweichendes Virtual-Host-Routing, ein vorgeschalteter Proxy, eine Firewall-Regel oder nicht synchronisierte Container.

TLS-ALPN-01 verlangt dagegen Kontrolle über die TLS-Terminierung auf Port 443. Bei einem Fehler sollte geprüft werden, welcher Load Balancer oder Proxy die Verbindung annimmt, ob er das für die Challenge benötigte Zertifikat ausliefert und ob ein regulärer TLS-Dienst den Vorgang überschreibt. Eine erfolgreich erzeugte lokale Zertifikatsdatei belegt nicht, dass der öffentlich angesprochene Endpunkt sie verwendet.

Bei DNS-01 sind Name und Inhalt des TXT-Records unter _acme-challenge getrennt zu kontrollieren. Der Record muss in der delegierten oder maßgeblichen Zone publiziert sein; außerdem muss die Delegationskette stimmen, wenn eine separate Challenge-Zone verwendet wird. Wiederholte Fehlversuche wegen Tippfehlern, noch nicht sichtbarer Änderungen oder fehlerhafter Delegation sollten zunächst im Staging analysiert werden.

Wirksames Controle beobachtet nicht nur das Ablaufdatum in der Ablage des ACME-Workers. Es prüft unabhängig den ausgelieferten Hostnamen, die Restlaufzeit des dort präsentierten Zertifikats und den Erfolg des Reloads nach einer Aktualisierung. Alarmiert werden sollte auch, wenn eine Erneuerung fehlschlägt oder ein Endpunkt trotz erfolgreicher Ausstellung noch das alte Zertifikat ausliefert. Für geplante Änderungen an Hosting-Servern ergänzt der Beitrag cPanel- und WHM-Updates sicher planen die notwendige Betriebsplanung.

Rate Limits und Erneuerungen im Bestand

In einem Zertifikatsbestand sind Rate Limits eine Entwurfsbedingung der SSL-Automatisierung. Täglich erzwungene Erneuerungen oder zeitgleich gestartete Jobs erzeugen unnötige Orders und können Begrenzungen auslösen. Das gilt besonders, wenn ein Infrastrukturfehler viele Domains zugleich betrifft: Wiederholungen beheben weder fehlende Challenge-Dateien noch falsches DNS, erhöhen aber die Zahl fehlgeschlagener Validierungen. Fehler müssen daher vor dem nächsten produktiven Lauf eingegrenzt werden.

ACME Renewal Information, kurz ARI, ersetzt starre lokale Schwellenwerte durch ein vom ACME-Server empfohlenes Erneuerungsfenster für ein vorhandenes Zertifikat. Der ARI-fähige Client fragt die Renewal Information ab und wählt einen zufälligen Zeitpunkt innerhalb dieses Fensters. Ein Scheduler kann den Client regelmäßig starten, wertet ARI aber nicht selbst aus. Der Client muss das empfohlene Fenster und Retry-After berücksichtigen sowie bei Fehlern geeignete Backoff- und Wiederholungsintervalle einhalten. Häufigere Scheduler-Läufe dürfen deshalb nicht zu ungebremsten Wiederholungen fehlgeschlagener Aufträge führen.

Für Let’s Encrypt können ARI-koordinierte Erneuerungen unter den dokumentierten Voraussetzungen von Rate Limits ausgenommen sein. Der neue Auftrag muss unter anderem mindestens einen Identifier des zu ersetzenden Zertifikats enthalten, und dieses darf nicht bereits über ARI ersetzt worden sein. Das ist keine allgemeine Freigabe für beliebige Neuaufträge: Änderungen am Zertifikatsumfang sind fachlich und operativ getrennt zu behandeln.

Insbesondere eine verkürzte oder veränderte SAN-Liste ist nicht automatisch eine Erneuerung des bisherigen Zertifikats. Ein Auftrag mit nur einem Teil der bisherigen Namen kann ein separates Zertifikat erzeugen, während das alte weiterhin gültig bleibt. Das Inventar sollte deshalb Zertifikatskennung, vollständige Identifier-Liste, zugeordnete Endpunkte und Erneuerungsweg erfassen. Vor einer geplanten SAN-Änderung ist zu entscheiden, welche Dienste umgestellt und wann nicht mehr benötigte Zertifikate entfernt werden.

Bei mehreren Workern verhindert eine eindeutige Zuständigkeit doppelte Orders für denselben Bestand. Sinnvoll sind ein zentraler Scheduler oder eine koordinierte Sperre, nachvollziehbare Protokolle und gestaffelte Wiederholungen nach einem Fehler. Die Zufallsauswahl innerhalb eines ARI-Fensters ist kein Ersatz für diese Steuerung, sondern reduziert vor allem die Gleichzeitigkeit regulärer Erneuerungen.

Das passende Betriebsmodell nach Risiko wählen

Für eine einzelne, öffentlich erreichbare Website ist HTTP-01 meist das einfachste Betriebsmodell. Der Webserver muss Port 80 zuverlässig bedienen und die Challenge-Datei am erwarteten Pfad ausliefern. Dieses Modell passt nicht zu Wildcards und wird fragil, wenn mehrere unabhängige Ziele dieselbe Domain beantworten. Es ist deshalb vor allem dann sinnvoll, wenn Webrouting, Zertifikatsablage und TLS-Auslieferung an einer klar kontrollierten Stelle zusammenlaufen.

DNS-01 ist das passende Modell für Wildcards, dynamische Subdomains und verteilte TLS-Endpunkte. Die Voraussetzung ist keine bloße DNS-Zugriffsmöglichkeit, sondern eine sicher automatisierbare Änderung des benötigten TXT-Records. Ein möglichst eng begrenztes Token oder eine delegierte Challenge-Zone reduziert die Folgen eines kompromittierten Systems. Welche Granularität erreichbar ist, hängt von der DNS-API ab. Delegationen müssen als produktive Abhängigkeit dokumentiert, überwacht und mit einem Wiederherstellungsweg versehen werden.

TLS-ALPN-01 eignet sich für Betreiber, die die TLS-Terminierung auf Port 443 gezielt steuern, etwa an einem Reverse Proxy oder Load Balancer. Die Methode ist weder ein pauschaler Ersatz für HTTP-01 noch wildcard-fähig. Ihre praktische Verwendbarkeit hängt zusätzlich von der jeweiligen Client- und Proxy-Implementierung ab. Vor dem Einsatz muss daher geprüft werden, ob die Software die Challenge erzeugen, ausliefern und nach Abschluss wieder sauber entfernen kann.

De shortlived-Profil ist nur für Systeme mit lückenloser End-to-End-Automatisierung geeignet. Let’s Encrypt beschreibt dafür eine Laufzeit von rund 160 Stunden sowie DNS- und IP-Identifier; gegenüber dem Standardprofil mit 90 Tagen erhöht dies die notwendige Erneuerungsfrequenz rechnerisch deutlich. Jeder Ablauf von Bestellung bis Verteilung, Reload und Außenprüfung muss daher belastbar funktionieren. Die Wahl eines Profils setzt zudem voraus, dass der eingesetzte ACME-Client die Profilauswahl tatsächlich unterstützt.

Unabhängig vom Modell braucht professionelles Certificate Management ein vollständiges Inventar, sicher verwaltete Schlüssel und minimal berechtigte DNS-Zugänge. Der Kontoschlüssel authentisiert den Client für das ACME-Konto; der in der CSR verwendete private Schlüssel gehört zur TLS-Identität. RFC 8555 verbietet, den öffentlichen Kontoschlüssel in einem Zertifikat zu verwenden: Der Schlüssel in der CSR darf insbesondere nicht mit dem Kontoschlüssel übereinstimmen, der den Finalisierungsauftrag authentisiert. Die getrennte Ablage, Berechtigungsvergabe und Rotation dieser Schlüsselklassen sowie widerrufbare Zugänge und ein getesteter Rückweg auf das vorherige Zertifikat gehören zum Rechte- und Notfallkonzept.

Ein erfolgreicher ACME-Lauf darf nicht das einzige Erfolgskriterium sein. Die Auslieferungskontrolle muss außerhalb des Workers feststellen, welches Zertifikat ein echter TLS-Endpunkt präsentiert. Für Verteilungs- und Reload-Schritte eignen sich Aktionen, die nur nach einer erfolgreichen Erneuerung ausgelöst werden; bei Certbot ist dafür ein Deploy Hook vorgesehen. Sein Skript sollte idempotent sein, Fehler protokollieren und nur Dienste neu laden, die das erneuerte Material tatsächlich nutzen.