Seit dem 15. März 2026 dürfen öffentlich vertrauenswürdige SSL- und TLS-Zertifikate nur noch eine maximale Laufzeit von 200 Tagen haben. Ab dem 15. März 2027 sinkt diese Grenze auf 100 Tage, ab dem 15. März 2029 auf rund 47 Tage. Für Unternehmen mit großem Zertifikatsportfolio bedeutet das: Ein Betrieb mit 500 Zertifikaten kommt 2029 auf rund 3.900 Renewals pro Jahr. Manuelle Prozesse skalieren damit nicht mehr.
Drei Wege zur Automatisierung
In der Praxis haben sich drei Ansätze etabliert. Der erste ist die direkte ACME-Anbindung: Ein Client wie Certbot, acme.sh, cert-manager oder win-acme spricht direkt mit der Certificate Authority (CA), führt die Challenge aus und installiert das Zertifikat. Das funktioniert auf einzelnen Servern oder in homogenen Cluster-Umgebungen gut, stößt aber an Grenzen, sobald mehrere CAs parallel orchestriert werden müssen oder Compliance-Anforderungen über ein einfaches Logfile hinausgehen.
Der zweite Weg ist die REST-API-Integration bei einer kommerziellen CA oder einem Certificate Lifecycle Management (CLM)-Anbieter. Das bringt zentrales Inventar und Reporting, allerdings um den Preis einer anbieterspezifischen Implementierung. Ein CA-Wechsel erfordert dann den Neubau der Integration.
Der dritte Weg ist eine Plattformlösung als Abstraktionsschicht zwischen Endsystemen und CAs. Sie bietet sowohl ACME-Endpoints als auch REST-APIs und ermöglicht Multi-CA-Orchestrierung über eine einheitliche Schnittstelle. Diese Architektur bleibt auch bei einer Frequenzverdopplung 2027 und 2029 wirtschaftlich tragfähig.
Typische Schwachstellen im Eigenbau
Wer ACME-Clients selbst betreibt, trifft auf vier wiederkehrende Probleme. Erstens: DNS-01-Challenges erfordern Schreibrechte auf DNS-Zonen. Bei kompromittiertem Token kann ein Angreifer produktive DNS-Records manipulieren. Die elegante Lösung ist CNAME-Delegation auf eine dedizierte Validierungszone, sodass die Hauptzone strukturell nicht schreibend erreichbar ist.
Zweitens fehlt Standalone-Clients eine konsolidierte Sicht über das Gesamtportfolio. Spätestens bei ISO-27001- oder NIS2-Prüfungen wird das Problem sichtbar. Drittens erfordert der parallele Betrieb mehrerer CAs eigene Orchestrierungslogik, die bei jeder Strategieänderung angepasst werden muss. Viertens ist systemweites Alerting bei Renewal-Fehlern in Standard-Clients nicht vorgesehen, bei künftig sechs Renewals pro Jahr und Zertifikat wird jeder Ausfall aber zum produktiven Vorfall.
Vier Anforderungen für eine zukunftsfähige Architektur
Eine Renewal-Architektur, die bis 2029 trägt, muss Multi-CA-fähig sein, ohne jedes Mal neu implementiert werden zu müssen. Sie muss die DNS-Validierungspfade architektonisch so trennen, dass produktive Zonen nie schreibend berührt werden. Sie braucht eine entwicklerfreundliche REST-Alternative für Legacy-Anwendungen. Und sie muss ein zentrales Inventar mit revisionssicherem Audit-Trail bieten.
Parallel kündigt sich mit Post-Quantum-Kryptografie die nächste Anforderungswelle an. Das NIST hat im August 2024 die ersten Post-Quantum-Standards finalisiert. Wer 2026 nur auf die 200-Tage-Regel reagiert, baut Architekturen, die in zwei Jahren wieder nachjustiert werden müssen. Wer jetzt eine multi-CA-fähige Plattformlösung einführt, ist auf weitere Laufzeitverkürzungen und den Post-Quantum-Übergang besser vorbereitet.