Zertifikatslaufzeiten schrumpfen: Was 64‑Tage- und 45‑Tage-TLS für benutzerdefinierte Domains bei Tunneln bedeuten

Am 10. Februar 2027, ungefähr drei Monate von jetzt an, ändert Let’s Encrypt seine Standard-Zertifikatslaufzeit von 90 Tagen auf 64 Tage. Ungefähr fünf Wochen später, am 15. März 2027, sinkt die branchenweite Höchstgrenze für öffentlich vertrauenswürdige TLS-Zertifikate von 200 Tagen auf 100 Tage. Keine der beiden Änderungen ist überraschend, doch nur wenige Entwickler haben gefragt, was das für eine auf einen Tunnel verweisende benutzerdefinierte Domain bedeutet.

Wenn Sie app.yourdomain.com durch einen Tunneling-Dienst laufen lassen, sitzt ein Zertifikat zwischen Ihren Nutzern (oder Ihren Webhook-Absendern) und Ihrem localhost. Jemand muss es jedes Mal erneuern, wenn die Uhr abläuft, und diese Uhr wird bald schneller ticken. Dieser Leitfaden deckt den genauen Zeitplan ab, wie Erneuerung und DNS-Validierung hinter einem Tunnel funktionieren, den Unterschied zwischen vom Anbieter verwalteten und Bring-Your-Own (BYO) Zertifikaten und die Fehlerfälle, die auftreten, wenn die Erneuerung stillschweigend stoppt.

Der Zeitplan: Was sich tatsächlich ändert und wann

Zwei getrennte Zeitpläne kommen ins Spiel, und oft vermischen Leute sie.

1. Der CA/Browser Forum Zeitplan (gilt für jede öffentliche CA)

Im April 2025 hat das CA/Browser Forum den Ballot SC-081v3 verabschiedet. Es reduziert sowohl die maximale Zertifikatsgültigkeit als auch den Zeitraum, in dem eine CA eine vorherige Domain-Validierung (DCV) erneut verwenden darf. Der Ballot wurde am 11. April 2025 ohne Gegenstimmen angenommen.

Gültigkeitsdatum	Maximale Zertifikatsgültigkeit	Maximale DCV-Wiederverwendung
Bis 14. März 2026	398 Tage	398 Tage
15. März 2026 (bereits in Kraft)	200 Tage	200 Tage
15. März 2027	100 Tage	100 Tage
15. März 2029	47 Tage	10 Tage

2. Der Let’s Encrypt Zeitplan (die CA, die die meisten Tunnel- und ACME-Setups verwenden)

Let’s Encrypt bewegt sich schneller als die Vorgabe. Es wird 45 Tage im Jahr 2028 erreichen, also ein Jahr vor dem Forum‑Maximalwert von 47 Tagen.

Datum	ACME-Profil	Gültigkeit	Autorisierungs-Wiederverwendung
13. Mai 2026 (live)	tlsserver (opt-in)	45 Tage	In der Ankündigung nicht angegeben
10. Februar 2027	classic (Default)	64 Tage	10 Tage (reduziert von 30)
16. Februar 2028	classic (Default)	45 Tage	7 Stunden

Einige Details aus Let’s Encrypts Ankündigungen:

• Staging ist jetzt live. 64‑Tage‑Zertifikate standen seit dem 14. Oktober 2026 in der Staging-Umgebung von Let’s Encrypt zur Verfügung, damit Sie Ihre Erneuerungseinrichtung vor Produktionsänderungen testen können.
• Vorhandene Zertifikate werden nicht widerrufen. Let’s Encrypt erwartet, dass das letzte 90‑Tage‑Zertifikat am 11. Mai 2027 abläuft.
• Nutzer der tlsserver (45‑Tage) oder shortlived (6‑Tage) Profile sind von der Februar-Änderung nicht betroffen.
• Der kurze Autorisierungs-Wiederverwendungszeitraum ist der ruhige Teil. Wenn das Wiederverwendungsfenster schrumpft, beweisen Sie die Domain-Kontrolle bei praktisch jeder Ausstellung statt sich auf eine zwischengespeicherte Validierung zu verlassen. Let’s Encrypt sagt auch, dass damit die Notwendigkeit einer „CAA‑Nacherprüfung“ entfällt, wenn Validierungsdaten älter als sieben Stunden sind.

Wenn Sie das Standardprofil verwenden und Ihre ACME-Client-Einstellungen nie angepasst haben, tritt die Februar-2027-Änderung automatisch in Kraft. Das ist in Ordnung, wenn Ihre Erneuerung wirklich automatisiert ist. Es ist ein Problem, wenn „automatisiert“ bedeutet, dass ein Cron-Job existiert, den niemand seit 2023 angesehen hat.

Warum Tunnel-Benutzerdefinierte Domains eine Sonderrolle sind

Auf einem normalen Server halten Sie den privaten Schlüssel und führen den ACME-Client selbst aus. Bei einem Tunnel gehört der öffentliche Rand dem Anbieter, und Ihre Domain ist ein Alias, der darauf zeigt. Das teilt die Verantwortung in drei Teile:

• Der Anbieter beendet TLS und beschafft bzw. erneuert das Zertifikat in der Regel.
• Sie kontrollieren die DNS-Einträge, die diese Ausstellung ermöglichen.
• Ihre lokale App sieht das Zertifikat überhaupt nicht.

Kürzere Laufzeiten belasten vor allem die DNS‑Hälfte dieses Arrangements. Der Erneuerungsprozess auf Seiten des Anbieters kann fehlerfrei sein und trotzdem scheitern, weil ein Eintrag auf Ihrer Seite abweicht.

Vom Anbieter verwaltete Zertifikate: Praktisch, nicht unsichtbar

Die meisten Tunnel-Plattformen verwenden standardmäßig verwaltete Zertifikate, und die Dokumentation von ngrok ist ein konkretes Beispiel. Sie empfiehlt automatische Zertifikate, sofern Sie keine speziellen Anforderungen haben. Für diese stellt sie Zertifikate von einer ACME‑konformen CA wie Let’s Encrypt bereit und erneuert sie. Es verwendet für die meisten Domains eine HTTP-01‑Herausforderung und wechselt bei Wildcard‑Domains zu DNS-01.

Für eine gebrandete Domain wie api.your-domain.com erstellen Sie einen CNAME-Eintrag, und die Bereitstellung beginnt erst, wenn Sie dies tun. Für eine Wildcard wie *.app.example.com benötigen Sie zwei CNAMEs: die Wildcard selbst und _acme-challenge.app.example.com.

Bereitstellung ist asynchron. ngrok gibt an, dass sie typischerweise von wenigen Sekunden bis zu mehreren Minuten dauert, gelegentlich auch länger, wenn eine DNS-Herausforderung bei der Validierung langsam ist. Währenddessen bedient ngrok sein eigenes Standard‑Wildcard‑Zertifikat. Dieses Zertifikat ist nicht für Ihren Hostnamen ausgestellt, daher zeigen Browser und andere TLS‑Clients eine Hostnamen‑Übereinstimmungswarnung an.

Diese Dokumentation beschreibt einen Anbieter, aber das Muster ist allgemein. Sie zeigt Ihnen, worauf Sie bei kürzeren Laufzeiten achten müssen:

1. Der CNAME ist Ihre Ausstellungsberechtigung. Wenn jemand DNS „bereinigt“ und es entfernt, kann die Bereitstellung nicht fortfahren. Bei 398 Tagen bemerkt man es möglicherweise erst nach einem Jahr. Bei 64 Tagen erfahren Sie es innerhalb von etwa zwei Monaten, und bei 45 Tagen innerhalb von etwa sechs Wochen.
2. Wildcards hängen von einem zweiten Eintrag ab. Der _acme-challenge-CNAME ist leicht zu vergessen, weil nichts Sichtbares bricht, bis das Zertifikat erneuert werden muss.
3. Fallback‑Zertifikate sehen wie ein Ausfall aus. Eine Hostnamen‑Übereinstimmungswarnung ist für viele API‑Clients und Webhook‑Absender ein harter Fehler, selbst wenn ein Mensch durchklicken könnte.

Verwaltete Zertifikate entbinden Sie nicht von Ihren Verpflichtungen. Sie reduzieren sie auf eine kurze Liste: Halten Sie die DNS‑Einträge korrekt und überwachen Sie das Ergebnis.

Bring-Your-Own-Zertifikate: Kontrolle durch Rotationsaufwand

Einige Teams laden ihr eigenes Zertifikat hoch: eines von einer internen CA, ein EV‑Zertifikat oder eines, das von einem Partner verankert wird. Das ist legitim, und der Nachteil verschärft sich mit schrumpfenden Laufzeiten.

Mit ngrok ist zum Beispiel das Übersenden eigener Zertifikate bedeutet, dass Sie für Erneuerung und Rotation verantwortlich sind. Sie laden ein PEM‑Paket mit dem Leaf‑Zertifikat zuerst hoch, gefolgt von Zwischenzertifikaten, plus einem privaten Schlüssel, der nicht verschlüsselt ist. Dann hängen Sie das Zertifikat an eine oder mehrere Domains an, denn das Erstellen allein ändert keinen Traffic.

Bei ngrok sind TLS‑Zertifikate auf allen Plänen verfügbar, aber BYO‑Zertifikate erfordern den Pay‑as‑you‑go‑Plan. Sie kosten eine Pauschale von $0,27 pro Stunde für jede volle Stunde, in der mindestens ein Endpunkt, der dieses Zertifikat verwendet, aktiv ist. Ein Wildcard‑Zertifikat wird einmal berechnet, nicht pro übereinstimmender Subdomain. Preise und Planregeln unterscheiden sich je Anbieter, prüfen Sie daher Ihren.

Nun berechnen Sie die Rotation für einen einzelnen Hostnamen:

Maximale Lebensdauer	Mindestrotationen pro Jahr
398 Tage	1
200 Tage	2
100 Tage	4
64 Tage	6
47 Tage	8

Dies sind Minimalwerte, wenn Sie jedes Zertifikat exakt am Ablaufdatum ersetzen. Frühere Erneuerungen erhöhen die tatsächliche Zahl.

Ein manueller Prozess, der früher einmal im Jahr tolerierbar war (Herunterladen, Konvertieren, Hochladen, Anhängen, Testen), wird zu einer wiederkehrenden Betriebsaufgabe von sechs bis acht Mal pro Jahr pro Hostnamen, multipliziert mit jeder Umgebung. Wenn Sie BYO verwenden müssen, automatisieren Sie den gesamten Pfad:

1. Ihr ACME-Client erhält das Zertifikat.
2. Ein Deploy-Hook lädt es über die API des Anbieters hoch.
3. Ein zweiter Schritt hängt es an die Domain.
4. Eine Prüfung verifiziert anschließend die Gültigkeit des Live-Zertifikats.

Behandeln Sie jeden Schritt, den Sie nicht automatisieren können, als den Schritt, der scheitern wird.

Der Zeitplan des Forums gilt für öffentlich vertrauliche Zertifikate. Eine Zertifizierung von einer privaten PKI, der Ihre eigenen Clients vertrauen, fällt außerhalb, hilft aber nicht, wenn externe Dienste Ihre Tunnel-URL aufrufen.

Was bricht, wenn die Erneuerung stillschweigend fehlschlägt

„Stillschweigend“ ist das operative Wort. Mehrere Dinge, die früher Ausfälle abgefedert haben, sind jetzt schwächer:

• Keine Erinnerungsemails mehr. Let’s Encrypt beendete seine Ablaufbenachrichtigungen am 4. Juni 2025. Es empfiehlt stattdessen Drittüberwachung, und seine Überwachungsseite nennt Red Sift Certificates Lite, das kostenlos bis zu 250 Zertifikate unterstützt. Falls Sie sich auf diese E-Mail als Sicherheitsnetz verlassen haben, ist sie weg.
• Kürzere Fenster lassen weniger Spielraum. Let’s Encrypt empfiehlt, etwa zwei Drittel der Lebensdauer eines Zertifikats zu erneuern. Bei einem 45‑Tage‑Zertifikat bedeutet das erneuern um Tag 30, verbleibend ca. 15 Tage, um einen Fehler zu beheben. Bei einem 64‑Tage‑Zertifikat liegt es bei Tag 43, verbleibend ca. drei Wochen.
• Wiederverwendung nimmt ab. Wenn die Wiederverwendung der Autorisierung auf 10 Tage und dann 7 Stunden für Let’s Encrypts Standardprofil sinkt, bedeutet „es hat beim letzten Mal funktioniert“ nicht mehr automatisch „es wird auch dieses Mal funktionieren.“

Typische Ausfallmodi bei Tunnel-Benutzerdefinierten Domains:

Fehler	Wahrscheinliches Symptom
CNAME entfernt oder während einer DNS-Migration neu ausgerichtet	Bereitstellung oder Erneuerung kann nicht fortfahren; der Status des Anbieters zeigt einen Fehler
HTTP-01-Anfrage von einer Firewall, WAF oder Zugriffspolitik blockiert	Ausstellungsfehler nach einer Konfigurationsänderung
DNS-API-Token abgelaufen oder rotiert (DNS-01 Setups)	Automatisierung schlägt in Protokollen fehl
CAA-Eintrag schließt die verwendete CA aus	Ausstellungsverweigerung
Alter ACME-Client oder aufgegebener Cron-Job	Überhaupt keine Erneuerungsversuche
Hochgeladenes BYO-Zertifikat nicht ersetzt	Das abgelaufene Zertifikat ist weiterhin an die Domain gebunden

Zwei Details aus Let’s Encrypts Dokumentation sind hier relevant. Erstens kann HTTP-01 nur auf Port 80 durchgeführt werden. Seine Validierung folgt bis zu 10 Weiterleitungen, aber nur zu Ports 80 oder 443. Zweitens überprüft Let’s Encrypt CAA-Einträge vor der Ausstellung, und sein CAA‑Identifikator ist letsencrypt.org.

Webhook-Anbieter und API-Verwender sind am wenigsten nachsichtig. Eine Person könnte eine Warnung einfach überspringen, aber ein automatischer Absender scheitert typischerweise beim TLS‑Handshake, und das erste Anzeichen sind fehlende Events statt einer sichtbaren Fehlerseite.

Renewal Timing: Stop Using Fixed Offsets

Viele Tools waren auf 90‑Tage‑Zertifikate mit einer festen Regel konfiguriert, wie „erneuere, wenn 30 Tage verbleiben“ oder „erneuere alle 60 Tage“. Die eigene Anleitung von Let’s Encrypt ist deutlich. Ein fest codierter Intervall von 60 Tagen genügt nicht mehr für 45‑Tage‑Zertifikate. Sie empfiehlt, in Cron-Jobs, Wrapper-Skripten und Runbooks nach festen Zahlen wie 83, 80 oder 60 zu suchen. Alles, was 80 Tage wartet, verpasst ein 64‑Tage‑Zertifikat vollständig.

Die bessere Antwort ist ACME Renewal Information (ARI), standardisiert als RFC 9773. Die CA teilt dem Client mit, wann erneuert werden soll, und Clients sollten innerhalb des vorgeschlagenen Fensters erneuern. Let’s Encrypt empfiehlt ARI, und sagt, dass, falls Ihr Client es nicht unterstützt, ein Erneuern bei etwa zwei Dritteln der Zertifikatslebensdauer akzeptabel ist.

Certbot hat ARI automatisch geprüft, wenn die CA es unterstützt, seit Version 4.1.0 (Juni 2025). Andere Clients unterscheiden sich, prüfen Sie daher Ihren konkreten Client und Ihre Version, statt davon auszugehen. Für Tunnel-Anbieter fragen Sie, ob deren Erneuerungs-Pipeline ARI-basierte Timing verwendet, da Sie sie nicht kontrollieren.

DNS-Validierung bei kürzeren Lebensdauern

HTTP-01 vs DNS-01

HTTP-01 ist einfach für einzelne Hostnamen: Die CA holt ein Token von Ihrer Seite. Bei einem Tunnel beantwortet der Anbieter es in der Regel für Sie, sobald der CNAME eingerichtet ist. DNS-01 ist für Wildcards erforderlich und funktioniert dort, wo HTTP-01 nicht kann, benötigt jedoch Schreibzugriff auf DNS bei jeder Ausstellung. Let’s Encrypt stellt fest, dass das Bereitstellen vollständiger DNS-API-Anmeldedaten auf einem Webserver das Risiko eines Kompromisses erhöht. Es empfiehlt eng gefasste Anmeldedaten oder Validierung von einem separaten Server aus.

Die Challenge delegieren statt DNS-Schlüssel zu teilen

Let’s Encrypt folgt Standard-DNS-Abfragen für DNS-01-Validierung, daher können Sie CNAME- oder NS-Einträge verwenden, um den _acme-challenge‑Namen an eine andere Zone zu delegieren. Dadurch können Sie _acme-challenge.yourdomain.com auf eine Zone zeigen, die für Automatisierung reserviert ist, mit Anmeldeinformationen, die ausschließlich auf diese Zone beschränkt sind. Die Client-Unterstützung zum Folgen der Delegation variiert, bestätigen Sie daher Ihre Version und testen Sie mit einem Dry Run, bevor Sie sich darauf verlassen.

DNS-PERSIST-01: Eine neue Option zum Beobachten

Let’s Encrypt hat einen neuen Herausforderungs-Typ beschrieben, DNS-PERSIST-01, basierend auf einem IETF-Entwurf. Anstatt bei jeder Ausstellung ein frisches Token zu veröffentlichen, veröffentlichen Sie einen bestehenden TXT‑Eintrag unter _validation-persist.\u003cdomain\u003e, der die CA und Ihr spezifisches ACME-Konto benennt. Erneuerungen benötigen dann keine DNS-Änderungen, sodass DNS-Schreibzugriff nach der Einrichtung eingeschränkt werden kann.

Geltungsbereich und Lebensdauer werden durch optionale Parameter gesteuert. policy=wildcard weitet die Autorisierung auf Wildcard‑Zertifikate und passende Subdomains aus. persistUntil setzt einen Ablaufzeitstempel. Ohne Ablauf gilt die Autorisierung unbefristet; daher setzen Sie eine Überwachungs-Erinnerung. Da der Eintrag bestehen bleibt, wird der Schutz Ihres ACME‑Konto-Schlüssels zur zentralen Sorge. Das CA/Browser Forum hat die zugrunde liegende Validierungsmethode in Ballot SC-088v3 im Oktober 2025 genehmigt.

Let’s Encrypt hatte eine Produktionseinführung in Q2 2026 geplant, zunächst die Staging. Bestätigung, dass es in der Produktion live ist, konnte ich nicht finden. Community-Diskussionen bis Juli 2026 beschrieben den IETF-Entwurf als noch eng zu fassen und sagten, dass keine öffentliche CA eine Produktion implementiert habe. Betrachten Sie es als etwas, das man planen sollte, statt darauf zu vertrauen. Es kommt auch darauf an, ob Ihr Tunnelanbieter es unterstützt, nicht nur Ihr eigener ACME‑Client, denn bei einer verwalteten Domain hält der Anbieter das ACME‑Konto.

Eine praktische Checkliste für benutzerdefinierte Domains auf Tunneln

Vor dem 10. Februar 2027

1. Inventarisieren Sie jeden benutzerdefinierten Hostnamen und notieren Sie, wer ihn erneuert: der Anbieter, Ihr ACME‑Client oder eine Person.
2. Überprüfen Sie die DNS‑Einträge (das CNAME‑Ziel sowie _acme-challenge für Wildcards) gemäß den aktuellen Anweisungen Ihres Anbieters.
3. Prüfen Sie CAA‑Einträge, um sicherzustellen, dass sie der tatsächlich ausstellenden CA die Erlaubnis geben.
4. End-to-End‑Erneuerung testen. Führen Sie Ihren ACME‑Client gegen Let’s Encrypt‑Staging aus, das seit dem 14. Oktober 2026 Zertifikate mit 64 Tagen ausgestellt hat. Für verwaltete Domains bestätigen Sie, dass das Statusfeld oder Dashboard des Anbieters ein gesundes Zertifikat anzeigt.
5. Aktualisieren Sie alte Clients. Stellen Sie sicher, dass Ihr Client ACME‑Profile und ARI unterstützt, und entfernen Sie harte Erneuerungs-Offsets.

Laufend

1. Überwachen Sie das Live‑Zertifikat, nicht den Job. Führen Sie eine externe Prüfung durch, die sich mit jedem Hostnamen verbindet und Alarm schlägt, wenn die verbleibende Lebensdauer unter eine festgelegte Schwelle fällt, z. B. das letzte Drittel der Zertifikatslebensdauer. Ein Job mit Exit-Code 0 beweist nichts darüber, was am Edge bedient wird.
2. Alarmieren Sie bei DNS‑Drift. Eine geplante Prüfung, die sicherstellt, dass Ihre CNAMEs weiterhin auf die erwarteten Ziele auflösen, fängt die häufigsten Fehler bei verwalteten Zertifikaten ab.
3. Dokumentieren Sie die Eigentümerschaft. Wenn die Person, die die Domain eingerichtet hat, geht, sollte der Erneuerungsprozess nicht mit ihr gehen.
4. Üben Sie den Fehlerfall. Kennen Sie die manuellen Wiederherstellungsschritte (Datensatz neu erstellen, Neuausstellung auslösen, erneut hochladen), bevor Sie sie um 2 Uhr morgens benötigen.

Provider-Managed oder BYO? Ein schneller Entscheidungsleitfaden

Situation	Bessere Wahl
Standard-öffentliche Website, Webhooks, API auf einer benutzerdefinierten Domain	Provider-managed
Kleines Team, kein dedizierter Betrieb	Provider-managed
Vertragliche Anforderung für eine bestimmte CA oder Zertifikatstyp	BYO, mit automatisiertem Upload
Zertifikat von Partner verankert	BYO, mit Rotations-Runbook
Wildcard über viele Tunnels	Verwaltet mit DNS-01‑Delegation, oder BYO mit Automatisierung

Für die meisten Entwickler ist der verwaltete Weg richtig, und kürzere Lebensdauern stärken die Argumentation. Ein Anbieter, der kontinuierlich erneuert, macht den Job, den Sie sonst selbst skripten würden.

Wo Pro-Benutzerdefinierte Domains hineinpassen

Benutzerdefinierte Domains sind der Punkt, an dem ein Tunnel aufhört, eine Wegwerf-URL zu sein, und Teil Ihrer Infrastruktur wird: eine stabile Hostname für Webhooks, Demos, Staging oder eine Client‑Vorschau. Das macht Zertifikatsverwaltung zu einem Teil dessen, was Sie kaufen. Wenn Sie einen Pro-Custom-Domain-Plan von irgendeinem Tunnel-Anbieter evaluieren, fragen Sie:

• Werden Zertifikate automatisch ausgestellt und erneuert, und was passiert mit dem Hostnamen, wenn die Erneuerung fehlschlägt?
• Welche Herausforderungsarten und DNS-Einträge sind erforderlich, und können Sie Zertifikatsstatus und Ablauf in einem Dashboard oder via API sehen?
• Wird Wildcard-Unterstützung angeboten, und wie wird der _acme-challenge‑Eintrag behandelt?
• Kann ich mein eigenes Zertifikat verwenden, und ist Rotation über eine API steuerbar? Was kostet das?
• Wie benachrichtigt mich der Anbieter vor Ablauf, da Let’s Encrypts Erinnerungs-E-Mails nicht mehr existieren?

Ein Plan, der diese Fragen klar beantwortet, macht die Änderungen auf 64‑ und 45‑Tage zu einem Nicht-Ereignis.

Häufig gestellte Fragen

Ist die 64‑Tage‑Änderung eine Regel des CA/Browser Forum?
Nein. Die 64‑Tage‑Standardeinstellung ist ein eigener Zwischen-Schritt von Let’s Encrypt. Das aktuelle maximale Forum ist 200 Tage, das am 15. März 2027 auf 100 Tage sinkt.

Muss ich etwas tun, wenn mein Tunnel-Anbieter Zertifikate verwaltet?
In der Regel nichts außer, dass DNS-Einträge intakt bleiben und das Zertifikat überwacht wird, das Ihr Hostname tatsächlich bedient.

Werden Let’s Encrypt Zertifikate 47 Tage lang?
Nein. Let’s Encrypt plant 45 Tage ab dem 16. Februar 2028, leicht unter dem eventualen Forum-Maximum von 47 Tagen im Jahr 2029.

Was passiert mit meinen bestehenden 90‑Tage‑Zertifikaten?
Sie bleiben gültig, bis sie verfallen, und keines wird im Zuge der Änderung widerrufen. Let’s Encrypt erwartet, dass das letzte 90‑Tage‑Zertifikat am 11. Mai 2027 abläuft. Alles, was ab dem 10. Februar 2027 ausgestellt oder erneuert wird, erhält 64 Tage.

Gilt das für selbstsignierte oder private‑CA‑Zertifikate?
Der Zeitplan gilt für öffentlich vertrauenswürdige TLS‑Zertifikate, private PKI liegt außerhalb, auch wenn externe Aufrufer solchen Zertifikaten nicht vertrauen.

Kernpunkte

• Die wichtigsten Termine sind: 10. Februar 2027 (Let’s Encrypt wechselt auf 64 Tage), 15. März 2027 (100 Tage branchenweites Maximum), 16. Februar 2028 (Let’s Encrypt wechselt auf 45 Tage), und 15. März 2029 (47 Tage Maximum, 10‑Tage DCV-Wiederverwendung).
• Bei Tunneln ist das Risiko selten der Renewing‑Mechanismus des Anbieters. Es ist DNS‑Drift, abgelaufene Anmeldeinformationen und BYO‑Zertifikate, die niemand rotiert hat.
• Überwachen Sie das bereitgestellte Zertifikat extern, da Let’s Encrypts Erinnerungsemails im Juni 2025 eingestellt wurden.
• Ersetzen Sie hartkodierte Erneuerungs-Offsets durch ARI oder Erneuerungen bei etwa zwei Dritteln der Lebensdauer.
• Bevorzugen Sie verwaltete Zertifikate, es sei denn, eine echte Anforderung spricht dagegen, und automatisieren Sie jeden Schritt, wenn Sie BYO verwenden.

Quellen

• CA/Browser Forum Ballot SC-081v3 Zeitplan: SSLInsights, Odown, DNSimple
• Let’s Encrypt / ISRG: Decreasing Certificate Lifetimes to 45 Days
• Let’s Encrypt: 64-Day Certificate Lifetimes Coming Feb 2027
• Let’s Encrypt: DNS-PERSIST-01
• Let’s Encrypt community: DNS-PERSIST-01 deployment status and win-acme discussion
• Let’s Encrypt: Expiration Notification Service Has Ended
• Let’s Encrypt: Monitoring Service Options
• Let’s Encrypt: Challenge Types
• Let’s Encrypt: CAA
• ngrok: TLS certificates documentation
• Certbot 4.1.0 release (ARI support)
• IETF: ACME Renewal Information, RFC 9773