SSL/TLS-Zertifikate erneuern: Automatisierung, Sonderfälle und Kaufschwelle

⚡TL;DR

• Erneuerungen verbrauchen das Let's-Encrypt-Kontingent von 50 Zertifikaten pro registrierter Domain nicht. Dieses Limit misst den Zugang neuer Namen, nicht die Größe eines Bestands. Wer das Gegenteil glaubt, dimensioniert alles falsch.
• Was eine SSL-Zertifikatserneuerung zerbricht, ist fast nie ACME, sondern die Endpunkte, die kein Skript neu lädt: Appliances mit reiner Weboberfläche, Keystores mit interaktivem Passwort, verwaltete TLS-Terminierungen ohne API.
• Ein Inventar wird je Paar (Host, Port) geführt, nicht je Hostname. Auf ein und derselben IP-Adresse liefert ldap.google.com einem Standard-Client zwei verschiedene Seriennummern auf den Ports 389 und 636, und ein Scanner, der SNI vergisst, erfasst eine dritte Seriennummer, stabil und falsch.
• ACME, ARI und die sechs Phasen des Lebenszyklus werden hier vorausgesetzt: Sie werden im Leitfaden zum Zertifikatslebenszyklus-Management behandelt.

Die Erneuerung eines SSL-Zertifikats scheitert selten dort, wo man es erwartet. Der häufigste Fehlermodus ist kein gut sichtbarer Ausstellungsfehler im Log: Es ist ein certbot renew, das wochenlang grün durchläuft, während der Dienst weiterhin das alte Zertifikat präsentiert. Zwei Zeilen openssl decken das auf: die auf der Platte gelesene Seriennummer gegen die tatsächlich auf dem Port ausgelieferte. Nichts in den Logs des ACME-Clients erledigt das für Sie. Die realen Ausgaben folgen weiter unten.

Der Kontext verschärft die Mechanik. Am 21. Juli 2026 darf ein öffentliches TLS-Zertifikat 200 Tage Gültigkeit nicht überschreiten, und dieselbe Grenze gilt für die Wiederverwendung der Domain-Kontrollvalidierung. Die nächsten Stufen fallen im März 2027 und dann im März 2029, und die zweite entkoppelt Gültigkeit und Revalidierung. Das Warum dieses Zeitplans behandelt unser Artikel zur Verkürzung auf 47 Tage. Hier geht es um das Wie: was konkret zerbricht, wenn die Frequenz steigt, und was man dem entgegensetzt.

Dieses Playbook richtet sich an Teams, die zwischen 50 und 1000 Zertifikaten in einem heterogenen Bestand betreiben, ohne dediziertes PKI-Team. Sie finden hier ausgeführte Kommandos mit ihren realen Ausgaben, die zugehörigen Fallstricke und die Stellen, an denen wir nichts messen konnten, klar benannt. Kein Anbietervergleich. Ein einziges, beziffertes Kaufkriterium, und es betrifft nicht die Anzahl der Zertifikate.

Ablauf von SSL-Zertifikaten 2026: die geltende Stufe und was das für Ihre Skripte ändert

Am 21. Juli 2026 gilt die Stufe, die am 15. März 2026 in Kraft trat. Sie setzt drei Obergrenzen: 200 Tage maximale Gültigkeit, 200 Tage Wiederverwendung der Domain-Kontrollvalidierung (DCV) und 398 Tage Wiederverwendung der Subscriber-Identitätsinformationen (SII). Das ist die harte Obergrenze der Baseline Requirements des CA/Browser Forums.

In der Praxis stellen die Zertifizierungsstellen darunter aus. Der Text empfiehlt, 199 Tage nicht zu überschreiten, und verbietet erst jenseits von 200, sodass alle den operativen Puffer mitnehmen. DigiCert nimmt seit dem 24. Februar 2026 keine Anträge für öffentliche TLS-Zertifikate mit mehr als 199 Tagen Gültigkeit mehr an, rund drei Wochen vor der Frist. Sectigo folgte am 12. März 2026: 199 Tage Gültigkeit für jedes ausgestellte oder neu ausgestellte TLS-Zertifikat, 198 Tage DCV-Wiederverwendung.

Die Fortsetzung steht bereits fest. Am 15. März 2027 sinken maximale Gültigkeit und DCV-Wiederverwendung beide auf 100 Tage. Am 15. März 2029 fällt die Gültigkeit auf 47 Tage und die DCV-Wiederverwendung auf 10 Tage. Die SII bleibt über den gesamten Zeitplan bei 398 Tagen: Ihre einzige Stufe ist die vom 15. März 2026.

Vorsicht vor der verbreitetsten Verkürzung: 2029 fällt nicht die Gültigkeit auf 10 Tage, sondern die Wiederverwendung des Domain-Kontrollnachweises. Die beiden Zähler trennen sich, und genau dort ändert sich alles für Ihre Skripte. Heute deckt eine erfolgreiche Validierung mehrere aufeinanderfolgende Erneuerungen ab. 2029 schleppt jede Neuausstellung eine vollständige Revalidierung hinter sich her, weil der vorherige Nachweis längst abgelaufen sein wird. Die Ausstellung zu automatisieren, wird nicht mehr genügen. Auch die Validierung muss dauerhaft automatisiert sein, also müssen DNS-Schreibrechte oder der Zugang zu Port 80 durchgehend verfügbar sein, und nicht nur an dem Tag, an dem ein Mensch eine Änderung einplant.

Einen Zertifikatsbestand inventarisieren: vier Quellen, vier blinde Flecken

Keine Inventarquelle sieht den gesamten Bestand. Die Transparenz-Logs listen, was öffentlich ausgestellt wurde, Platte und Zertifikatspeicher listen, was installiert ist, der Netzwerk-Scan liest, was ausgeliefert wird, und die Anbieter-APIs decken ab, was die anderen drei nicht sehen. Man muss sie kreuzen und vor allem wissen, was jede übersieht.

Transparenz-Logs zeigen, was ausgestellt wurde, nicht was läuft

Die Certificate-Transparency-Logs erfassen jedes Zertifikat, das eine öffentliche Zertifizierungsstelle für Ihre Domains ausgestellt hat. Sie sagen weder, wo es ausgerollt ist, noch ob es noch im Einsatz ist. Die naive Abfrage passt in eine Zeile:

curl -s 'https://crt.sh/?q=%25.captaindns.com&output=json' | jq -r '.[].name_value' | sort -u

Auf unserer Domain lieferte sie 12 eindeutige Werte in 54 Sekunden. Ein vorheriger Lauf hatte drei aufeinanderfolgende HTTP 502 zurückgegeben, bevor er beim vierten Versuch durchlief. Am Kommando ist nichts kaputt: crt.sh antwortet eben so.

Was folgt, ist bei der Ausführung aufgetreten, nicht hergeleitet. Das -s verdeckt den Fehler: jq bekommt HTML und meldet jq: parse error: Invalid numeric literal at line 1, column 7, und ohne set -o pipefail läuft das Skript weiter, als wäre nichts gewesen. Die 54 Sekunden sind eine nominale Antwortzeit für 142 Zertifikate, keine Ratenbegrenzung. Das %25 kodiert den Platzhalter %, der die Subdomains abdeckt, nicht aber den Apex. Das Feld name_value enthält Zeilenumbrüche, wenn das Zertifikat mehrere SAN trägt: 142 JSON-Objekte ergaben 158 Zeilen für 12 eindeutige Werte, weshalb das sort -u Pflicht ist. Und schließlich sind abgelaufene Zertifikate standardmäßig enthalten: 76 der 142 Einträge.

Die gehärtete Fassung korrigiert das alles:

curl -sS --fail --retry 8 --retry-all-errors --retry-delay 5 --max-time 180 \
  -o crt.json 'https://crt.sh/?q=%25.captaindns.com&output=json&exclude=expired' \
&& jq -r '.[].name_value' crt.json | sed 's/^\*\.//' | tr 'A-Z' 'a-z' | sort -u

Reale Ausgabe: Code 0 in 41,9 Sekunden inklusive Wiederholversuchen, 66 Einträge gegenüber 142 ohne den serverseitigen Filter, und 11 Namen. Zwei Varianten wurden getestet und verworfen, und gerade sie sind am lehrreichsten. Ohne -o, also mit Ausgabe auf stdout, verkettet curl den Body des 502 mit dem des erfolgreichen 200: 8342 Bytes, die mit <html><head><title>502 Bad Gateway</title> beginnen, gefolgt von gültigem JSON, und jq scheitert. Mit -o spult curl die Datei bei jedem Versuch zurück. Und --fail --retry 8 ohne --retry-all-errors wiederholt nicht: curl 8.7.1 meldet curl: (56), ein Code, der nicht in der Liste der Fehler steht, die curl standardmäßig wiederholt. Fehlschlag in 0,12 Sekunden.

Bleibt der strukturelle blinde Fleck: Die Transparenz sieht nur die öffentliche PKI. Ihre internen Zertifikate tauchen dort nicht auf.

Platte und Zertifikatspeicher zeigen, was installiert ist, nicht was ausgeliefert wird

Eine PEM-Datei, einen Java-Keystore oder den Windows-Computerspeicher zu lesen, sagt etwas darüber aus, was auf der Maschine liegt. Nicht darüber, was der Dienst dem Netz präsentiert.

Auf PEM-Seite genügt openssl x509 -in fullchain.pem -noout -subject -dates -serial. Für die beiden anderen zuerst die Ehrlichkeit: Wir konnten die entsprechenden Kommandos nicht ausführen. Unser Testrechner hat kein JDK und läuft nicht unter Windows. Statt einer erfundenen Ausgabe hier die Spur des Versuchs:

$ keytool -list -v -keystore /Library/Keychains/System.keychain
The operation couldn't be completed. Unable to locate a Java Runtime.

$ file /usr/bin/keytool
/usr/bin/keytool: Mach-O universal binary with 2 architectures

$ pwsh -NoProfile -Command 'Get-ChildItem Cert:\LocalMachine\My'
Get-ChildItem: Cannot find drive. A drive with the name 'Cert' does not exist.

Diese beiden Fehlschläge zerlegen jeweils einen Fehlalarm scheinbarer Verfügbarkeit. Die Maschine stellt zwar eine Binärdatei /usr/bin/keytool bereit, aber das ist ein Apple-Platzhalter, der auf die Java-Website weiterleitet: Ein antwortendes which keytool beweist unter macOS nichts. Und PowerShell 7 unter macOS oder Linux zu installieren, gibt keinerlei Zugriff auf den Zertifikatspeicher, denn der Provider Certificate ist ein Windows-Baustein und fehlt in der Liste der PSProvider. Dieses Skript lässt sich nur auf seinem Zielsystem validieren.

Die Fallstricke zählen genauso viel wie die Kommandos. keytool fragt sein Passwort interaktiv ab, und es über -storepass zu übergeben, macht es in der History und in ps sichtbar: besser -storepass:file. Seit JDK 9 ist das Standardformat PKCS12, nicht JKS. Auf Windows-Seite verlangt LocalMachine\My eine als Administrator geöffnete Konsole, andernfalls kommt die Liste ohne Fehlermeldung unvollständig zurück, und ein IIS-Binding kann auf einen anderen Fingerprint zeigen als das, was installiert ist.

Der Netzwerk-Scan wird Ihre Mailserver nie sehen

Ein Netzwerk-Scan liest, was tatsächlich ausgeliefert wird, was ihn zur zuverlässigsten Quelle macht. Von einem gewöhnlichen Arbeitsplatz oder aus den meisten Clouds heraus wird er Ihre Mailserver aber nie sehen: Der ausgehende Port 25 ist dort gefiltert.

Der Beweis passt in drei Zeilen, auf einem einzigen Host. smtp.gmail.com löste zum Testzeitpunkt auf eine einzige Adresse auf, und die Google-Frontends rotieren: Welche Adresse die Auflösung auch liefert, die drei Ports zeigen denselben Kontrast. Port 587 mit STARTTLS und Port 465 mit implizitem TLS nehmen die Verbindung an und liefern das Zertifikat; auf Port 25 läuft die Verbindung in einen Timeout. Die Maschine ist erreichbar, der Port ist blockiert. Auf sieben öffentliche MX von sechs verschiedenen Betreibern wiederholt, zwei bei Google, dann Proton, OVH, Riseup, Yandex und GMX, läuft dasselbe Kommando sieben von sieben Mal in den Timeout.

Port 25 ist bei uns gefiltert, ausgehend. Die Nuance zählt, weil der umgekehrte Schluss überall herumgeistert. Google schließt gar nichts. AWS, GCP, Azure und OVH blockieren den ausgehenden Port 25 standardmäßig, ebenso wie nahezu alle Privatanschlüsse. Ein Bestands-Scan von einer solchen Maschine aus liefert also zwangsläufig ein unvollständiges Ergebnis.

Dasselbe Symptom deckt allerdings zwei verschiedene Ursachen ab, und die zweite kommt nicht aus Ihrem Netz. Vom selben Rechner aus läuft pop.gmail.com auf Port 110 in den Timeout, während pop.gmx.net dort antwortet, und imap.gmx.net antwortet auf 143 mit validiertem STARTTLS, genau wie auf 993; 995 geht überall. Die Klartext-Ports sind also ausgehend nicht gefiltert, anders als 25: Es sind die Google-Hosts, die diese Pakete ohne Antwort verwerfen, weil sie weder POP3 noch IMAP im Klartext anbieten. Anbieterpolitik auf der einen Seite, Netzwerkfilterung auf der anderen: zwei Ursachen für "nicht erreichbar", ein einziges Symptom. Bevor Sie schließen, ein Port sei gefiltert, testen Sie einen zweiten Betreiber.

Ein Inventar-Scanner muss also drei Zustände unterscheiden, nicht zwei: Zertifikat gelesen, Zertifikat fehlerhaft und Host nicht erreicht. Ein als "nichts zu melden" gezähltes "nicht erreichbar" ist das schlechtestmögliche Ergebnis, weil das Dashboard bei Diensten grün bleibt, die nie gemessen wurden. Und bei MX ist das keine Theorie: Wenn sich das Zertifikat ändert, bevor der zugehörige TLSA-Eintrag veröffentlicht ist, verbietet RFC 7672 die Zustellung über diesen Server und zwingt den Absender, auf den nächsten MX auszuweichen oder die Zustellung aufzuschieben.

Unsere eigenen Tools unterliegen derselben Grenze: Der Uptime-Monitor von CaptainDNS akzeptiert nur die Schemata HTTP und HTTPS. SMTP, IMAPS und LDAPS liegen außerhalb seines Umfangs.

Anbieter-APIs sehen, was die drei anderen Quellen schlecht zuordnen

Bleibt die vierte Quelle, die unspektakulärste: die Anbieter-APIs. AWS Certificate Manager, Cloudflare oder ein CDN, das TLS für Sie terminiert, halten Zertifikate, die nichts anderes korrekt Ihrem Bestand zuordnet. Die Transparenz-Logs sehen sie, ohne zu sagen, wer sie betreibt, die Platte enthält sie nicht, und der Netzwerk-Scan schreibt sie der Infrastruktur des Anbieters zu statt Ihrem Dienst. Die API ist der einzige Ort, an dem diese verwalteten Terminierungen mit Ablaufdatum und Erneuerungsmodus existieren.

Ihr blinder Fleck ist symmetrisch: Jede API deckt nur ab, was bei diesem Anbieter lebt, und setzt Leserechte voraus, die das inventarisierende Team nicht immer hat. Drei Anbieter bedeuten drei Abfragen, drei Anmeldedatensätze und drei abzugleichende Antwortformate.

Ein Inventar wird auf ein Paar (Host, Port) indexiert, nicht auf einen Namen

Gleicher Name, gleiche IP-Adresse, zwei Zertifikate. ldap.google.com löst auf eine einzige IPv4-Adresse auf, 216.239.32.58. Ein Standard-Client liest dort die Seriennummer 84D4296C auf Port 389 mit STARTTLS und E97CCECB auf Port 636 mit implizitem TLS. Drei identische Läufe, dreimal dasselbe Ergebnis.

Erster Fallstrick: SNI. Ohne SNI liefern beide Ports Googles Sentinel, CN=invalid2.invalid mit OU=No SNI provided - please fix your client., Nummer B3E9BADC: Ein Scanner ohne SNI erfasst einen vollkommen stabilen und vollkommen falschen Wert, und das weiterhin ohne Fehler.

Der Port selbst ist allerdings nicht die Ursache des Unterschieds zwischen 389 und 636. Der Listener auf 389 hält beide Zertifikate und entscheidet anhand der Signaturalgorithmen, die der Client ankündigt:

openssl s_client -starttls ldap -connect ldap.google.com:389 -servername ldap.google.com \
  -sigalgs 'RSA-PSS+SHA256:rsa_pkcs1_sha256' </dev/null 2>/dev/null | openssl x509 -noout -serial

serial=E97CCECBFFF70F940963C3B2C1F06634

Port 389 liefert also auf Anfrage das Zertifikat, das man für 636-spezifisch hielt. Umgekehrt schlägt es fehl: ECDSA+SHA256 auf 636 erzwungen löst einen tls alert handshake failure aus (Alert 40), ganz ohne Zertifikat. Port 636 hat nur RSA, und das rettet die Indexierung nach Paar (Host, Port). Aber die TLS-Konfiguration des Scanners ist eine Eingangsvariable wie der Port auch: Zwei Scanner mit unterschiedlichen Signaturalgorithmen inventarisieren zwei verschiedene Seriennummern auf demselben Paar, ohne dass irgendein Fehler auftaucht. Frieren Sie die TLS-Konfiguration des Scanners ein und dokumentieren Sie sie, sonst ist das Inventar von Lauf zu Lauf nicht reproduzierbar.

Anderswo dreht sich das Verhalten um: Bei Gmail liefern die Ports 465 und 587 dasselbe Zertifikat, 6D09D839.... Nichts davon lässt sich erraten, und ein auf den Hostnamen indexiertes Inventar zählt in beide Richtungen falsch: Es verschmilzt verschiedene Zertifikate oder dupliziert dasselbe.

Das Audit-Raster zum Download am Artikelende übernimmt genau diese Spalten: eine Zeile je Paar (Host, Port), den TLS-Modus, den Status des letzten Scans mit seinen drei möglichen Werten, die Ablagemethode, die Reload-Methode, den namentlich benannten Eigentümer und die Automatisierungsklasse. Drei Beispielzeilen zeigen die erwartete Befüllung, der Rest ist leer.

_acme-challenge delegieren, ohne die Schlüssel zur Zone herzugeben

_acme-challenge per CNAME zu delegieren, gibt dem ACME-Client Schreibrecht auf eine dedizierte Validierungszone, und sonst nichts. Ihre Produktionszone bleibt unangetastet: dieselben Einträge, dieselbe geschlossene API.

Was die CNAME-Delegation ist und was sie nicht ist

RFC 8555 erwähnt CNAME nicht. Das Wort taucht nirgends im Text auf, nachgeprüft. Die Delegation ist also keine Empfehlung des ACME-Standards: Sie ist von Let's Encrypt dokumentiert und unterstützt, deren DNS-01-Validierung den gewöhnlichen DNS-Regeln folgt und akzeptiert, dass ein CNAME oder eine NS-Delegation die Antwort auf die Challenge in eine andere Zone verweist. Regulatorisch nennen die Baseline Requirements den CNAME-Eintrag ausdrücklich unter den gültigen Trägern der Validierungsmethode "DNS Change", in Abschnitt 3.2.2.4.7.

Die Unterscheidung passt in eine Zeile: vom Ökosystem unterstützt, im Standard nicht vorhanden.

Der Nutzen ist dafür eindeutig. Der ACME-Client erhält Anmeldedaten, die nur in einer Validierungszone schreiben, die oft anderswo gehostet wird. Die Kompromittierung des erneuernden Servers gibt dann keinerlei Macht über Ihre produktiven MX-, A- oder TXT-Einträge. Beim Durchsehen von 32 öffentlichen Domains fanden wir mehrere reale Delegationen dieser Art: fastmail.com verweist auf fastmail.com.acme-challenge.fmhosted.com, github.com auf github.com.acme.github.net, reddit.com auf ein Ziel unter dcv.cloudflare.com, eff.org und digitalocean.com auf fastly-validations.com.

Eine Delegation prüfen: drei Schritte, nie nur einer

Eine einzelne Abfrage beweist nichts. Die vollständige Prüfung verlangt drei, und der dritte ist der, der aus einem Verdacht einen Beweis macht.

Schritt 1, der CNAME existiert:

dig +noall +answer _acme-challenge.fastmail.com CNAME

_acme-challenge.fastmail.com. 3600 IN CNAME fastmail.com.acme-challenge.fmhosted.com.

Mehr sagt dieses Kommando nicht: Ein CNAME ist eingetragen. Es beweist nicht, dass die Delegation funktioniert.

Schritt 2, der Kette bis zum TXT folgen und den Status lesen:

dig +noall +answer +comments _acme-challenge.fastmail.com TXT

Drei reale Fälle, und hier irren sich die meisten Artikel:

FALL A - fastmail (CNAME vorhanden, Ziel ohne aktiven TXT)
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59352
_acme-challenge.fastmail.com. 3600 IN CNAME fastmail.com.acme-challenge.fmhosted.com.

FALL B - reddit (CNAME vorhanden, Ziel existiert)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8461
_acme-challenge.reddit.com. 292 IN CNAME reddit.com.7ee8918f112aca0f.dcv.cloudflare.com.

FALL C - captaindns.com (keine Delegation)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27534
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Man muss zwei Signale kreuzen, nie nur eines. Ein CNAME im ANSWER-Abschnitt zusammen mit einem NXDOMAIN bedeutet, dass die Delegation eingetragen ist, das Ziel aber in diesem Moment nicht existiert, weil der TXT erst zum Zeitpunkt der Challenge angelegt wird. Das ist der normale Zustand zwischen zwei Erneuerungen: Von den sieben öffentlichen Delegationen, die wir abgefragt haben, waren sechs in diesem Zustand. Der echte Fehler ist ein NOERROR mit ANSWER: 0, also überhaupt keine Delegation. Ein Monitoring, das auf den NXDOMAIN von _acme-challenge alarmiert, erzeugt Dauerrauschen und irrt sich in sechs von sieben Fällen.

Schritt 3, auf autoritativer Ebene prüfen und bestätigen, dass die Zielzone lebt:

ns=$(dig +short NS fastmail.com | head -1)
dig +noall +answer +comments @"$ns" _acme-challenge.fastmail.com CNAME
dig +noall +answer +comments acme.github.net SOA

Der SOA von acme.github.net antwortet mit NOERROR, während die TXT-Abfrage auf _acme-challenge.github.com NXDOMAIN lieferte: Die Delegation ist gesund, es fehlt lediglich die Challenge-Antwort, weil keine Erneuerung läuft. Ein SOA mit NXDOMAIN oder SERVFAIL auf der Zielzone signalisiert umgekehrt eine endgültig kaputte Delegation, typischerweise ein gelöschtes Validierungskonto oder eine abgelaufene Domain.

Der Name beginnt mit einem Unterstrich, den manche Verwaltungsoberflächen verschlucken oder doppelt voranstellen: Prüfen Sie den in der DNS-Antwort zurückgegebenen FQDN, nicht die Anzeige im Panel; eine CNAME-Abfrage im DNS-Lookup-Tool zeigt das, ohne ein Terminal zu öffnen. Ein CNAME auf _acme-challenge verträgt sich mit keinem anderen Eintrag desselben Namens, sodass ein übrig gebliebener alter Validierungs-TXT die Zone ungültig macht. Die beobachteten TTL reichen je nach Domain von 3600 bis 120 Sekunden: Nach einer Korrektur kann ein Resolver die alte Antwort inklusive NXDOMAIN für diese gesamte Dauer weiter ausliefern, und das ist die Ursache Nummer eins für Validierungsfehler direkt nach einer Änderung. Das head -1 testet nur einen einzigen autoritativen Server. Und schließlich beweist die Abfrage der Zielzone nicht, dass der Client dort Schreibrechte hat: Das beweist nur eine echte Ausstellung.

Die Grenze eines einzigen Delegationsziels pro Domain, und der Draft, der sie aufhebt

DNS erlaubt nur einen CNAME pro Name. _acme-challenge.captaindns.com kann also immer nur an einen Client zugleich delegiert werden. Multi-CDN, Multi-Region, Migration ohne Ausfall, Ersatzzertifikat von einer zweiten Zertifizierungsstelle: Diese vier Anforderungen laufen alle gegen dieselbe Wand, und eine saubere Umgehung auf DNS-Seite gibt es nicht.

Ein laufender Draft der IETF greift das Problem auf. Der draft-ietf-acme-dns-account-label-03, Active Internet-Draft der ACME-Arbeitsgruppe, Revision 03 vom 15. Mai 2026, zum Zeitpunkt unserer Prüfung im Working Group Last Call, definiert eine Challenge namens dns-account-01. Das Prinzip: dem Validierungsnamen einen Hash der ACME-Konto-URL voranstellen, nach der Konstruktion "_" || base32(SHA-256(ACCOUNT_URL)[0:10]) || "._acme-challenge". Jedes Konto erhält so seinen eigenen Validierungsnamen, und mehrere Clients können parallel auf derselben Domain validieren.

Das ist ein Draft, keine Norm. Er hat keine RFC-Nummer, sein Inhalt kann sich mit der nächsten Revision ändern, und wir kündigen keinerlei Verfügbarkeit bei einer Zertifizierungsstelle an. Beobachtenswert, wenn Ihre Architektur mehrere Anbieter nutzt, aber nichts für einen Rollout-Plan.

Die Erneuerung eines SSL-Zertifikats endet nicht bei der Ausstellung: Der Reload ist das echte schwache Glied

certbot renew schreibt das neue Zertifikat auf die Platte. Es lädt weder nginx noch postfix noch haproxy neu. Zwischen dem Moment, in dem die Ausstellung gelingt, und dem, in dem der Dienst das neue Zertifikat präsentiert, liegt ein Reload, und dort bricht die Kette am häufigsten, ohne dass irgendein Log angeht. Die Gegenmaßnahme auf Client-Seite heißt Deploy-Hook, und der Leitfaden zum Zertifikatslebenszyklus-Management widmet ihm seine Phase 3; die folgende Kontrolle prüft von außen, ob er wirklich funktioniert hat.

Die Kontrolle nach der Erneuerung und ihre fünf Fehlalarme

Die einzige Kontrolle, die zählt, vergleicht die auf der Platte gelesene Seriennummer mit der tatsächlich im Netz ausgelieferten:

HOST=api.captaindns.com
FILE=/etc/letsencrypt/live/$HOST/fullchain.pem

disk=$(openssl x509 -in "$FILE" -noout -serial | cut -d= -f2)
served=$(openssl s_client -connect "$HOST:443" -servername "$HOST" </dev/null 2>/dev/null \
         | openssl x509 -noout -serial | cut -d= -f2)

echo "Platte=$disk"
echo "Netz  =$served"
[ "$disk" = "$served" ] \
  && echo "OK: Das ausgelieferte Zertifikat ist das von der Platte" \
  || echo "ALARM: Der Dienst liefert ein ALTES Zertifikat -> Reload erforderlich"

Beide Zweige wurden tatsächlich ausgeführt, mit zwei verschiedenen Seriennummern:

FALL 1 - Übereinstimmung
Platte=05DFD8366DC6A73780F3707BC7E13F91E0EC
Netz  =05DFD8366DC6A73780F3707BC7E13F91E0EC
OK: Das ausgelieferte Zertifikat ist das von der Platte

FALL 2 - Abweichung
Platte=05DFD8366DC6A73780F3707BC7E13F91E0EC
Netz  =05B499411D7820A6C0EC7A0626E1BA25CF67
ALARM: Der Dienst liefert ein ALTES Zertifikat -> Reload erforderlich

Diese Kontrolle hat ihre Fallstricke, und der erste ist banal. Das cut -d= -f2 ist kein Zierrat: openssl gibt serial=05DF... aus, und ohne diesen Schnitt schlägt der Vergleich fehl. Vergleichen Sie die Seriennummer, nie das Ablaufdatum: Zwei am selben Tag erneuerte Zertifikate können dasselbe notAfter haben. Die Datei fullchain.pem enthält mehrere Zertifikate, und openssl x509 -in liest nur das erste, sodass eine falsch sortierte Datei dazu führt, dass das Zwischenzertifikat verglichen wird und der Test dauerhaft fehlschlägt. Hinter einem Load Balancer, der TLS terminiert, hat das auf der Platte des Origins liegende Zertifikat nichts mit dem zu tun, was öffentlich ausgeliefert wird: Die Kontrolle wird zum dauerhaften Fehlalarm, und man muss sie von außerhalb des Load Balancers ansetzen. Und schließlich: Um die Datei statt der Ausstellung zu identifizieren, ersetzen Sie -serial durch -fingerprint -sha256.

Diese Kontrolle ist keineswegs auf 443 beschränkt. Wir haben sie außerhalb des Webs wiederholt: mit implizitem TLS auf Port 465, dann mit STARTTLS auf Port 587, mit derselben Seriennummer 6D09D839... auf beiden Seiten. Ein Mailbestand wird genauso kontrolliert, bis auf die Verbindungsoption.

Der SPKI-SHA-256-Fingerprint bietet eine ergänzende Kontrolle, weiter vorne in der Kette. Er wird sowohl von unserem SSL Certificate Checker als auch vom CSR Parser ausgegeben, genug, um zu belegen, dass ein bestimmter CSR das ausgelieferte Zertifikat erzeugt hat. Der Abgleich ist manuell: Nichts erledigt ihn automatisch für Sie.

Liefern alle Ihre Frontends dasselbe Zertifikat?

Eine Schleife über die IP-Adressen des Dienstes beantwortet die Frage in wenigen Sekunden:

HOST=debian.org
for ip in $(dig +short A "$HOST" | grep -E '^[0-9]'); do
  printf '%-16s ' "$ip"
  openssl s_client -connect "$ip:443" -servername "$HOST" </dev/null 2>/dev/null \
    | openssl x509 -noout -serial | cut -d= -f2
done

Bei debian.org lieferten alle vier zurückgegebenen Adressen dieselbe Seriennummer, 057EB3AB.... Homogener Bestand an dieser Stelle. Der Kern des Kniffs steckt im -servername, das gesetzt wird, obwohl man sich mit einer IP verbindet: Ohne es bekommt man das Standardzertifikat des Frontends, nicht das des gewünschten vHosts. Das grep -E '^[0-9]' filtert die CNAME-Zeilen heraus, die dig +short dazwischenschiebt, ein Verhalten, das wir bei www.google.com wegen einer Umschreibung durch den lokalen Resolver beobachtet haben.

Die Schleife deckt nur IPv4 ab: Ergänzen Sie einen Durchlauf über dig +short AAAA mit -connect "[$ip]:443". Die andere Grenze ist heimtückischer. Hinter einem Anycast (dieselbe Adresse, von mehreren Punkten der Welt angekündigt) gehören diese vier Adressen zu demselben Point of Presence, so wie er von Ihrem Rechner aus gesehen wird: Sie testen ihn viermal, nicht die N anderen, die weltweit verteilt sind.

Einen falsch erkannten Port an einer Fehlerzeile diagnostizieren

Man muss den Modus eines Ports nicht raten: openssl sagt es in seiner Fehlermeldung. Ein wrong version number bedeutet, dass -starttls fehlt: Der Server erwartet vor der Aushandlung einen Dialog im Klartext. Umgekehrt bedeutet ein Didn't find STARTTLS in server response, trying anyway... gefolgt von einem unexpected eof while reading, dass -starttls überflüssig ist, auf einem bereits verschlüsselten Port: openssl versucht es trotzdem, wartet auf ein Klartext-Banner von einem Server, der nur TLS erwartet, und die Verbindung stirbt an einem EOF.

Das entsprechende Kommando für einen MX auf Port 25 sieht so aus:

openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 \
  -servername gmail-smtp-in.l.google.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -serial

Von unserem Rechner aus nicht validiert, ausgehender Port 25 gefiltert; identische Syntax auf 587 validiert. Wir veröffentlichen dafür also keine Ausgabe. Drei Fallstricke sind trotzdem erwähnenswert: Das 2>/dev/null schluckt den echten Fehler und lässt Sie mit einem Could not find certificate from <stdin> zurück, egal worin das Problem besteht, das </dev/null verhindert, dass die Sitzung offen bleibt, und das -servername muss den Namen des MX tragen, nicht den der Maildomain.

DANE und TLSA: der einzige Fall, in dem die Reihenfolge normativ ist

Der Reload hat eine letzte Etage, reserviert für MX, die TLSA-Einträge veröffentlichen. Dort hört die Reihenfolge der Schritte auf, eine Best Practice zu sein, und wird zur Pflicht. RFC 7671, Abschnitt 8.1, beschreibt die Rotation in vier Zügen: den TLSA-Eintrag des künftigen Zertifikats neben dem des aktuellen Zertifikats veröffentlichen, mindestens zwei TTL warten, bis die Caches geleert sind, dann das neue Zertifikat ausrollen und prüfen, dass es funktioniert, und schließlich den obsolet gewordenen Eintrag entfernen. Zwei TTL, nicht 48 Stunden: Die RFC rechnet in TTL, und Ihre TTL sind nicht unsere.

Für SMTP macht RFC 7672 daraus eine formale Pflicht. Bei einer Desynchronisation ist die Zustellung über diesen Server verboten, und der Absender weicht auf den nächsten MX aus oder schiebt die Zustellung auf.

Der Fehlermodus ist asymmetrisch, und genau das macht ihn gefährlich. Auf Seiten des fehlerhaften Betreibers gibt es keinerlei Alarm: Die Verbindung wird vom Client abgebrochen, Absender, die DANE nicht validieren, stellen weiter zu, das Monitoring bleibt grün. RFC 7672 verwendet das Wort "unwittingly", um diese Partnerdomain zu beschreiben, die ohne ihr Wissen falsch konfiguriert ist. Auf Seiten des validierenden Absenders ist es nicht still, aber verzögert: Die Nachrichten stauen sich in der Warteschlange, mit Verzögerungsmeldungen und schließlich möglichen Bounces bei Ablauf. Der eigentliche Empfänger bekommt weder die Nachricht noch irgendeine Benachrichtigung.

Bleibt eine Bedingung, die Abschnitt 8.1 stellt, ohne sie hervorzuheben: Usage, Selector und Matching Type müssen unverändert bleiben. Wenn Sie einen dieser drei Parameter ändern, gilt Abschnitt 8.3, und die Regel kehrt sich um.

Die Fälle, die sich ACME widersetzen: was sich nicht automatisieren lässt

Ein Teil des Bestands sperrt sich, und das nicht aus Protokollgründen. ACME kann für fast alles ausstellen. Was klemmt, ist die Installation, der Reload oder die geforderte Validierungsstufe.

Die interne PKI und die Zwei-Jahres-Zertifikate

Interne Zertifizierungsstellen entziehen sich dem Zeitplan des CA/Browser Forums, also drängt sie nichts zu kürzeren Laufzeiten oder zur Automatisierung. Die öffentliche Demo-Instanz von FreeIPA zeigt das deutlich: Bei der Erhebung am 21. Juli 2026 lieferte ipa.demo1.freeipa.org ein Zertifikat mit Gültigkeit vom 23. April 2025 bis zum 24. April 2027, also zwei Jahre, an einer von einer privaten Root signierten Kette.

Von einem externen Rechner aus gesehen gibt openssl verify error:num=19 self-signed certificate in certificate chain zurück. Dieser Code wird oft mit einem anderen verwechselt: verify error:num=20 unable to get local issuer certificate. Sie beschreiben nicht dieselbe Situation. Die 19 bedeutet, dass der Server seine private Root sehr wohl in der Kette mitschickt, sie aber in Ihrem lokalen Speicher fehlt. Die 20 bedeutet, dass das Zwischenzertifikat gar nicht mitgeschickt wird und openssl die Kette nicht aufbauen kann. In beiden Fällen ist die Diagnose dieselbe: ein Problem des Trust Stores, kein Problem des Zertifikats. Die Korrektur ebenfalls: -CAfile internal-ca.pem.

Es gibt Brücken, um solche Bestände zu ACME zurückzuholen. Keine davon lässt sich ohne Gegenleistung ausrollen, und man kennt sie besser vorher.

• acme2certifier, unter GPLv3-Lizenz, setzt eine ACME-Fassade vor Microsoft ADCS über MS-WCCE oder die Certificate Enrollment Web Services. Widerruf wird nicht unterstützt, und die Kette der Zertifizierungsstelle muss von Hand geladen werden. Es ist ein Community-Projekt, getragen von einem Maintainer, aktiv: Version 0.44 am 18. Juli 2026.
• step-ca ist in seiner Standardkonfiguration ein Single Point of Failure, wegen der eingebetteten Badger-Datenbank, die keine Nebenläufigkeit beherrscht. Die Dokumentation beschreibt ein Multi-Instanz-Deployment, um den Preis einer externen MySQL- oder PostgreSQL-Datenbank und der entfernten Verwaltung der Provisioner.
• HashiCorp Vault stellt seit Version 1.14.0 einen ACME-Server bereit, mit einer auf 90 Tage gedeckelten Lebensdauer. Das ist ein Server, kein Client, und diese Nuance ändert in einer Architektur alles.
• EJBCA Community Edition: Keyfactor schreibt es selbst in die README des offiziellen Repositorys, "EJBCA Community Edition is not intended for production use."

Die Zertifikate, die ACME nicht ausstellen kann

Die Extended-Validation-Stufe lässt sich nicht über ACME erlangen. Sie setzt eine juristische Identitätsprüfung voraus (Geschäftskategorie, Registrierungsgerichtsstand, Handelsregisternummer), die keine automatisierte Challenge erzeugt.

Der Fall begegnet einem in Produktion. Bei derselben Erhebung lieferte posteo.de auf Port 465 ein Extended-Validation-Zertifikat mit Gültigkeit vom 18. Februar 2026 bis zum 24. Februar 2027, also 371 Tage. Und trotzdem kein Verstoß gegen die 200-Tage-Obergrenze. Das Zertifikat wurde vor dem 15. März 2026 ausgestellt, und die Regel wirkt nicht rückwirkend. Wir ziehen daraus keinerlei Schluss über die Erneuerungspraxis dieses Betreibers.

Das Feld wird noch enger. Die Markenzertifikate VMC und CMC, die von BIMI genutzt werden, lassen sich mit unserem dedizierten Analysewerkzeug dekodieren, sind aber keine TLS-Serverzertifikate. Client-Zertifikate, insbesondere solche mit gegenseitiger Authentifizierung, folgen ihrerseits einer Ausstellungskette und einer Verteilung, die mit ACME nichts zu tun haben.

Die Endpunkte, die kein Skript neu lädt

Hier liegt die eigentliche Obergrenze der Automatisierung, und die einzige Zahl, die für eine Kaufentscheidung zählt. Gehen Sie Ihren Bestand durch und zählen Sie das Folgende.

Netzwerk-Appliances, die sich nur über eine Weboberfläche verwalten lassen. Hardware-Load-Balancer, deren Zertifikatsaktualisierung über ein Formular läuft. Drucker, Industrieanlagen, Kameras und alles, was einen seit der Installation vergessenen HTTPS-Server mitbringt. Java-Keystores mit interaktivem Passwortschutz, die jede unbeaufsichtigte Ausführung sofort blockieren. Windows-Zertifikatspeicher, bei denen die Installation eines Zertifikats nicht genügt, weil ein IIS-Binding weiterhin auf einen anderen Fingerprint zeigen kann. Verwaltete TLS-Terminierungen bei einem Anbieter, der keine API bereitstellt.

Die Gemeinsamkeit ist nicht die Ausstellung: ACME kann für all diese Namen ausstellen. Manuell bleiben Installation und Reload. Ein Skript kann das Zertifikat in Sekunden beschaffen und dann darauf warten, dass ein Mensch sich an einer Oberfläche anmeldet, um es abzulegen. Bei 200 Tagen Gültigkeit greift dieser Mensch zweimal im Jahr ein, und niemand beschwert sich. Bei 47 Tagen greift er mindestens achtmal pro Jahr und pro Endpunkt ein, wenn zum Ablauf erneuert wird, und elf- bis zwölfmal bei der empfohlenen Erneuerung nach zwei Dritteln. Die Kosten werden zu einer Budgetposition.

Messen Sie das jetzt, solange die Frequenz noch niedrig ist: Anzahl der betroffenen Endpunkte, tatsächlich pro Rotation aufgewendete Minuten, namentlich benannter Eigentümer. Diese drei Spalten sind mehr wert als alle Tool-Vergleiche.

Taktung, Kurzzeitprofile und was eine Erneuerungsschleife wirklich begrenzt

Eine Erneuerungsschleife wird nicht durch die Größe des Bestands begrenzt. Sie wird durch die Taktung begrenzt, mit der jeder Name neu ausgestellt wird, und durch zwei, drei Rate Limits, die alles andere als intuitiv sind.

Wann erneuern: Die Zwei-Drittel-Regel hat eine Ausnahme

Die allgemeine Regel ist einfach: erneuern, wenn noch ein Drittel der Gesamtlaufzeit übrig ist. Also 30 Tage vor Ablauf bei einem 90-Tage-Zertifikat. Die Dokumentation von Let's Encrypt sieht aber eine ausdrückliche Ausnahme für Zertifikate mit weniger als zehn Tagen Gültigkeit vor: Für diese wird die Erneuerung zur Halbzeit empfohlen.

Das Profil shortlived fällt genau in diese Ausnahme. Es umfasst 160 Stunden, also 6,67 Tage. Seine Halbzeit liegt damit bei 80 Stunden, was 2,1 Ausstellungen pro Woche und pro Name ergibt.

Diese 2,1 sind ein Modell, kein von Let's Encrypt veröffentlichter Wert. Seine fünf Annahmen, offen gelegt. Die Gültigkeit von 160 Stunden ist dokumentiert. Die auf feste 168 Stunden gebrachte Woche ist eine Näherung: Der reale Mechanismus ist ein Token Bucket mit kontinuierlichem Nachfüllen. Die Erneuerung zu einem festen, deterministischen Bruchteil, ohne Jitter und ohne Wiederholversuche, ist eine Modellannahme. Ein Zertifikat gleich ein Name, während shortlived bis zu 25 Namen akzeptiert: Bündeln senkt die Anzahl der Zertifikate entsprechend. Und die Rechnung setzt null Fehlschläge voraus.

Der wichtigste Vorbehalt: Mit ARI, dem Normalbetrieb, folgt die Taktung keinem festen Bruchteil, sondern dem vom Server vorgeschlagenen Fenster, dessen Lage und Breite nicht veröffentlicht sind. Jede Taktung als Bruchteil der Lebensdauer beschreibt also ein Sicherheitsnetz, nicht den Normalbetrieb.

Und die kursierenden "rund dreißig Namen pro Domain im Kurzzeitprofil" teilen ein Kontingent, das Erneuerungen gar nicht verbrauchen, durch eine Taktung, die für dieses Profil nicht gilt: Wir übernehmen diese Zahl nicht.

Was Let's Encrypt eine Erneuerung nennt

Zwei Mechanismen, zwei Ausnahmeregime. Sie zu verwechseln ist der Fehler, der im Betrieb am teuersten wird.

Über ARI benennt das Kommando newOrder ausdrücklich das Zertifikat, das es ersetzt. Tatsächlich drei Bedingungen: diese Benennung, mindestens ein gemeinsamer Identifier mit dem ausscheidenden Zertifikat, und ein ausscheidendes Zertifikat, das nicht bereits einmal ersetzt wurde. Die Ausnahme ist dann vollständig. Alle Rate Limits entfallen, ohne Ausnahme, und der SAN-Umfang darf sogar wechseln, da die Identität des ausscheidenden Zertifikats im dafür vorgesehenen Feld transportiert wird.

Bei der Erkennung über den exakten Satz ist das Regime enger. Der Satz der Identifier muss strikt identisch sein, wobei Groß- und Kleinschreibung sowie Reihenfolge keine Rolle spielen (eine Nuance, die viele Artikel umkehren). Die Ausnahme deckt dann nur New Orders per Account und New Certificates per Registered Domain ab.

Die Schlussfolgerung gehört an die Wand gehängt: Ein SAN-Zertifikat um eine Subdomain zu erweitern, verbraucht das Kontingent der 50 pro registrierter Domain, während die unveränderte Erneuerung gar nichts verbraucht. "50 Zertifikate pro Woche und Domain" ohne diese Präzisierung zu schreiben, beschreibt eine Bestandsobergrenze, die es nicht gibt. Dieses Limit misst einen Zugangsdurchsatz neuer Namen.

Die Limits, die wirklich beißen, nach Gefährlichkeit sortiert

Fünf Rate Limits sollte man kennen, und sie sind nicht gleichwertig. Hier von den gefährlichsten bis zu den harmlosesten.

Das erste ist das einzige, das eine legitime Schleife ganz allein ausschöpfen kann: 5 Autorisierungsfehler pro Identifier, pro Konto und pro Stunde, Nachfüllen von einem Fehler alle 12 Minuten, keine Anhebung möglich, und vor allem eine Anwendung auf Erneuerungen. Das zweite zählt die aufeinanderfolgenden Fehler und pausiert den Identifier nach 1152 Fehlern in Folge. Das ist ein Serienzähler, kein Durchsatz, und er füllt sich um ein Token pro Identifier und pro Tag nach: Ein Tag mit fünf Fehlern verbraucht netto nur vier, und die Pause tritt erst nach 288 Tagen ein; bei 120 Fehlern pro Tag fällt sie nach 10 Tagen, und bei einem einzigen pro Tag nie. Diese Werte stammen nicht aus einer Hausrechnung, die Let's-Encrypt-Dokumentation veröffentlicht die Tabelle. Verschmelzen Sie die beiden Limits nicht.

Es folgt die echte Obergrenze einer Schleife ohne ARI: 5 Zertifikate pro exaktem Satz von Identifiern alle 7 Tage, Nachfüllen von einem Zertifikat alle 34 Stunden, keine Anhebung. Eine Taktung von 2,1 passt bequem hindurch, und der Puffer fängt die Wiederholversuche ab. Weiter unten in der Rangfolge beißen 10 Konten pro IP-Adresse alle 3 Stunden nur dann, wenn jeder Knoten sein eigenes Konto anlegt, statt eines gemeinsam zu nutzen. Das letzte ist nicht einmal ein Kontingent, sondern eine Profilbeschränkung: shortlived deckelt bei 25 Namen pro Zertifikat, gegenüber 100 bei classic. Der Wechsel auf das Kurzzeitprofil erzwingt also, große SAN-Zertifikate neu zu schneiden, und diese Schnitte sind Neuausstellungen, keine Erneuerungen.

Die Rate Limits von Let's Encrypt, die eine Erneuerungsschleife betreffen

Auf der offiziellen Rate-Limits-Seite dokumentierte Werte, abgerufen am 21. Juli 2026. Diese Ausnahmen und Obergrenzen gelten für Let's Encrypt und lassen sich nicht auf andere Zertifizierungsstellen verallgemeinern.

5

Autorisierungsfehler pro Identifier, Konto und Stunde

Nachfüllen von einem Fehler alle 12 Minuten, keine Anhebung möglich, gilt auch für Erneuerungen.

5

Zertifikate pro exaktem Satz von Identifiern alle 7 Tage

Nachfüllen von einem Zertifikat alle 34 Stunden, keine Anhebung möglich.

50

Neue Zertifikate pro registrierter Domain alle 7 Tage

Zugangsdurchsatz neuer Namen, Nachfüllen von einem Zertifikat alle 202 Minuten. Erneuerungen sind davon ausgenommen.

1152

Aufeinanderfolgende Fehler bis zur Pausierung des Identifiers

Serienzähler, der bei jeder erfolgreichen Validierung zurückgesetzt wird, Ausstieg über das Self-Service-Portal.

Der Integrationsleitfaden des Anbieters ergänzt zwei Betriebshinweise: ab 10.000 Namen in kleinen Chargen statt in großen Paketen erneuern, und die Erneuerungstermine ein für alle Mal verteilen. Das Formular zur Kontingenterhöhung betrifft nur zwei Limits, braucht einige Wochen Bearbeitung und setzt niemals einen Zähler zurück: ein Planungswerkzeug, kein Notfallmittel.

Alles Vorstehende beschreibt die Politik von Let's Encrypt und sonst nichts. Beim AWS Certificate Manager ist die strukturierende Kennzahl keine Anzahl von Zertifikaten, sondern ein Durchsatz, FinalizeOrder gedeckelt auf eine Anfrage pro Sekunde, und diese Kontingente sind im Benutzerhandbuch dokumentiert.

Der echte Fehlermodus: zwei Szenarien, und keines ist ein Kontingent

Die Erneuerungsvorfälle, die wir sehen, sehen nicht aus wie ein überschrittenes Ausstellungskontingent. Sie sehen aus wie diese beiden Szenarien, die eine unangenehme Eigenschaft teilen: Sie verschlimmern sich von allein.

Szenario 1, die Fehlerschleife. Ein DNS-Identifier läuft ab, eine Delegation bricht, Port 80 schließt sich nach einer Änderung der Netzwerkregeln. Der ACME-Client versucht es erneut, oft aggressiv, weil das die Standardeinstellung vieler Konfigurationen ist. Beim sechsten Fehlschlag innerhalb einer Stunde auf demselben Identifier wird jedes Kommando mit diesem Namen abgelehnt, und das Nachfüllen sinkt auf einen Fehler alle 12 Minuten. Ein in zehn Minuten reparierbarer Vorfall wird zu einem mehrstündigen Ausfall, nicht wegen des ursprünglichen Problems, sondern wegen des Verhaltens des Clients gegenüber dem Problem. Und der Zähler der aufeinanderfolgenden Fehler steigt derweil in Richtung der 1152 des zweiten Limits. Die Gegenmaßnahme besteht aus zwei Einstellungen: einem exponentiellen Backoff auf Client-Seite und einem Alarm auf den Validierungsfehler statt allein auf den nahenden Ablauf.

Szenario 2, die Erneuerung, die keine mehr ist. Ohne ARI verliert ein SAN-Zertifikat seinen Erneuerungsstatus, sobald ein einziger Name hinzukommt oder wegfällt, und das Kommando fällt zurück auf das Kontingent für neue Namen. Viele Bestände erzeugen ihre SAN-Sätze aber aus einem dynamischen Inventar: Kubernetes-Ingress-Controller, kurzlebige Umgebungen, Preview-Plattformen. Kein Kommando ist dann noch eine Erneuerung, und ein eigentlich stabiler Bestand verbraucht den für neue Namen reservierten Durchsatz.

Real wird dieses zweite Szenario durch den Zustand der Clients am 21. Juli 2026. Certbot liest ARI, sendet aber das Feld replaces nicht: Seine Implementierung bleibt lesend, also stützen sich alle seine Kommandos auf die Erkennung über den exakten Satz. lego sendet replaces seit v4.16.0, ignoriert ARI aber seit v5.1.0, wenn sich die SAN geändert haben. cert-manager kann es senden, hinter dem Feature Gate ACMEUseARI, eingestuft als Alpha und standardmäßig deaktiviert, verfügbar seit der am 8. Juli 2026 veröffentlichten v1.21.0. acme.sh sendet es seit Version 3.1.4, veröffentlicht am 17. Juli 2026, also vier Tage bevor wir diesen Punkt geprüft haben. Der Schutz existiert im Standard seit Juni 2025. Wirksam ist er fast nirgends.

Ablaufüberwachung von SSL-Zertifikaten: zwei Dinge überwachen, nicht eines

Die Überwachung des Ablaufs und die des Erneuerungsfehlers sind zwei verschiedene Systeme. Das erste sieht die Folge, mit Wochen Verzögerung. Das zweite sieht die Ursache, noch am selben Tag. Ein sauber ausgestatteter Bestand hat beide, und sie hängen nicht von derselben Komponente ab.

Schwellenwerte, die kurze Zertifikate nicht überleben

Ein auf 30 Tage gesetzter Alarmschwellenwert wird bei einem 47-Tage-Zertifikat absurd. Er löst schon am 17. Lebenstag des Zertifikats aus, also während mehr als der Hälfte seiner Existenz. Der Alarm ist dauerhaft, also unsichtbar, also nutzlos. Der Schwellenwert muss relativ zur Lebensdauer werden: ein Bruchteil, keine Konstante.

Diese Anforderung wenden wir gleich auf unsere eigenen Tools an. Der SSL Certificate Checker von CaptainDNS nutzt einen auf 30 Tage fixierten Schwellenwert für "läuft bald ab", und die Alarmstufen der Posture-Bewertung sind T-30, T-14, T-7, T-3 und T-1. Ein relativer Schwellenwert der Art max(15, Lebensdauer / 3) ist in der internen Spezifikation vorgesehen, aber er ist nicht implementiert. In einem Bestand mit Kurzzeitprofil müssen Sie diese Werte selbst nachrechnen.

Was neben dem Ablauf einen Alarm auslösen muss

Neben dem Ablaufdatum verdienen sechs Signale einen Alarm. Das letzte der Liste ist das nützlichste von allen.

• Ein Wechsel der Seriennummer signalisiert eine erfolgte Erneuerung, also eine gute Nachricht, die man trotzdem mitbekommen sollte.
• Ein Wechsel des Ausstellers kann einen ungeplanten CA-Wechsel verraten.
• Eine unvollständig gewordene Kette bricht die Validierung nur bei einem Teil der Clients, was sie schwer reproduzierbar macht.
• Ein nicht mehr passender Hostname tritt nach einer Migration auf.
• Ein schwach gewordenes Protokoll oder ein schwach gewordener Schlüssel zeigen eine regredierte Konfiguration an.
• Und vor allem der ACME-Validierungsfehler: das einzige Signal, das früh genug eintrifft, um den Ausfall zu verhindern.

Umgekehrt erzeugen zwei Reflexe nur Rauschen. Nie auf einen NXDOMAIN von _acme-challenge alarmieren, aus dem oben dargelegten Grund. Und nicht auf einen bloßen Fingerprint-Wechsel ohne sichtbare Zustandsänderung alarmieren, sonst erntet man Fehlalarme bei jedem Frontend-Wechsel.

Unsere Grenzen, offen gesagt, weil sie ändern, wie die vorstehenden Absätze zu lesen sind. Die Posture-Bewertung ist ein kostenpflichtiges Opt-in je Monitor. Ihre Standardtaktung beträgt 86.400 Sekunden, also ein Durchlauf pro Tag: Von "kontinuierlicher Überwachung" zu sprechen, wäre falsch. Es gibt keinerlei Discovery des Bestands, keine Aufzählung über die Transparenz-Logs: Sie überwachen, was Sie deklarieren, eine URL nach der anderen. Und es gibt kein STARTTLS, also nichts für Ihre Mailserver.

Ab wann lohnt sich ein kostenpflichtiges Tool?

Die Kaufschwelle zählt nicht in Zertifikaten. Sie zählt in Endpunkten, die kein Skript neu laden kann. Ein Bestand von 800 Zertifikaten, vollständig über einen Ingress-Controller gesteuert, rechtfertigt keine Ausgabe; ein Bestand von 60 Zertifikaten, von denen 25 auf Appliances mit Weboberfläche leben, rechtfertigt sie sofort.

Sortieren Sie Ihren Bestand in drei Spalten und zählen Sie dann die dritte.

Klasse	Was das Skript erledigt	Was menschlich bleibt
Durchgängig automatisierbar	Ausstellung, Installation, Reload, Prüfung der ausgelieferten Seriennummer	Nichts im Normalbetrieb
Teilweise automatisierbar	Ausstellung und Ablage der Datei	Installation oder Reload von Hand, oft über eine Konsole
Nicht automatisierbar	Nur die Ausstellung	Anmeldung an einer Weboberfläche, Import der Datei, Neustart

Der Kipppunkt liest sich an der dritten Zeile ab, multipliziert mit der künftigen Frequenz. Ein nicht automatisierbarer Endpunkt kostet im 47-Tage-Regime mindestens acht Eingriffe pro Jahr, nämlich bei Erneuerung zum Ablauf, und elf bis zwölf bei der empfohlenen Erneuerung nach zwei Dritteln; der Leitfaden zum Lebenszyklus modelliert mit einer anderen Kalenderannahme etwas weniger als acht, ohne dass sich die Größenordnung verschiebt. Gegenüber zwei heute. Bilden Sie das Produkt mit Ihren gemessenen, nicht geschätzten Minuten, und vergleichen Sie es mit dem Preis einer Lizenz: Die Rechnung verlangt weder Benchmark noch Ausschreibung.

Das am Artikelende bereitgestellte Schwellenmodell macht diese Annahmen einzeln veränderbar: Anzahl der nicht neu ladbaren Endpunkte, Rotationstaktung je Gültigkeitsstufe, Minuten pro Rotation, belasteter Stundensatz und Referenzpreis. Jeder vorbefüllte Wert trägt dort seinen Status, dokumentiert, abgeleitet oder zu einem Datum erhoben, sodass es eine Minute dauert, unsere Annahmen durch Ihre zu ersetzen.

Apropos Preise. Auf dem AWS Marketplace, Erhebung vom 21. Juli 2026, weist die Seite von AppViewX AVX ONE CLM zwei öffentliche Stufen bei einmonatiger Vertragslaufzeit aus: 2100 $ pro Monat für 100 Serverzertifikate und 4200 $ pro Monat für 250 Serverzertifikate. Derselbe Anbieter veröffentlicht auf seiner PKIaaS-Seite 5000 $ und 9100 $ pro Monat, was verbietet, die 2100 $ als "den" öffentlichen Preis des Anbieters darzustellen. Die Seite von Venafi Certificate Management Service enthält keinen Preis und verweist auf ein privates Angebot auf Anfrage. Die DigiCert-Seite weist einen Betrag von 5000 $ für einen Zwölf-Monats-Vertrag aus, weist aber zugleich darauf hin, dass sie Käufen über ein privates Angebot vorbehalten ist. Diese Erhebung bezieht sich auf die an jenem Tag eingesehenen Seiten, auf einen einzigen Marktplatz und auf den Begriff des öffentlich abschließbaren Preises. Sie sagt nichts über ausgehandelte Tarife und nichts über Anbieter, die in dieser Erhebung fehlen.

Ein Wort zum Markt, formuliert als Feststellung einer Abwesenheit. Auf gartner.com ist kein Magic Quadrant zum Zertifikatslebenszyklus-Management gelistet: Gartner behandelt das Thema über einen am 29. Mai 2025 veröffentlichten "Buyers' Guide for PKI and Certificate Life Cycle Management" und über einen Peer-Insights-Bereich mit Nutzerbewertungen. Und die Zahlen, die in Verkaufsargumentationen kursieren, sind zuschreibbar und mehr nicht: In einer Pressemitteilung vom 2. Juli 2025 gibt DigiCert an, dass 45 % der Befragten seiner Umfrage "Trust Pulse" erklären, eine Dienstunterbrechung im Zusammenhang mit einem Zertifikatsvorfall erlitten zu haben, und dass 31 % Verluste zwischen 50.000 und 250.000 Dollar angeben. Die Mitteilung nennt weder die Zahl der Befragten noch ihr Profil, noch die abgedeckten Länder, noch den Erhebungszeitraum, und wir haben zu diesem Datum keinen Bericht gefunden, der diese Methodik darlegt. Das sind Aussagen von Befragten einer Umfrage, die ein Akteur der Kategorie beauftragt hat, keine Messung.

Merken Sie sich die Geste, nicht die Zahlen: die dritte Spalte zählen, mit Ihren Minuten multiplizieren, vergleichen.

🎯 Aktionsplan: die Reihenfolge zum Abarbeiten

Acht Aktionen, in dieser Reihenfolge. Die ersten drei erledigt man einmal; die folgenden werden zu Betriebsreflexen.

1. Je Paar (Host, Port) inventarisieren, durch Kreuzen der Transparenz-Logs, von Platte und Zertifikatspeichern und dann des Netzwerk-Scans. Starten Sie diesen Scan aus einem Netz, das ausgehende Ports nicht filtert, sonst tauchen Ihre Mailserver nie auf.
2. "Host nicht erreicht" als Inventarfehler behandeln, mit einer expliziten Zeile im Bericht. Ein still als Erfolg gezähltes "nicht erreichbar" macht ein Dashboard falsch.
3. _acme-challenge per CNAME delegieren, dann die Delegation in drei Schritten prüfen: Der CNAME existiert, die Kette löst auf, die Zielzone antwortet auf SOA. Und außerhalb von Erneuerungsphasen nicht auf NXDOMAIN alarmieren.
4. Nach jeder Erneuerung prüfen, dass die ausgelieferte Seriennummer die der Platte ist, auch außerhalb von 443. Das ist die Kontrolle, die den vergessenen Reload erwischt, und sie kostet zwei Skriptzeilen.
5. Einen exponentiellen Backoff im Client einbauen und auf den Validierungsfehler alarmieren. Ohne das wird ein Zehn-Minuten-Vorfall zur stundenlangen Blockade.
6. Prüfen, ob Ihr Client replaces sendet, oder akzeptieren, von der Erkennung über den exakten Satz abzuhängen, was bedeutet, Ihre SAN einzufrieren.
7. Alarmschwellen von einem festen Wert auf einen Bruchteil der Lebensdauer umstellen. Dreißig Tage bedeuten bei einem 47-Tage-Zertifikat nichts.
8. Ihre nicht neu ladbaren Endpunkte zählen, bevor Sie Tools vergleichen. Diese Zahl entscheidet über den Kauf; die Anzahl der Zertifikate nicht.

Acht Aktionen, zwei Dateien zum Herunterladen und eine einzige zu ermittelnde Zahl: die Anzahl der Endpunkte, die niemand neu laden kann. Sie entscheidet über das Weitere, nicht die Größe des Bestands.

FAQ

Lässt sich ein SSL-Zertifikat automatisch erneuern?

Ja, und mit ACME ist das seit Jahren der Normalbetrieb. Die eigentliche Frage betrifft die vollständige Kette: Ausstellung, Installation, Reload des Dienstes und Prüfung. Die Erweiterung ARI erlaubt zusätzlich, dem von der Zertifizierungsstelle vorgeschlagenen Fenster zu folgen, aber ihre Unterstützung auf Client-Seite bleibt am 21. Juli 2026 ungleichmäßig. Certbot liest sie, ohne das Feld replaces zu senden, cert-manager hält sie hinter einem standardmäßig deaktivierten Feature Gate, acme.sh hat sie am 17. Juli 2026 in Version 3.1.4 verdrahtet.

Wie automatisiert man die Erneuerung von SSL-Zertifikaten?

Drei Bausteine genügen. Ein geplanter ACME-Client, der das Zertifikat beschafft. Eine _acme-challenge-Delegation per CNAME auf eine dedizierte Validierungszone, was verhindert, dem erneuernden Server die Schlüssel Ihrer Produktionszone anzuvertrauen. Und eine Kontrolle, die die auf der Platte gelesene Seriennummer mit der tatsächlich auf dem betreffenden Port ausgelieferten vergleicht. Der dritte Baustein ist der, den man vergisst, und er ist der, der den fehlenden Reload aufdeckt.

Wie erneuert man ein SSL-Zertifikat?

Eine Erneuerung ist keine Verlängerung: Sie ist eine vollständige Neuausstellung, mit einer neuen Domain-Kontrollvalidierung, falls das Wiederverwendungsfenster abgelaufen ist. Bei Let's Encrypt wird ein Kommando auf zwei Wegen als Erneuerung anerkannt: Es benennt über ARI das Zertifikat, das es ersetzt, oder es trägt exakt denselben Satz von Identifiern wie das ausscheidende Zertifikat. In beiden Fällen entgeht es den Ausstellungslimits für neue Namen.

Wie prüft man, ob eine Erneuerung wirklich wirksam geworden ist?

Lassen Sie den ACME-Client die Ausstellung erledigen und prüfen Sie das Ergebnis dann über das Netz statt über die Logs des Clients. Das nützliche Kommando vergleicht openssl x509 -in fullchain.pem -noout -serial mit der Seriennummer, die openssl s_client am Dienst zurückgibt. Weichen beide voneinander ab, ist das Zertifikat auf der Platte erneuert, der Dienst liefert aber noch das alte aus: Es fehlt ein Reload.

Was tun, wenn mein SSL-Zertifikat abläuft?

Bei einem Webdienst sieht man den Ablauf sofort: Die Browser blockieren. Bei einem durch DANE geschützten Mailserver ist es hinterhältiger. RFC 7672 verbietet die Zustellung über einen Server, dessen Authentifizierung fehlschlägt, und der Absender weicht auf den nächsten MX aus oder schiebt die Zustellung auf: Auf Ihrer Seite kein Alarm. Beginnen Sie die Diagnose also mit dem Auslesen des tatsächlich auf dem betreffenden Port ausgelieferten Zertifikats, nicht mit Ihren Anwendungslogs.

Wie viele Let's-Encrypt-Zertifikate kann ich pro Woche erneuern?

Die Frage geht von einer falschen Annahme aus, der verbreitetsten des Themas. Erneuerungen sind vom Limit der 50 Zertifikate pro registrierter Domain und Zeitraum von 7 Tagen ausgenommen: Dieses Limit misst den Zugang neuer Namen. Eine über ARI gesteuerte Erneuerung entgeht sogar allen Limits. Ohne ARI ist die einzige Beschränkung, die beißt, die Obergrenze von 5 Zertifikaten pro exaktem Satz von Identifiern alle 7 Tage.

Wie inventarisiert man einen Zertifikatsbestand?

Durch Kreuzen von vier Quellen, von denen keine vollständig ist. Die Transparenz-Logs listen, was öffentlich ausgestellt wurde, ignorieren aber Ihre interne PKI. Platte und Zertifikatspeicher (PEM, Java-Keystores, Windows-Speicher) listen, was installiert ist, nicht was ausgeliefert wird. Der Netzwerk-Scan liest, was tatsächlich präsentiert wird, verfehlt aber alles, was Ihre ausgehende Firewall filtert, allen voran Port 25. Die APIs Ihrer Anbieter decken die verwalteten TLS-Terminierungen ab. Indexieren Sie das Ergebnis auf das Paar (Host, Port).

Wie delegiert man _acme-challenge per CNAME, ohne die Schlüssel zur Zone herzugeben?

Legen Sie einen CNAME von _acme-challenge.captaindns.com auf einen Namen in einer dedizierten Validierungszone an und geben Sie dem ACME-Client dann Anmeldedaten, die nur in diese Zone schreiben. Prüfen Sie in drei Schritten: Der CNAME ist vorhanden, die TXT-Auflösung liefert einen stimmigen Status, die Zielzone antwortet auf SOA. Ein NXDOMAIN außerhalb einer Erneuerungsphase ist normal. Der Draft draft-ietf-acme-dns-account-label-03 sieht vor, die Grenze eines einzigen Delegationsziels pro Domain aufzuheben, aber das ist noch keine Norm.

Ab wie vielen Endpunkten sollte man ein Tool kaufen?

Es gibt keine universelle Schwelle, und schon gar keine in Zertifikaten ausgedrückte. Zählen Sie die Endpunkte, die kein Skript neu laden kann, multiplizieren Sie mit der Zahl der künftigen jährlichen Rotationen (mindestens acht im 47-Tage-Regime, elf bis zwölf bei Erneuerung nach zwei Dritteln) und mit den Minuten, die auf jeden entfallen. Vergleichen Sie die Summe mit den Kosten einer Lizenz: Auf dem AWS Marketplace weist die Seite von AppViewX AVX ONE CLM bei der letzten Erhebung 2100 $ pro Monat für 100 Serverzertifikate aus. Schreiben Sie die Annahmen Ihrer Rechnung auf, sie zählen genauso viel wie das Ergebnis.

Vergleichstabellen herunterladen

Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.

• Parametrierbares Schwellenmodell herunterladen (CSV)
• Parametrierbares Schwellenmodell herunterladen (JSON)

Deployment-Checkliste herunterladen

Assistenten können die Checkliste über die JSON- oder CSV-Exporte unten wiederverwenden.

• Bestandsaudit-Raster herunterladen (CSV)
• Bestandsaudit-Raster herunterladen (JSON)

📖 Glossar

• ARI (ACME Renewal Information): ACME-Erweiterung, normiert durch RFC 9773, im Status Proposed Standard. Es ist eine Erweiterung, keine Revision von ACME: Sie macht RFC 8555 weder obsolet noch aktualisiert sie diese.
• DCV (Domain Control Validation): Nachweis, dass der Antragsteller die Domain kontrolliert. Seine Wiederverwendung ist seit März 2026 auf 200 Tage gedeckelt, 2027 auf 100 Tage und 2029 auf 10 Tage: Dieser Zähler fällt auf 10 Tage, nicht die Gültigkeit.
• Exakter Satz von Identifiern: strikt identische Menge der von einem Zertifikat abgedeckten Namen. Bei Let's Encrypt dient sie dazu, eine Erneuerung ohne ARI zu erkennen; Groß- und Kleinschreibung sowie Reihenfolge spielen keine Rolle, aber schon ein einziger zusätzlicher Name kostet den Erneuerungsstatus.
• Registrierte Domain: der bei einer Registrierungsstelle gekaufte Teil der Domain, identifiziert über die Public Suffix List. Alle Subdomains teilen sich dasselbe Kontingent. Let's Encrypt verwendet den Begriff "eTLD+1" nie.
• Profil shortlived: Ausstellungsprofil von Let's Encrypt mit 160 Stunden Gültigkeit und maximal 25 Namen, allgemein verfügbar seit dem 15. Januar 2026. Es bleibt optional, und seine Zertifikate enthalten bis heute eine URL zu einer Sperrliste.
• Nicht neu ladbarer Endpunkt: Endpunkt, an dem sich ein Zertifikat automatisch ausstellen, aber nur von Hand installieren lässt, mangels API oder nicht-interaktivem Zugang. Er ist die Recheneinheit der Kaufschwelle.

---

Eine letzte Kontrolle zum Schluss. Die Geste, die dieses Playbook durchzieht, das tatsächlich ausgelieferte Zertifikat mit dem zu vergleichen, das man ausgerollt zu haben glaubt, hat ein Feld, in dem sie keine Näherung duldet: Wenn Ihre MX TLSA-Einträge veröffentlichen, wird die Rotation vor dem Rollout geprüft, nie danach. Der DANE/TLSA-Checker löst Ihre Einträge auf, validiert die DNSSEC-Kette und kann optional das vom SMTP-Server präsentierte Zertifikat mit dem abgleichen, was Ihr DNS ankündigt.

---

📚 Verwandte Leitfäden zu Zertifikaten und DNS

• Ballot SC-085v2: CAs prüfen DNSSEC vor der Ausstellung: was die Zertifizierungsstellen vor jeder Validierung in Ihrem DNS kontrollieren.
• DANE und TLSA: der vollständige Leitfaden: TLSA-Einträge im Takt der Erneuerungen veröffentlichen und rotieren.
• HSTS und Preload: der vollständige Leitfaden: warum es keinerlei Spielraum gibt, wenn bei einer Site mit HSTS das Zertifikat abläuft.

Quellen

1. Let's Encrypt: Rate Limits
2. Let's Encrypt: Certificate Profiles
3. Let's Encrypt: Integration Guide
4. CA/Browser Forum: Baseline Requirements for TLS Server Certificates
5. draft-ietf-acme-dns-account-label: ACME DNS Labeled With ACME Account ID Challenge