SaaSFort Ein Managed-Service-Provider mit fünfzig Kundendomains führt heute rund fünfzig Zertifikatserneuerungen pro Jahr durch. Lästig, machbar, und häufig noch über eine Mischung aus Tickets, Kalendererinnerungen und einer Person erledigt, die daran denkt.
Ab März 2027 werden daraus etwa zweihundert Erneuerungen pro Jahr. Ab März 2029 etwa vierhundert.
Der Aufwand wächst nicht linear mit der Absenkung. Er wächst schlechter, denn jede Erneuerung trägt Abstimmungskosten mit einem Kunden, dessen DNS Sie womöglich nicht kontrollieren.
Der Zeitplan
| Ab | Maximale Laufzeit | Erneuerungen je Domain und Jahr |
|---|---|---|
| 15.03.2026 | 200 Tage | ~2 |
| 15.03.2027 | 100 Tage | ~4 |
| 15.03.2029 | 47 Tage | ~8 |
Parallel sinkt die Wiederverwendung der Domain-Control-Validierung bis 2029 auf 10 Tage. Heute lässt sich eine Validierung über ein Jahr nutzen. Künftig weisen Sie die Kontrolle etwa dreimal im Monat je Domain neu nach.
Diese zweite Änderung erledigt manuelle Abläufe endgültig. Erneuerungen kann ein entschlossener Mensch bündeln. Eine Revalidierung im 10-Tage-Takt über einen ganzen Bestand nicht.
Warum MSPs es härter trifft
Ein SaaS-Unternehmen, das seine eigenen Zertifikate automatisiert, kontrolliert sein DNS, seinen Load Balancer und seine Deploy-Pipeline. Ein MSP hat drei zusätzliche Komplikationen.
Die DNS-Hoheit ist zersplittert. Manche Kunden delegieren das DNS an Sie. Andere belassen es beim Registrar, dessen Passwort die Büroleitung hat. ACME-DNS-01-Challenges brauchen einen programmatischen Weg, TXT-Einträge anzulegen, und “dem Kunden schreiben und warten” ist keiner.
Die Terminierungspunkte variieren. Ein Kunde sitzt hinter einem CDN, einer auf einer Appliance, ein dritter auf einem alten IIS, wo die Zertifikatsinstallation ein manueller Import ist.
Der Fehler ist kundensichtbar und wird Ihnen zugerechnet. Ein abgelaufenes Zertifikat auf der Kundenseite erzeugt eine Browser-Warnseite. Der Kunde wird das nicht als Änderung der Zertifikatslaufzeitpolitik beschreiben.
Die Migration in der Reihenfolge, die funktioniert
1. Zuerst das Inventar, auch das, was Sie nicht betreuen. Certificate-Transparency-Logs zeigen Subdomains auf Kundendomains, von denen Ihnen niemand erzählt hat. Marketing-Microsites und Kampagnenseiten sind die üblichen Funde, und es sind auch die, die unbemerkt ablaufen.
2. Sortieren Sie Kunden nach DNS-Kontrolle, nicht nach Größe. Kunden, deren DNS Sie halten, sind eine Migration innerhalb derselben Woche. Kunden mit DNS anderswo brauchen ein Delegationsgespräch, dessen Vorlauf sich in Wochen bemisst.
3. Nutzen Sie CNAME-Delegation für die hartnäckigen Fälle. Statt volle DNS-Kontrolle zu fordern, lassen Sie den Kunden einen dauerhaften CNAME von _acme-challenge.kundendomain.de auf eine von Ihnen kontrollierte Zone anlegen. Er ändert einmal etwas. Danach beantworten Sie jede künftige Challenge, ohne sein DNS je wieder anzufassen. Diese eine Technik löst den Großteil des Hoheitsproblems und ist die wirksamste Maßnahme dieser Liste.
4. Standardisieren Sie den Client. lego als einzelne Binärdatei für ungewöhnliche Umgebungen, cert-manager für alles auf Kubernetes, certbot dort, wo es schon läuft. Die Vielfalt zählt weniger als die Beseitigung von Hosts, auf denen die Installation ein manuelles Kopieren ist.
5. Lösen Sie über den Restanteil aus, nicht über Tage. Erneuern Sie bei einem Drittel Restlaufzeit. Sinkt die Obergrenze erneut, muss an Ihrer Konfiguration nichts überarbeitet werden. Jeder Bestand, der “30 Tage vor Ablauf” fest verdrahtet, muss noch zweimal angefasst werden.
6. Überwachen Sie extern, je Kunde. Eine still stehengebliebene Automatisierung ist der Fehlerfall, der wehtut, denn er entfernt den Menschen, dem es früher auffiel. Externe Ablaufprüfung je Kundendomain ist das Auffangnetz und zugleich ein Ergebnis, das Sie dem Kunden zeigen können.
Der geschäftliche Aspekt
Dies ist eine seltene compliance-nahe Änderung, die sich unmittelbar verkaufen lässt, denn der kundensichtbare Fehlerfall ist konkret und die Frist kommt von außen.
Für MSPs, die sich bereits über NIS2-Pflichten kleinerer Kunden positionieren, fügt sich der Zertifikatslebenszyklus natürlich in dasselbe Gespräch. Er ordnet sich NIS2 Artikel 21(2)(h) zu, und der Automatisierungsnachweis beantwortet die zunehmend folgende Frage nach Krypto-Agilität.
Er passt zudem zu den beiden anderen Transportänderungen von 2026, die über einen Bestand ebenso günstig zu liefern und ebenso unsichtbar sind, bis jemand fragt:
- MTA-STS und TLS-RPT für Kunden-Maildomains, wo die Verbreitung unter einem Prozent liegt und der Rollout zwei DNS-Einträge umfasst.
- Hybride Post-Quantum-Schlüsselvereinbarung, eine Konfigurationszeile je Terminierungspunkt.
Gemeinsam geliefert ergeben sie ein belastbares Paket “Transportsicherheits-Grundlinie 2026” mit angehängter Frist, das sich erheblich leichter verkauft als ein Härtungsprojekt mit offenem Umfang.
Was je Kunde monatlich zu prüfen ist
# Ausgestellte Laufzeit, nicht nur der Ablauf
echo | openssl s_client -connect kunde.example.de:443 2>/dev/null \
| openssl x509 -noout -dates
# Mailtransportrichtlinie und ihr Modus
dig +short TXT _mta-sts.kunde.example.de
curl -s https://mta-sts.kunde.example.de/.well-known/mta-sts.txt | grep -i mode
Jedes für mehr als 100 Tage ausgestellte Zertifikat gehört zu einer Domain, deren Erneuerungskadenz sich vor März 2027 ändern muss. Ihren Bestand nach dieser Zahl zu sortieren ergibt das Migrations-Backlog, bereits priorisiert.
Kurzfassung
Die entscheidende Frist ist der 15.03.2027, nicht 2029, denn bei 100 Tagen hört ein menschlicher Prozess auf zu funktionieren.
Beginnen Sie mit dem Inventar, sortieren Sie nach DNS-Hoheit, nutzen Sie CNAME-Delegation für Kunden, die ihre Zone nicht abgeben, und lösen Sie die Erneuerung über den Restanteil aus, damit die nächste Absenkung Sie nichts kostet.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.