Flexible Automatisierung für SSL- und TLS-Zertifikate gesucht Die Laufzeit von SSL-Zertifikaten wird nur noch kürzer

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

FTAPI Software GmbH

Die Laufzeit öffentlich vertrauenswürdiger SSL-Zertifikate sank Anfang 2026 auf 200 Tage. Ab 2027 sollen rund 100 Tage folgen, ab 2029 etwa 47. Manuelle Renewal-Prozesse skalieren mit dieser Frequenz nicht mehr. Wer heute nur die nächste Stufe abarbeitet, baut Architekturen, die bald wieder bröckeln.

Seit dem 15. März 2026 dürfen öffentlich vertrauenswürdige SSL- und TLS-Zertifikate nur noch eine maximale Laufzeit von 200 Tagen haben. Die Entscheidung stammt vom CA/Browser Forum, der maßgeblichen Instanz für die Ausstellung öffentlicher Zertifikate. Ab dem 15. März 2027 sinkt die Laufzeit dann auf 100 Tage, ab dem 15. März 2029 auf etwa 47 Tage. Was nach einer tech­ni­schen Randnotiz klingt, ist für IT-Verantwortliche mit verteilten Domain-Portfolios eine operative Zäsur. Ein Unternehmen mit 500 Zertifikaten kommt 2029 auf rund 3.900 Renewals pro Jahr.

Der Markt reagiert darauf seit Jahren mit Standardisierung. Das ACME-Protokoll, kurz für Automatic Certificate Management Environment und definiert in RFC 8555, ist inzwischen De-facto-Standard. Auch kommerzielle Certificate Authorities (CAs) wie DigiCert, Sectigo, GlobalSign, SSL.com oder Entrust unterstützen ACME nativ. Die Frage „ob automatisieren" ist entschieden. Die spannende Frage lautet, welche Architektur die kommenden Verkürzungsstufen tatsächlich trägt.

Drei Wege durch die Automatisierungslandschaft

In der Praxis haben sich drei Pfade etabliert.

• Der Erste ist die direkte ACME-Anbindung. Ein Client wie Certbot, acme.sh, cert-manager oder win-acme spricht direkt mit der CA, führt die Challenge aus und installiert das Zertifikat. Das Modell funktioniert auf einzelnen Webservern oder in homogenen Cluster-Umgebungen exzellent. Es stößt aber an Grenzen, sobald mehrere CAs parallel orchestriert werden müssen oder die Compliance-Anforderungen über ein einfaches Logfile hinausgehen.

• Der zweite Pfad ist die REST-API-Integration bei einer kommerziellen CA oder einem CLM-Anbieter, also Certificate Lifecycle Management. Hier kommen Reporting und zentrales Inventar dazu, allerdings um den Preis einer anbieterspezifischen Implementierung. Wer den CA-Provider wechseln will, muss die Integration neu bauen.

• Der dritte Pfad ist die Plattform-Lösung. Sie liegt als Abstraktionsschicht zwischen Endsystemen und CAs, bietet sowohl ACME-Endpoints als auch REST-APIs an und ermöglicht Multi-CA-Orchestrierung über eine einheitliche Schnittstelle. Diese Architektur ist die Einzige, die auch bei einer Frequenzverdopplung 2027 und 2029 wirtschaftlich tragfähig bleibt.

Der unverzichtbare Standard

Deshalb sind TLS-Zertifikate für Domains unverzichtbar

Wo Eigenbau in der Praxis bricht

In über 20 Jahren Beratung internationaler Konzernkunden sehen wir vier wiederkehrende Bruchstellen, wenn ACME-Clients dauerhaft selbst betrieben werden.

Erstens das DNS-Update-Problem. In Enterprise-Umgebungen läuft die Mehrheit der Validierungen über die DNS-01-Challenge, weil sie Wildcard-Zertifikate erlaubt und auch für interne Hosts funktioniert. Das setzt voraus, dass der ACME-Client Schreibrechte auf eine DNS-Zone bekommt. Bei kompromittiertem Token kann ein Angreifer im schlimmsten Fall produktive DNS-Records manipulieren, nicht nur Validierungs-Einträge. Das BSI weist im IT-Grundschutz-Kompendium explizit auf die Risiken unzureichend abgesicherter DNS-Update-Pfade hin.

Zweitens das Inventar-Problem. Standalone-Clients wissen nur, was sie selbst beantragt haben. Eine konsolidierte Sicht über das Gesamtportfolio fehlt strukturell. Spätestens bei der ersten ISO-27001- oder NIS2-Prüfung wird das schmerzhaft. Excel-basierte Workarounds erfüllen die Anforderungen an revisionssichere Protokollierung in der Regel nicht.

Drittens das Multi-CA-Problem. Viele Unternehmen brauchen verschiedene CAs gleichzeitig. Let's Encrypt für unkritische DV-Zertifikate, DigiCert oder GlobalSign für OV- und EV-Anforderungen in regulierten Bereichen, dazu eine Backup-CA für Ausfallszenarien. Die Orchestrierungs-Logik dafür muss in eigenen Skripten implementiert und in jeder Client-Konfiguration nachgepflegt werden. Bei jeder Strategie-Änderung folgt eine Welle an Anpassungen.

Viertens das Eskalations-Problem. Wenn ein Renewal auf einem einzelnen Server scheitert, läuft die Fehlerbehandlung lokal. Ein systemweites Alerting mit definierten Eskalationspfaden ist in Standard-Clients nicht vorgesehen. Bei künftig sechs Renewals pro Jahr und Zertifikat wird jeder einzelne Ausfall zu einem produktiven Vorfall. Verizon dokumentiert im Data Breach Investigations Report seit Jahren, dass abgelaufene Zertifikate eine der häufigsten Ursachen für TLS-bezogene Produktivausfälle sind.

Sicherheitsarchitektur über CNAME-Delegation

Eine elegante Antwort auf das DNS-Update-Problem liegt in der CNAME-Delegation, in der Praxis oft als DCV-Zonen-Konzept bezeichnet. Statt dem ACME-Client Schreibrechte auf die produktive DNS-Zone zu geben, wird der „_acme-challenge"-Subnamespace per CNAME-Eintrag auf eine dedizierte Validierungs-Zone umgeleitet. Alle Validierungs-Einträge passieren ausschließlich dort. Selbst bei kompromittiertem API-Token bleibt die Hauptzone strukturell unerreichbar. DNSSEC-Signaturen, MX-Records, SPF und DKIM sind nicht manipulierbar.

Das Konzept ist nicht neu, wird aber in vielen Eigenbau-Setups übersprungen, weil es eine zusätzliche Initial-Konfiguration erfordert. Wer die Komplexität einmal investiert, gewinnt eine architektonische Sicherheitsebene, die in regulierten Branchen Voraussetzung für ernsthafte Zertifikatsautomatisierung ist. In Audits wird sie zunehmend explizit nachgefragt.

Vier Anforderungen an eine zukunftsfähige Architektur

Aus unserer Beratungspraxis muss eine Renewal-Architektur, die bis 2029 trägt, vier Anforderungen erfüllen.

Erstens Multi-CA-Fähigkeit ohne Re-Implementierung. Wer heute auf eine einzige CA setzt, hat morgen ein Cluster-Risiko. Die vergangenen zwei Jahre haben mehrfach gezeigt, dass selbst große CAs binnen Tagen Vertrauen verlieren können. Ein Wechsel muss ohne Endsystem-Anpassungen möglich sein.

Zweitens DCV-Erzwingung auf Architektur-Ebene. Wenn der Validierungs-Pfad strukturell so gebaut ist, dass produktive Zonen nie schreibend berührt werden, ist der größte Angriffsvektor neutralisiert.

Drittens eine API-Alternative für Setups ohne ACME. Legacy-Anwendungen, eigene CertOps-Tools oder Multi-Tenant-Plattformen lassen sich oft nicht mit Standard-Clients automatisieren. Eine entwicklerfreundliche REST-Schnittstelle macht den Unterschied zwischen vollständiger Automatisierung und einem Restbestand an manuellen Renewals.

Viertens zentrales Inventar mit Audit-Trail. Ohne lückenlose Protokollierung über alle Zertifikate hinweg sind ISO-27001, NIS2 und DORA nicht sauber erfüllbar.

Ausblick auf 100, 47 Tage und Post-Quantum

Mit der schrittweisen Verkürzung auf 100 und 47 Tage wird der operative Druck weiter steigen. Branchenbeobachter rechnen damit, dass spätestens ab 2027 manuelles Zertifikatsmanagement in größeren Umgebungen wirtschaftlich nicht mehr leistbar ist. Parallel kommen mit Post-Quantum-Kryptographie weitere Anforderungen. Das NIST hat im August 2024 die ersten Post-Quantum-Standards finalisiert, und etablierte CAs haben begonnen, Migrationspfade vorzubereiten.

Die Wahl der Architektur ist keine reine Tool-Entscheidung mehr, sondern eine strategische. Wer 2026 nur die 200-Tage-Regel adressiert, baut Architekturen, die in zwei Jahren wieder nachjustiert werden müssen. Wer jetzt eine multi-CA-fähige, DCV-erzwingende Plattform-Lösung einführt, ist auf die kommenden Verkürzungen und auf den Post-Quantum-Übergang wesentlich besser vorbereitet. Die einzige nicht-tragfähige Option ist, gar nichts zu tun.

Über den Autor: Thomas Küchenthal ist Gründer und Chief Technology Officer (CTO) der LEMARIT GmbH, einem Spezialisten für Corporate Domain Services, digitalen Markenschutz und Zertifikatsmanagement. Als Wirtschaftsinformatiker bringt Thomas Küchenthal technische Expertise aus mehr als 25 Jahren Branchen-Erfahrung mit. Der ausgewiesene DNS-Spezialist ist Mitglied des Technischen Beirats der DENIC eG und Verfechter einer sicheren Infrastruktur mit technisch durchdachten Lösungen.

(ID:50899350)