Redirect-Infrastruktur-Checkliste für die 45-Tage-Zertifikatsära

Die Laufzeiten von SSL-Zertifikaten werden demnächst halbiert. Let's Encrypt — das 60% aller Web-Zertifikate ermöglicht — wechselt von maximal 90 Tagen auf maximal 45 Tage. Der Vorschlag des CA/Browser Forum von Google geht in dieselbe Richtung. Die gesamte Zertifikatsbranche drängt als Sicherheitsstandard auf kürzere Laufzeiten, und der Zeitplan ist nicht länger nur theoretisch.

Für Teams, die Redirect-Infrastruktur über Hunderte oder Tausende von Domains hinweg verwalten, ist das keine kleine Anpassung — es ist ein operativer Verstärker. Was pro Domain und Jahr bisher 4 Erneuerungszyklen erforderte, wird bald 8 erfordern. Manuelle Prozesse, die bei 90 Tagen gerade so funktionierten, werden bei 45 Tagen vollständig scheitern.

Diese Checkliste wurde entwickelt, um Infrastrukturteams dabei zu helfen, ihre Einsatzbereitschaft in sechs kritischen Bereichen zu bewerten: Automatisierung, Monitoring, Erneuerungszeitpunkt, Benachrichtigungen, Wildcard-Strategie und Disaster Recovery. Jeder Abschnitt enthält eine Selbsteinschätzungsfrage und einen Zielzustand. Am Ende hast du ein klares Bild davon, wo deine Infrastruktur steht — und was sich ändern muss, bevor die Ära mit 45 Tagen beginnt.

1. Automatisierung: Zertifikatslebenszyklus ohne Zutun#

Die wichtigste Frage in deiner Bewertung der Einsatzbereitschaft: Werden alle ausgestellten und erneuerten Zertifikate ohne menschliches Eingreifen bereitgestellt?

Wenn die Antwort nicht eindeutig „Ja“ lautet, hast du ein Problem. Bei 45-Tage-Laufzeiten sind manuelle Zertifikatsprozesse schon in überraschend kleinen Maßstäben nicht mehr tragfähig. Ein Portfolio mit nur 50 Domains erfordert 400 Zertifikatsvorgänge pro Jahr — mehr als ein Vorgang pro Tag, jeden Tag, einschließlich Wochenenden und Feiertagen.

Aktueller Stand: Selbsteinschätzung — Wie geht dein Team heute mit der Bereitstellung von Zertifikaten um? Wenn die Antwort Kalendererinnerungen, Tabellenkalkulationen, manuelle CSR-Erstellung oder „jemand kümmert sich normalerweise darum“ beinhaltet, seid ihr in der manuellen Kategorie. Auch wenn du Teile des Workflows automatisiert hast: Prüfe, ob das Skript jede Domain abdeckt, jede Edge Case berücksichtigt und sich von jedem Ausfall erholt, ohne dass Menschen eskalieren müssen.

Zielzustand: Jeder Hostname in deiner Redirect-Infrastruktur stellt SSL automatisch über ACME bereit, sobald DNS konfiguriert ist. Zertilausstellung, Installation und Erneuerung erfolgen ohne menschliches Zutun. Das System erkennt neue Domains, validiert den Besitz über den DNS-01-Challenge, fordert das Zertifikat an, installiert es auf Edge-Nodes und plant die nächste Erneuerung — alles innerhalb von Sekunden, nachdem der Hostname hinzugefügt wurde.

Eine Redirect-Plattform, die SSL pro Hostname verwaltet — statt von dir zu verlangen, Zertifikate pro Server zu managen — schließt die Automatisierungslücke vollständig. Wenn DNS an die Plattform delegiert wird, wird SSL zu einer Eigenschaft der Infrastruktur, nicht zu einer Aufgabe auf der To-do-Liste von jemandem.

2. Monitoring: Wissen, bevor es kaputtgeht#

Fragen Sie sich: Haben Sie eine aktive Überwachung der Zertifikatsabläufe für alle Domains?

Monitoring ist das Sicherheitsnetz unterhalb der Automatisierung. Selbst mit ACME-basiertem Renewal kann etwas schiefgehen: Ein DNS-Eintrag ändert sich, ein Rate-Limit wird ausgelöst, eine CA hat einen Ausfall. Ohne Monitoring entdecken Sie abgelaufene Zertifikate auf die gleiche Weise wie Ihre Nutzer — über eine Browser-Warnung.

Aber Monitoring geht nicht nur darum, Ablaufdaten zu prüfen. Effektives Monitoring für Redirect-Infrastruktur bedeutet Health Checks von mehreren globalen Standorten, denn ein Zertifikat, das in Ihrem Büro gültig aussieht, kann an einem Nutzerstandort fehlschlagen — aufgrund von Verzögerungen bei der Edge-Propagation oder wegen CDN-Caching.

Aktueller Status-Check: Haben Sie ein Dashboard oder ein Benachrichtigungssystem, das die Zertifikatsablaufdaten für jede Domain anzeigt? Wird es in Echtzeit aktualisiert, wenn Zertifikate erneuert werden? Können Sie auf einen Blick sehen, welche Domains sich dem Ablauf nähern und welche bereits fehlgeschlagen sind?

Zielzustand: Kontinuierliche Überwachung der Zertifikatsgesundheit von mehreren globalen Edge-Standorten. Das System führt aktive TLS-Handshake-Checks durch — nicht nur Abfragen der Ablaufdaten — um zu verifizieren, dass jedes Zertifikat gültig, vertrauenswürdig und korrekt ausgeliefert wird. Das Dashboard zeigt den Echtzeitstatus für alle Domains. Das Monitoring ist automatisch: Wenn eine neue Hostname hinzugefügt wird, startet die Überwachung ohne Konfiguration.

3. Erneuerungszeitpunkt: Die Pufferzone#

Die Frage: Werden Erneuerungen früh genug angestoßen, um mehrtägige Ausfälle zu überstehen?

Bei 90-Tage-Zertifikaten bot die Erneuerung 7–14 Tage vor Ablauf einen komfortablen Puffer. Bei 45-Tage-Zertifikaten frisst derselbe Puffer 15–30 % der gesamten nutzbaren Lebensdauer des Zertifikats auf. Die Rechnung zwingt zu einem Trade-off: Erneuern Sie zu früh, und Sie wechseln Zertifikate ständig; erneuern Sie zu spät, und ein vorübergehender CA-Ausfall wird zu einem Produktionsvorfall.

Die Rate-Limits von Let’s Encrypt bringen noch eine weitere Dimension ins Spiel. Das Limit für „Duplicate Certificate“ erlaubt 5 Zertifikate pro Woche für denselben Satz von Hostnames, und das Limit „Certificates per Registered Domain“ ist auf 50 pro Woche gedeckelt. Bei 45-Tage-Erneuerungszyklen können große Domain-Portfolios diese Limits schneller erreichen als erwartet — insbesondere, wenn Sie zusätzlich Zertifikate für neue Domains bereitstellen.

Aktueller Status-Check: Wie groß ist Ihr Erneuerungsfenster? Wenn Ihr Team Zertifikate manuell erneuert, werden Erneuerungen mindestens 15 Tage vor Ablauf gestartet? Können Sie einen 5-tägigen CA-Ausfall überstehen, ohne dass irgendein Zertifikat abläuft? Haben Sie getestet, was passiert, wenn ein Erneuerungsversuch fehlschlägt — versucht das System automatisch erneut oder wartet es auf menschliches Eingreifen?

Zielzustand: Automatisierte Verlängerungen beginnen 30 Tage vor Ablauf mit einer Retry-Logik mit exponentiellem Backoff. Wenn der erste Versuch fehlschlägt, wiederholt das System die Verlängerung in zunehmenden Intervallen — 1 Stunde, 4 Stunden, 12 Stunden, 24 Stunden — bis die Verlängerung erfolgreich ist. Ratenlimits werden automatisch verfolgt und eingehalten. Das System kann einen mehrtägigen CA-Ausfall überstehen, ohne dass eine Domain ihr Ablaufdatum erreicht, weil die Verlängerungen früh genug gestartet werden, sodass es immer mindestens 15 Tage Puffer gibt.

4. Benachrichtigungen: Vorher, nicht nachher#

Die Frage: Werden die richtigen Personen benachrichtigt, bevor — nicht nachdem — ein Zertifikat abläuft?

Benachrichtigung ist der Unterschied zwischen einem Nicht-Ereignis und einem Vorfall. Wenn eine Zertifikatsverlängerung fehlschlägt, müssen zwei Dinge passieren: Das System versucht automatisch erneut (siehe Abschnitt 3), und die richtige Person weiß darüber. Wenn dein Monitoring ein abgelaufenes Zertifikat erkennt, ohne jemanden zu benachrichtigen, hast du trotzdem eine Lücke — du erfährst es nur schneller.

Benachrichtigungen sollten nach Schweregrad und Zielgruppe gestaffelt sein. Eine fehlgeschlagene Verlängerung, die 30 Minuten später erfolgreich nachholt, braucht kein Paging um 2 Uhr nachts — aber sie sollte in einem täglichen Digest erscheinen. Ein Zertifikat, das sich den finalen 72 Stunden nähert, ohne dass die Verlängerung erfolgreich war, ist eine kritische Benachrichtigung, die den On-Call-Ingenieur sofort erreichen muss.

Aktueller Zustand: Selbsteinschätzung: Wer wird benachrichtigt, wenn ein Zertifikat kurz vor dem Ablauf steht? Gibt es ein gestaffeltes Benachrichtigungssystem mit unterschiedlichen Schweregraden? Gehen Benachrichtigungen an die richtigen Kanäle (Slack, E-Mail, PagerDuty) je nach Dringlichkeit? Wenn die primäre On-Call-Person nicht verfügbar ist, wird die Benachrichtigung eskaliert?

Zielzustand: Drei-stufige Benachrichtigungen: Info (Verlängerung versucht, täglicher Digest), Warning (Verlängerung fehlgeschlagen, 7-Tage-Fenster, Slack/E-Mail), Critical (Verlängerung wiederholt fehlgeschlagen, 72-Stunden-Fenster, PagerDuty/On-Call-Eskalation). Benachrichtigungen enthalten den Domainnamen, das Ablaufdatum des Zertifikats, die Uhrzeit des letzten Verlängerungsversuchs und den Grund des Fehlschlags. Jede Domain im Portfolio ist abgedeckt — keine Ausnahmen, kein „wir überwachen das manuell“.

5. Wildcard-Zertifikate: Komfort vs. Risiko#

Die Frage: Werden Wildcard-Zertifikate korrekt behandelt oder schaffen sie einzelne Punkte des Versagens?

Wildcard-Zertifikate sind verlockend: Ein Zertifikat für *.example.com deckt jede Subdomain ab. Eine Verlängerung. Ein Ablaufdatum. Eine Sache, die man verwalten muss. Aber diese „eine Sache, die man verwalten muss“ ist auch eine Sache, die ausfallen kann — und wenn das passiert, gehen alle Subdomains gleichzeitig dunkel.

Für Redirect-Infrastruktur im Speziellen schaffen Wildcards ein weiteres Problem: DNS-01-Challenges für Wildcard-Zertifikate erfordern Zugriff auf die DNS-Zone der Apex-Domain. Wenn Ihre Redirect-Domains über mehrere Registrar- und DNS-Provider verteilt sind — was bei großen Portfolios üblich ist — wird die Verwaltung von DNS-01-Challenges für eine einzelne Wildcard deutlich komplexer als die Verwaltung von Zertifikaten pro Hostname.

Aktueller Stand – Selbsteinschätzung: Verwenden Sie Wildcard-Zertifikate für Redirect-Domains? Wenn das Wildcard-Zertifikat nicht verlängert werden kann, wie viele Domains sind betroffen? Haben Sie einen getesteten Rollback-Plan? Werden Wildcards vom selben Team verwaltet, das auch Zertifikate pro Domain betreut, oder sind es separate Prozesse mit unterschiedlichen Verantwortlichen?

Zielzustand: Zertifikate pro Hostname sind die Standardlösung. Jede Domain erhält ihr eigenes Zertifikat, das unabhängig bereitgestellt und verlängert wird. Das schafft Isolation: Ein Verlängerungsfehler bei einer Domain wirkt sich nicht auf andere aus. Wildcards werden nur dort eingesetzt, wo sie ausdrücklich benötigt werden (z. B. interne Services hinter einer gemeinsam genutzten Subdomain) — mit separatem Monitoring und separaten Alarmen sowie einer dokumentierten, getesteten Wiederherstellungsprozedur.

6. Disaster Recovery: Wenn die CA ausfällt#

Die Frage: Wenn Ihre Certificate Authority für 5 Tage nicht verfügbar ist — überleben Ihre Zertifikate?

Let’s Encrypt hat in der Vergangenheit mehrstündige Ausfälle erlebt. Bei 90-Tage-Zertifikatslaufzeiten war ein 2–3-tägiger Ausfall beherrschbar — die Zertifikate hatten noch genug verbleibende Gültigkeit, um ihn zu überstehen. Bei 45 Tagen kann derselbe Ausfall Zertifikate über ihr Verlängerungsfenster hinaus bringen, bevor die CA wieder online ist.

Disaster Recovery für SSL ist nicht nur eine Frage der CA. Es geht auch um DNS: Wenn Ihr DNS-Provider während eines DNS-01-Challenge-Zeitfensters einen Ausfall hat, schlägt die Challenge fehl und die Verlängerung wird blockiert. Es geht um die Edge-Propagation: Wenn sich ein erneuertes Zertifikat nicht rechtzeitig auf alle Edge-Knoten ausbreitet, bevor das alte abläuft, sehen manche Nutzer Fehler. Und es geht um die Verlängerungs-Pipeline selbst: Wenn Ihre Automatisierungsplattform einen Ausfall hat — werden Verlängerungen dann in die Warteschlange gestellt oder fallen sie durch?

Aktueller Stand – Selbsteinschätzung: Haben Sie modelliert, was während eines 5-tägigen CA-Ausfalls passiert? Was ist Ihr kürzestes Zertifikatsgültigkeitsfenster im gesamten Portfolio? Haben Sie eine Fallback-CA konfiguriert, oder sind alle Zertifikate an einen einzigen Provider gebunden? Kann Ihre DNS-Infrastruktur einen Ausfall während eines Challenge-Zeitfensters überstehen?

Zielzustand: Zertifikate werden früh genug erneuert, sodass jede Domain mindestens 15 Tage Pufferzeit behält — ausreichend, um einen realistischen CA-Ausfall zu überstehen. Die Verlängerungs-Pipeline ist robust: Wenn eine Verlängerung aufgrund der Nichtverfügbarkeit der CA fehlschlägt, versucht das System automatisch erneut, sobald die CA wieder verfügbar ist. Das Monitoring deckt die gesamte Abhängigkeitskette ab (DNS, CA, Edge-Propagation) — nicht nur die Ablaufdaten der Zertifikate. Fallback-CAs sind für kritische Domains konfiguriert, und das Team verfügt über ein dokumentiertes, getestetes Runbook, um Zertifikate bei längeren CA-Ausfällen manuell bereitzustellen.

Selbsteinschätzung: Bewerten Sie Ihre Einsatzbereitschaft#

Bewerten Sie Ihre Infrastruktur in den sechs untenstehenden Bereichen. Seien Sie ehrlich – eine niedrige Punktzahl ist kein Scheitern, sondern eine Roadmap.

Bewertung: 1 = Manuell / Keine Fähigkeit, 2 = Teilweise automatisiert / Lücken vorhanden, 3 = Überwiegend automatisiert / Geringe Lücken, 4 = Vollständig automatisiert / Keine Lücken, 5 = Vollständig automatisiert + getestet / Resilient

Ihre Gesamteinschätzung verstehen:

24-30: Sie sind bereit. Ihre Infrastruktur ist automatisiert, überwacht und robust. Halten Sie diesen Zustand aufrecht und testen Sie Ihre Wiederherstellungsverfahren regelmäßig.

18-23: Sie haben eine solide Grundlage, aber es bleiben Lücken. Setzen Sie zuerst auf die „Kritischen“ Bereiche — Automatisierung und der richtige Zeitpunkt für Erneuerungen sind die Verbesserungen mit dem höchsten ROI. Ein 45-Tage-Zeitrahmen wird Ihre aktuelle Einrichtung stark belasten.

12-17: Ihre Infrastruktur ist nicht bereit für 45-Tage-Zertifikate. Manuelle Prozesse, die bei 90 Tagen funktionieren, brechen bei 45 Tagen. Beginnen Sie mit der Automatisierung (Domain ①) — wenn Sie nur eine Sache beheben, dann machen Sie die automatische Bereitstellung und Erneuerung von Zertifikaten.

6-11: Sie sind einem hohen Risiko ausgesetzt. Jede Domain in Ihrem Portfolio ist anfällig für eine einzige verpasste Kalendererinnerung oder einen CA-Ausfall. Erwägen Sie den Wechsel zu einer Redirect-Plattform, die SSL-Automatisierung als Infrastruktur übernimmt — nicht als Aufgabe — um die Lücke schnell zu schließen.

Die Lücke wird nur noch größer#

Das Zeitalter der 45-Tage-Zertifikate ist keine zukünftige Möglichkeit – es ist eine Entwicklung der Branche mit einem klaren Zeitplan. Let’s Encrypt, das Zertifikate für über 360 Millionen Domains ausstellt, treibt diese Veränderung an. Der Vorschlag des CA/Browser Forums von Google verfolgt dieselbe Richtung. Der Standard bewegt sich, und die Lücke zwischen automatisierter und manueller Infrastruktur wird nur noch größer, je kürzer die Gültigkeitsdauer der Zertifikate wird.

Die Teams, die jetzt automatisieren, werden die Umstellung nicht spüren. Sie werden sehen, wie ihre Dashboards die Erneuerungen termingerecht abschließen – 30 Tage früher, jedes Mal, für jede Domain – während andere hektisch versuchen, ihre Tabellen zu aktualisieren. Die Checkliste oben ist nicht nur ein Bewertungsinstrument. Sie ist eine Roadmap für eine Infrastruktur, die für jede Zertifikatslaufzeit bereit ist, auf die sich die Branche einigt – 45 Tage, 30 Tage oder kürzer.

Bewerten Sie Ihre Infrastruktur. Schließen Sie die Lücken. Das Zeitalter der 45-Tage-Zertifikate kommt – Ihre Redirect-Domains sollten das Letzte sein, worüber Sie sich Sorgen machen.