47-Tage-TLS-Zertifikate: Zeitplan und Automatisierung

Kurz gesagt. Mit Ballot SC-081, angenommen am 11. April 2025, verkürzt das CA/Browser Forum die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate in drei Schritten. Zertifikate, die ab dem 15. März 2026 ausgestellt werden, dürfen bis zu 200 Tage gültig sein, ab dem 15. März 2027 bis zu 100 Tage und ab dem 15. März 2029 bis zu 47 Tage. Die Frist, in der eine CA eine Domain-Validierung wiederverwenden darf, schrumpft zu denselben Terminen: auf 200 Tage, dann 100, dann 10. In der Praxis muss jedes Zertifikat automatisiert (per ACME) ausgestellt und bereitgestellt werden. Die Erneuerung sollte dem ARI-Fenster der CA folgen, und du brauchst ein Monitoring, das dich alarmiert, solange noch Zeit bleibt, eine fehlgeschlagene Erneuerung in Ordnung zu bringen. Private CAs sind nicht betroffen.

Der Zeitplan

Die Regeln stehen in den Abschnitten 6.3.2 und 4.2.1 der Baseline Requirements (Version 2.3.1, Oktober 2026). Ballot SC-081v3 wurde von Apple eingebracht und von Sectigo, Google Chrome und Mozilla befürwortet. Der Vorschlag wurde mit 25 Ja-Stimmen der CAs angenommen, ohne Gegenstimme und bei 5 Enthaltungen, und alle vier Browserhersteller stimmten mit Ja.

Einige Details, auf die es ankommt, wenn du mit diesen Zahlen planst:

• Die Grenzen sind Obergrenzen, die CAs bei der Ausstellung durchsetzen. Ein am 14. März 2026 ausgestelltes Zertifikat durfte noch 398 Tage gültig sein. Nichts zwingt dich, es vor seinem Ablauf zu ersetzen, aber sein Ersatz wird eine kurze Laufzeit haben.
• „Gültigkeit“ schließt beide Enden ein. Die BR definieren sie als den Zeitraum von notBefore bis einschließlich notAfter und empfehlen einen Tag Puffer: Zertifikate sollen 199, 99 und 46 Tage nicht überschreiten („SHOULD NOT“).
• Die Grenze für die Wiederverwendung der Validierung ist die größere Änderung. Heute kann eine CA den Nachweis, dass du über example.com verfügst, monatelang wiederverwenden. Ab 2029 darf der Nachweis höchstens 10 Tage alt sein, sodass fast jede Ausstellung eine frische Domain-Validierung braucht, und auch die DNS- oder HTTP-Challenge muss automatisiert sein.
• Details zur Organisation in OV- und EV-Zertifikaten (Firmenname, Adresse) dürfen 398 statt 825 Tage wiederverwendet werden.
• Geltungsbereich. Die BR regeln TLS-Serverzertifikate öffentlich vertrauenswürdiger CAs. Zertifikate deiner eigenen internen CA, Client-Zertifikate und S/MIME-Zertifikate unterliegen anderen Regeln oder gar keinen.

Was CAs heute ausstellen

Am 20. Oktober 2026 sahen die Zertifikate, die einige große Websites auslieferten, so aus. Die Ausgabe stammt aus dem Skript lifetimes.sh im Abschnitt zum Monitoring:

letsencrypt.org        Let's Encrypt              2026-09-04  ->  2026-12-03  (90 days)
www.google.com         Google Trust Services      2026-09-28  ->  2026-12-21  (84 days)
github.com             Sectigo Limited            2026-09-01  ->  2026-11-29  (90 days)
www.microsoft.com      Microsoft Corporation      2026-01-22  ->  2027-01-17  (360 days)
www.amazon.com         Amazon                     2026-01-19  ->  2027-01-11  (358 days)
www.digicert.com       DigiCert Inc               2026-10-11  ->  2026-11-26  (47 days)

Zwei davon nutzen noch Zertifikate mit fast einem Jahr Laufzeit, ausgestellt im Januar 2026, kurz bevor die 200-Tage-Grenze in Kraft trat. DigiCert liefert auf seiner eigenen Website bereits ein 47-Tage-Zertifikat aus. Laut seinem veröffentlichten Plan geht Let's Encrypt schneller vor, als die BR es verlangen:

• 13. Mai 2026: Das optionale Profil tlsserver stellt 45-Tage-Zertifikate aus.
• 10. Februar 2027: Das Standardprofil classic stellt 64-Tage-Zertifikate aus, deren Autorisierungen 10 Tage lang wiederverwendet werden dürfen.
• 16. Februar 2028: classic stellt 45-Tage-Zertifikate aus, deren Autorisierungen 7 Stunden lang wiederverwendet werden dürfen.

Das live abgerufene ACME-Verzeichnis listet die Profile auf, die du heute anfordern kannst:

"meta": {
  "profiles": {
    "classic": "https://letsencrypt.org/docs/profiles#classic",
    "shortlived": "https://letsencrypt.org/docs/profiles#shortlived",
    "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
  }
},
"renewalInfo": "https://acme-v02.api.letsencrypt.org/acme/renewal-info"

Was zu automatisieren ist

Bei 398-Tage-Zertifikaten war eine manuelle jährliche Erneuerung lästig, aber verkraftbar. Bei 47-Tage-Zertifikaten und einer Wiederverwendung der Validierung von 10 Tagen wird die manuelle Erneuerung zu einer fehleranfälligen Aufgabe, die mindestens achtmal im Jahr für jeden Namen anfällt – eher zwölfmal, wenn du bei zwei Dritteln der Laufzeit erneuerst. Die Arbeit gliedert sich in vier Teile.

1. Ausstellung über ACME. Verwende für jedes Zertifikat einer öffentlichen CA einen ACME-Client (RFC 8555). Die meisten kommerziellen CAs bieten ebenfalls ACME-Endpunkte an, oft mit External Account Binding. Kommt ein Zertifikat noch per E-Mail, als Download aus einem Portal oder über ein Ticket, gehört es als Erstes auf die Liste.

2. Validierung, die unbeaufsichtigt läuft. Wähle eine Challenge, die ohne menschliches Zutun funktioniert:

• http-01 setzt voraus, dass Port 80 auf jedem Host erreichbar ist, der Anfragen für den Namen beantwortet.
• dns-01 braucht API-Zugriff auf deinen DNS-Anbieter. Beschränke das Token auf die Einträge unter _acme-challenge, sofern der Anbieter das zulässt.
• tls-alpn-01 läuft vollständig über Port 443.

Zwei neuere Methoden sind genau für diesen Fall gedacht. „DNS Labeled with Account ID“, die ACME-Challenge dns-account-01 in BR §3.2.2.4.21, lässt mehrere ACME-Konten denselben Namen validieren, ohne dass sie sich um einen einzigen Eintrag _acme-challenge streiten müssen. „DNS TXT Record with Persistent Value“ (§3.2.2.4.22, Ballot SC-088) erlaubt dir, einmal einen dauerhaften Eintrag zu veröffentlichen:

_validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"

Die CA darf jede Prüfung dieses Eintrags höchstens 10 Tage lang als gültig betrachten. Weil die CA den Eintrag aber selbst erneut prüft, muss niemand für jede Erneuerung DNS anfassen. Frag deine CA, ob sie die Methode unterstützt, bevor du dich darauf verlässt.

3. Erneuerung, die der CA folgt. Erneuere früh und lass die CA den Zeitpunkt steuern:

• Erneuere bei etwa zwei Dritteln der Laufzeit. Das ist Tag 30 eines 45-Tage-Zertifikats. Let's Encrypt stellt klar, dass es „nicht mehr ausreichen wird, in einem fest einprogrammierten Intervall von 60 Tagen zu erneuern“. Seit Version 4.0 erneuert certbot, wenn noch ein Drittel der Laufzeit übrig ist, statt pauschal 30 Tage vor Ablauf.
• Nutze ARI (RFC 9773), beschrieben im nächsten Abschnitt. Die CA teilt jedem Client mit, wann er erneuern soll, und kann dieses Fenster vorverlegen, wenn sie Zertifikate massenhaft widerrufen muss.
• Fordere das Profil ausdrücklich an, wenn du 45-Tage-Zertifikate willst, bevor sich die Voreinstellung deiner CA ändert.

4. Bereitstellung für jede Kopie. Mit der erneuerten Datei auf der Festplatte ist es nicht getan. Liste jeden Ort auf, an den ein Zertifikat kopiert wird:

• Load Balancer und CDNs, die hochgeladene Zertifikate annehmen,
• Kubernetes-Secrets,
• Java-Keystores und PKCS#12-Bundles,
• Appliances, Mailserver, Datenbanken und Message Broker,
• mobile Apps, die ein Leaf-Zertifikat pinnen.

Jede Kopie braucht entweder einen Reload-Hook oder eine Integration, die das neue Zertifikat abholt. Ein Leaf-Zertifikat oder dessen Schlüssel in einer App zu pinnen, wird bei diesem Takt undurchführbar. Pinne stattdessen einen CA-Schlüssel, oder besser: Verzichte ganz auf Pinning.

Dieser Test lässt certbot 5.8.0 gegen einen lokalen ACME-Server laufen, Pebble 2.10.1, dessen Profil tlsserver 45-Tage-Zertifikate ausstellt. Er zeigt, dass die Anforderung des Profils und die Erneuerungskonfiguration wie dokumentiert funktionieren:

$ certbot certonly --standalone --non-interactive --agree-tos --register-unsafely-without-email \
    --server https://localhost:14000/dir -d app.example.test --preferred-profile tlsserver
Account registered.
Requesting a certificate for app.example.test
Successfully received certificate.
This certificate expires on 2026-12-04.
$ openssl x509 -in /etc/letsencrypt/live/app.example.test/cert.pem -noout -startdate -enddate
notBefore=Oct 20 11:47:52 2026 GMT
notAfter=Dec  4 11:47:51 2026 GMT
$ grep -E "preferred_profile|server" /etc/letsencrypt/renewal/app.example.test.conf
preferred_profile = tlsserver
server = https://localhost:14000/dir
$ certbot renew --non-interactive
Processing /etc/letsencrypt/renewal/app.example.test.conf
Certificate not yet due for renewal

certbot speichert das Profil in der Erneuerungskonfiguration, sodass jede spätere Erneuerung es erneut anfordert. Das Flag --preferred-profile gibt es seit certbot 4.0. Führt das Verzeichnis der CA das genannte Profil nicht, fällt certbot auf das Standardprofil der CA zurück. Mit --required-profile schlagen Ausstellung oder Erneuerung in diesem Fall stattdessen fehl. Profile stammen aus dem Entwurf draft-ietf-acme-profiles, der im Oktober 2026 auf die Prüfung durch die IESG wartete. Andere Clients als certbot benennen das Flag anders.

ACME Renewal Information (ARI)

Mit ARI (RFC 9773, Juni 2025) ist der Erneuerungszeitpunkt keine clientseitige Schätzung mehr, sondern eine Frage an die CA. Für jedes Zertifikat bildet der Client einen Bezeichner aus dem Authority Key Identifier und der Seriennummer des Zertifikats:

url = renewalInfo || '/' || base64url(AKI keyIdentifier) || '.' || base64url(Serial)

Diese URL fragt er anschließend ohne Authentifizierung regelmäßig ab. Die Antwort enthält ein suggestedWindow, und ein Header Retry-After gibt an, wann erneut gefragt werden soll. Du kannst das für jedes Zertifikat von Let's Encrypt selbst abfragen:

#!/bin/bash
set -e
host="$1"
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out cert.pem
aki=$(openssl x509 -in cert.pem -noout -ext authorityKeyIdentifier | grep -o -E '([0-9A-F]{2}:){19}[0-9A-F]{2}' | tr -d ':')
serial=$(openssl x509 -in cert.pem -noout -serial | cut -d= -f2)
# The DER INTEGER content keeps a leading 00 byte when the high bit is set.
[ $(( 16#${serial:0:1} )) -ge 8 ] && serial="00$serial"
b64url() { python3 -c 'import sys,base64; print(base64.urlsafe_b64encode(bytes.fromhex(sys.stdin.read().strip())).decode().rstrip("="))'; }
id="$(printf %s "$aki" | b64url).$(printf %s "$serial" | b64url)"
ari=$(curl -s https://acme-v02.api.letsencrypt.org/directory | grep -o '"renewalInfo": *"[^"]*"' | cut -d'"' -f4)
openssl x509 -in cert.pem -noout -issuer -startdate -enddate
echo "GET $ari/$id"
curl -s -D - "$ari/$id" | grep -i -E '^retry-after|^\{|"'

issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
GET https://acme-v02.api.letsencrypt.org/acme/renewal-info/uVnyjs8i8IbTN0j_dhQYuoLYVYc.BUOTO-OGs6KzrdU08hA7yLZf
retry-after: 25769
{
  "suggestedWindow": {
    "start": "2026-11-02T17:18:36Z",
    "end": "2026-11-04T12:29:25Z"

Das Fenster öffnet sich 59 Tage nach Beginn der Laufzeit dieses 90-Tage-Zertifikats, also bei etwa zwei Dritteln. Der Client sollte einen zufälligen Zeitpunkt innerhalb des Fensters wählen; so verteilen sich die Erneuerungen über die Zeit. Muss die CA Zertifikate massenhaft widerrufen, verschiebt sie das Fenster in die Vergangenheit, und Clients, die sich korrekt verhalten, erneuern innerhalb von Stunden, statt beim Ablauf zu scheitern. Beim Erneuern schickt der Client den Bezeichner des alten Zertifikats im Feld replaces seiner neuen Order mit.

ARI-Unterstützung in gängigen Clients, laut deren Release Notes:

Monitoring, das eine fehlgeschlagene Erneuerung erkennt

Automatisierung fällt lautlos aus: ein abgelaufenes DNS-API-Token, eine Firewall-Änderung, die Port 80 blockiert, ein Reload-Hook, der nicht mehr funktioniert. Bei einem 47-Tage-Zertifikat, das an Tag 30 erneuert wird, bleiben dir zwischen der ersten fehlgeschlagenen Erneuerung und einem Ausfall etwa 17 Tage. Lass dich früh in diesem Zeitraum alarmieren.

Von außen. Prüfe jeden öffentlichen Namen, nicht nur die, an die du dich erinnerst. Der Blackbox Exporter von Prometheus gibt den Ablaufzeitpunkt der ausgelieferten Kette als probe_ssl_earliest_cert_expiry aus:

probe_ssl_earliest_cert_expiry 1.795737599e+09
probe_success 1
probe_tls_version_info{version="TLS 1.3"} 1

Diese beiden Alert-Regeln bestehen promtool check rules (Prometheus 3.5.0). Die erste schlägt an, wenn die Erneuerung überfällig ist, die zweite, wenn ein Ausfall kurz bevorsteht:

groups:
  - name: certificates
    rules:
      - alert: CertificateRenewalOverdue
        # Fires when less than a third of a 47-day lifetime (about 16 days) is left:
        # the renewal job should have replaced the certificate by now.
        expr: probe_ssl_earliest_cert_expiry - time() < 16 * 86400
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"
      - alert: CertificateExpiresSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 7 * 86400
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"

Per Skript. openssl x509 -checkend N endet mit dem Exit-Status 1, wenn das Zertifikat innerhalb von N Sekunden abläuft – das genügt für einen Cronjob oder einen CI-Schritt:

$ openssl x509 -in cert.pem -noout -enddate
notAfter=Nov 26 23:59:59 2026 GMT
$ openssl x509 -in cert.pem -noout -checkend $((30 * 86400)); echo "exit status: $?"
Certificate will not expire
exit status: 0
$ openssl x509 -in cert.pem -noout -checkend $((45 * 86400)); echo "exit status: $?"
Certificate will expire
exit status: 1

Die Übersicht oben auf dieser Seite stammt aus diesem Skript:

#!/bin/bash
for host in "$@"; do
  openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out /tmp/c.pem 2>/dev/null || { echo "$host: no certificate"; continue; }
  nb=$(openssl x509 -in /tmp/c.pem -noout -startdate | cut -d= -f2)
  na=$(openssl x509 -in /tmp/c.pem -noout -enddate | cut -d= -f2)
  issuer=$(openssl x509 -in /tmp/c.pem -noout -issuer -nameopt multiline | grep -E "organizationName" | head -1 | cut -d= -f2 | sed 's/^ *//')
  days=$(( ($(date -d "$na" +%s) - $(date -d "$nb" +%s) + 1) / 86400 ))
  printf '%-22s %-26s %s  ->  %s  (%s days)\n' "$host" "$issuer" "$(date -u -d "$nb" +%F)" "$(date -u -d "$na" +%F)" "$days"
done

Aus Sicht der CA. Certificate-Transparency-Logs verzeichnen jedes Zertifikat, das für deine Domains ausgestellt wird. Ein CT-Monitor zeigt dir Erneuerungen, die stattgefunden haben, und Zertifikate, mit denen du nicht gerechnet hast. Mehr dazu im Artikel Certificate Transparency für Entwickler; die Historie einer Domain schlägst du mit dem Tool für die CT-Historie nach. Wie gut eine Reihe von Domains vorbereitet ist, zeigt der 47-Tage-Zertifikatsrechner: Er spielt den Zeitplan für jedes deiner Zertifikate durch.

CAA und Kontobindung

Eine kürzere Wiederverwendung der Validierung bedeutet mehr Validierungen, und jede davon prüft deine CAA-Einträge. Ab dem 15. März 2027 (Ballot SC-098) müssen CAs außerdem die Parameter accounturi und validationmethods aus RFC 8657 beachten. Damit kannst du die Ausstellung auf dein eigenes ACME-Konto und den von dir gewählten Challenge-Typ beschränken:

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"

Der CAA-Eintragsgenerator erstellt solche Einträge. Bedenke, dass ein veralteter CAA-Eintrag deine eigenen Erneuerungen blockiert – und die finden jetzt mindestens achtmal im Jahr statt, nicht mehr nur einmal.

Häufige Fehler

• Ein festes Erneuerungsintervall. „Alle 60 Tage erneuern“ scheitert schon an 45-Tage-Zertifikaten. Erneuere nach einem Anteil der Laufzeit oder zu dem Zeitpunkt, den ARI vorschlägt.
• Erneuern ohne Reload. Die neue Datei liegt auf der Festplatte, während der Server weiter das alte Zertifikat aus dem Speicher ausliefert, bis es abläuft. Teste den Deploy-Hook, nicht nur die Erneuerung.
• Die Kopien vergessen. Der Origin-Server erneuert automatisch, aber im CDN oder Load Balancer steckt noch ein manuell hochgeladenes Zertifikat.
• Alert erst 7 Tage vor Ablauf. Bei 47-Tage-Zertifikaten lässt ein Alert eine Woche vor Ablauf keine Zeit, ein Problem mit der DNS-API oder der Firewall zu debuggen. Lass dich alarmieren, sobald die Erneuerung überfällig ist.
• Pinning von Leaf-Schlüsseln in mobilen Apps oder API-Clients. Jede Erneuerung mit einem neuen Schlüssel legt sie lahm.
• Annehmen, dass eine private PKI nachziehen muss. Deine interne CA kann ihre eigene Richtlinie behalten. Kurze Laufzeiten sind auch dort eine gute Idee, aber die Entscheidung liegt bei dir.

Quellen

• CA/Browser Forum, Baseline Requirements v2.3.1: §1.2.2 (maßgebliche Stichtage), §3.2.2.4.21–22 (neue DNS-Methoden), §4.2.1 (Wiederverwendungsfristen), §6.3.2 (Gültigkeitsdauer).
• Ballot SC-081v3 (angenommen am 11. April 2025, wirksam ab 16. Mai 2025).
• RFC 9773: ACME Renewal Information. RFC 8555: ACME. draft-ietf-acme-profiles.
• Let's Encrypt, Decreasing Certificate Lifetimes to 45 Days und Profile.
• Release Notes von certbot, Caddy, lego, acme.sh und cert-manager.
• RFC 8659 (CAA) und RFC 8657 (CAA accounturi und validationmethods).

Die Befehlsausgaben wurden am 20. Oktober 2026 erzeugt, in node:24.22.0-trixie (OpenSSL 3.5.7, curl 8.14.1), certbot/certbot:v5.8.0 mit ghcr.io/letsencrypt/pebble:2.10.1, quay.io/prometheus/blackbox-exporter:v0.25.0 und prom/prometheus:v3.5.0.