SSL-Zertifikatsmanagement für MSPs und IT-Dienstleister Warum ACME allein bei SSL nicht mehr reicht

Seit März 2026 gelten für SSL/TLS-Zertifikate nur noch 200 Tage Laufzeit, 2027 sinkt sie auf 100 Tage, 2029 auf 47 Tage. Was das für Automatisierung, Governance und Betrieb bedeutet, und warum die Einführung eines ACME-Clients allein den Betriebsalltag nicht absichert.

Am 15. März 2026 ist eine Frist ausgelaufen, die viele Administratoren erst dann bemerkt haben, als die ersten Zertifikate mit ungewohnt kurzer Laufzeit im Monitoring auftauchten: Die maximale Gültigkeitsdauer öffentlicher SSL/TLS-Zertifikate ist von bisher 398 auf 200 Tage gesunken. Es ist der erste von drei Schritten, die das CA/Browser Forum mit Ballot SC-081v3 bereits im April 2025 einstimmig beschlossen hat: Ab dem 15. März 2027 sind es noch 100 Tage, ab dem 15. März 2029 nur noch 47 Tage. Parallel dazu sinkt die Wiederverwendbarkeit von Domain-Validierungsinformationen (DCV) auf denselben Zeiträumen, zuletzt auf gerade einmal zehn Tage.

Für Unternehmen mit einem übersichtlichen Zertifikatsbestand bedeutet das zunächst eine Verdopplung des Erneuerungsaufwands. Für MSPs, Reseller und IT-Dienstleister, die häufig mehrere hundert Zertifikate über verteilte Kundenumgebungen hinweg verwalten, ist es ein strukturelles Problem: Was bislang ein- bis zweimal jährlich als Wartungsaufgabe anfiel, wird ab 2027 zu einem quartalsweisen und ab 2029 zu einem monatlichen Dauerbetrieb. Manuelle Prozesse, Excel-Listen und Kalendererinnerungen, die bei Jahreszertifikaten noch tragfähig waren, werden bei 47 Tagen schlicht unrealistisch.

ACME ist die Antwort auf die Ausstellung – nicht auf das Problem

Die naheliegende Reaktion vieler IT-Abteilungen ist die Einführung von ACME (Automated Certificate Management Environment). Das ist richtig und notwendig – aber es greift zu kurz, wenn es als vollständige Lösung verstanden wird. ACME automatisiert zuverlässig die technische Ausstellung und Erneuerung eines Zertifikats. Es beantwortet jedoch nicht die Fragen, die im Betriebsalltag tatsächlich Ausfälle verursachen: Welche Zertifikate existieren überhaupt in welcher Umgebung? Wer ist verantwortlich, wenn eine Erneuerung fehlschlägt? Und wie wird sichergestellt, dass die Automatisierung selbst nicht zur neuen Schwachstelle wird?

Ein häufiges Missverständnis in Projekten ist daher: „Wir haben Certbot bzw. acme.sh im Einsatz, also ist SSL-Automatisierung erledigt.“ In der Praxis ist die ACME-Implementierung der Anfang eines Betriebsmodells, nicht dessen Abschluss.

Discovery und Inventar: Sie können nur schützen, was Sie kennen

Der häufigste Grund für ungeplante Zertifikatsausfälle ist nicht ein Fehler in der Automatisierung, sondern ein Zertifikat, von dessen Existenz niemand mehr wusste. Subdomains aus abgeschlossenen Projekten, interne Testsysteme, die produktiv weiterliefen, oder Zertifikate, die ein einzelner Mitarbeiter Jahre zuvor manuell bestellt hatte – all das sammelt sich in gewachsenen Infrastrukturen an.

Ein belastbares Zertifikatsmanagement beginnt deshalb mit einer vollständigen Bestandsaufnahme: Welche Zertifikate sind im Einsatz, auf welchen Systemen, mit welcher Erneuerungsmethode, und wer ist fachlich sowie technisch verantwortlich? Ohne dieses Inventar bleibt jede Automatisierung lückenhaft, weil sie nur die Zertifikate erfasst, die man bereits kennt.

DNS-01 und DCV: die unterschätzte Governance-Lücke

Für Wildcard-Zertifikate und verteilte Infrastrukturen ist die Domain-Validierung per DNS-01-Challenge der gängige Weg. Sie erfordert jedoch Schreibrechte auf die DNS-Zone – und genau hier entsteht ein Risiko, das in vielen Umsetzungen zu wenig Beachtung findet: Wird der Automatisierungsprozess mit vollen Schreibrechten auf die komplette DNS-Zone ausgestattet, kann ein kompromittiertes ACME-Client-System theoretisch beliebige DNS-Einträge manipulieren, nicht nur die für die Validierung notwendigen TXT-Records.

Sauberes DCV-Prozessdesign trennt deshalb die Rechte: über CNAME-Delegation auf eine dedizierte Validierungszone lässt sich die Automatisierung so beschränken, dass sie ausschließlich die für die Zertifikatsausstellung notwendigen Einträge setzen kann, ohne Zugriff auf die produktive Hauptzone zu erhalten. Das ist technisch kein großer Zusatzaufwand, wird in der Praxis aber häufig übersprungen, weil die schnellere Variante zunächst funktioniert – bis sie zum Sicherheitsproblem wird.

2023er Zertifikate – Warum erst der Aktivierungsstatus wirklich zählt

Ab Juni laufen Secure-Boot-Zertifikate ab – was Sie jetzt wissen müssen!

Monitoring, Eskalation, Audit-Trail: der Betriebsrahmen

Automatisierung reduziert die Häufigkeit menschlicher Eingriffe, sie ersetzt aber nicht die Notwendigkeit, den Prozess zu überwachen. Drei Elemente gehören in ein belastbares Betriebsmodell:

Monitoring, das rechtzeitig vor Ablauf und bei fehlgeschlagener Erneuerung alarmiert – nicht erst, wenn der Browser bereits eine Warnung anzeigt. Eskalationspfade, die definieren, wer bei einer fehlgeschlagenen automatischen Erneuerung informiert wird und wie schnell manuell nachgesteuert werden muss. Und ein Audit-Trail, der lückenlos dokumentiert, wann welches Zertifikat für welche Domain über welche Zertifizierungsstelle erneuert wurde – nicht als Selbstzweck, sondern weil genau dieser Nachweis bei Sicherheitsvorfällen und in regulierten Branchen zunehmend eingefordert wird.

CA-Flexibilität als Resilienzfaktor

Ein Aspekt, der in vielen Automatisierungsprojekten zu spät bedacht wird, ist die Abhängigkeit von einer einzelnen Zertifizierungsstelle. Fällt eine CA aus – sei es durch einen technischen Vorfall oder einen Vertrauensentzug durch einen Browserhersteller – muss ein Unternehmen kurzfristig auf eine andere CA umstellen können. Wer seine Automatisierung von Anfang an CA-agnostisch aufbaut, etwa über einen ACME-Client, der mit mehreren Zertifizierungsstellen kompatibel ist, reduziert dieses Risiko erheblich. Wer sich fest an eine einzelne CA-Implementierung bindet, riskiert im Ernstfall genau die Ausfallzeit, die die kürzeren Laufzeiten eigentlich vermeiden sollen.

Was IT-Verantwortliche jetzt konkret prüfen sollten

• Vollständiges Zertifikatsinventar erstellen, inklusive Schatten-IT und Alt-Systemen

• Erneuerungsprozess je Zertifikat klassifizieren: manuell, teilautomatisiert, vollautomatisiert

• DNS-Schreibrechte für DCV-Prozesse auf das technisch notwendige Minimum beschränken

• Monitoring und Eskalationspfade für fehlgeschlagene Erneuerungen definieren, bevor der Bedarf akut wird

• Audit-Trail-Fähigkeit prüfen: Kann im Bedarfsfall lückenlos nachgewiesen werden, wann und wie jedes Zertifikat erneuert wurde?

• CA-Abhängigkeit bewerten und wo sinnvoll auf Multi-CA-fähige Automatisierung umstellen

Die 200-Tage-Regelung ist mit diszipliniertem Prozessmanagement noch beherrschbar. Die 100-Tage-Stufe 2027 wird die meisten rein manuellen Ansätze überfordern. Wer die verbleibende Zeit nutzt, um Discovery, Governance und Betriebsprozesse jetzt zu etablieren, kommt an dem Punkt, an dem 47 Tage Realität werden, mit einem eingespielten System an – nicht mit einem Krisenprojekt.

Über den Autor

Martin Küchenthal ist Gründer und Geschäftsführer der Lemarit GmbH, einem international tätigen Full-Service-Anbieter für Corporate Domain Services und digitalen Markenschutz. Seit über 20 Jahren ist er in der Domainbranche aktiv und zählt zu den erfahrenen Experten für strategisches Domainmanagement und Markensicherheit im digitalen Raum.

Martin Küchenthal engagiert sich in führenden Branchenorganisationen und Gremien: Er ist unter anderem im Vorstand der Denic eG sowie der Brand Registry Group tätig und bringt seine Expertise in Verbände wie die INTA und den eco – Verband der Internetwirtschaft ein.

IT-Security in der Anwendungsbereitstellung

Warum Unternehmen ihre Application Delivery neu denken müssen

Sommerloch als Sicherheitsrisiko

Domain-Management in den Ferien ein Stresstest für MSPs?

(ID:50916256)