PQC- und 47-Tage-TLS-Zertifikate: Warum zwei Migrationen zusammenlaufen

Kurz gesagt: Zwei unabhängige PKI-Transformationen laufen gleichzeitig auf derselben Infrastruktur auf. Der CA/Browser Forum-Abstimmungsantrag SC-081v3 verkürzt die maximale Gültigkeitsdauer von TLS-Zertifikaten schrittweise: 200 Tage bis März 2026, 100 Tage bis März 2027 und 47 Tage bis März 2029. Die vollständige Automatisierung der Zertifikatsausstellung wird damit zur Grundvoraussetzung und nicht zur Optimierung. Die PQC-Migration, die im selben Zeitraum stattfindet, vergrößert die Zertifikats- und Signaturgrößen im Vergleich zu klassischen Algorithmen um das 15- bis 50-Fache und führt neue Kompatibilitätsanforderungen für dieselbe Zertifikatsinfrastruktur ein. Keine der beiden Transformationen wurde mit Blick auf die andere konzipiert. Da sie jedoch auf derselben CA-Hierarchie, denselben Automatisierungstools und demselben Zertifikatbestand basieren, birgt die separate Planung – nicht die gemeinsame – Risiken.

Die meisten PKI-Teams verfolgen diese als zwei separate Initiativen: ein Projekt zur Einhaltung der Zertifikatslebensdauer und ein Projekt zur Quantenfähigkeit. Diese werden von sich überschneidenden, aber nicht identischen Stakeholdern und in sich überschneidenden, aber nicht identischen Zeiträumen durchgeführt. Diese Trennung ist ein Fehler. Jedes ab sofort ausgestellte Zertifikat muss beide Anforderungen gleichzeitig erfüllen, wodurch sich die beiden Initiativen nahezu das gesamte tatsächliche Ausführungsrisiko teilen.

Wichtige Erkenntnisse

• Der CA/Browser Forum-Abstimmungsantrag SC-081v3 sieht eine stufenweise Reduzierung der maximalen Gültigkeitsdauer von TLS-Zertifikaten vor: 200 Tage bis März 2026, 100 Tage bis März 2027 und 47 Tage bis März 2029.
• Bei 47-Tage-Zertifikaten ist eine vollständige Automatisierung der Ausstellung und Verlängerung zwingend erforderlich; eine manuelle Zertifikatsverwaltung ist bei dieser Verlängerungsfrequenz betrieblich nicht mehr durchführbar.
• PQC-Zertifikate sind je nach Algorithmus und Parametersatz etwa 15 bis 50 Mal größer als klassische Zertifikate – eine Größensteigerung, für die die auf klassische Zertifikate ausgelegte Automatisierungsinfrastruktur nicht ausgelegt ist.
• Der Konvergenzpunkt ist die Häufigkeit der Erneuerungen multipliziert mit der Zertifikatsgröße: Die Automatisierungsinfrastruktur muss nun sowohl deutlich häufigere Erneuerungen als auch deutlich größere Datenmengen gleichzeitig bewältigen können.
• Wenn man diese als eine kombinierte Infrastrukturinvestition und nicht als zwei separate Projekte behandelt, vermeidet man eine doppelte Gebäudeautomation.

Der 47-Tage-Zeitplan

Die Abstimmung des CA/Browser Forums (SC-081v3) sieht eine stufenweise Reduzierung der maximalen Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate vor: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Jede Stufe erhöht den Aufwand für die Ausstellungs- und Erneuerungsinfrastruktur, da ein 47-Tage-Zertifikat etwa 7.7 Mal pro Jahr erneuert werden muss, im Vergleich zu nur einmal pro Jahr für ein 398-Tage-Zertifikat gemäß der vorherigen Höchstgültigkeitsregelung. Bei dieser Häufigkeit stellt die manuelle Zertifikatsverwaltung kein Compliance-Risiko dar, sondern ist für jede Organisation, die mehr als nur wenige Zertifikate verwaltet, praktisch unmöglich.

Das PQC-Größenproblem, auf der gleichen Zeitlinie

PQC-Zertifikate enthalten deutlich größere öffentliche Schlüssel und Signaturen als ihre klassischen Pendants. Eine ML-DSA-65-Signatur umfasst beispielsweise etwa 3,309 Byte gegenüber 64 Byte bei ECDSA. Diese Größensteigerung wird in unserem Leitfaden zu den FIPS-Standards 203, 204 und 205 ausführlich erläutert . Dieses Wachstum wirkt sich entlang der Zertifikatskette aus und beeinflusst direkt die Größe des TLS-Handshakes, den Speicherbedarf der Zertifikate und die Validierungszeit – also genau die Infrastruktur, die auch das erhöhte Ausstellungsvolumen aufgrund der 47-tägigen Erneuerungsfrequenz bewältigen muss.

Wo die beiden Transformationen tatsächlich zusammenlaufen

Die Konvergenz ist nicht konzeptioneller, sondern infrastruktureller Natur. Beide Transformationen basieren auf derselben Registrierungsautomatisierung (ACME, EST, SCEP), derselben CA-Hierarchie und derselben Zertifikatsverwaltungsplattform. Eine Automatisierungspipeline, die für die Verarbeitung klassischer Zertifikate mit jährlicher Erneuerung ausgelegt ist, muss gleichzeitig PQC-Zertifikate mit nahezu wöchentlicher Erneuerung verarbeiten können – eine kombinierte Anforderung, die deutlich höher ist als die jeder Transformation für sich. Auch die Test- und Validierungsinfrastruktur steht vor dieser Herausforderung: Das Registrierungsprotokoll, das die Konformität Ihres 47-Tage-Zertifikats prüft, muss mit den tatsächlichen Zertifikatsgrößen der PQC-Migration getestet werden, nicht mit den kleineren klassischen Zertifikaten von heute. Andernfalls validiert der Test den falschen zukünftigen Zustand.

Warum die separate Planung Risiken schafft, anstatt sie zu reduzieren

Organisationen, die diese beiden Aspekte als separate Initiativen verfolgen, bauen ihre Automatisierungsinfrastruktur typischerweise zweimal auf: einmal für kurzlebige klassische Zertifikate und dann erneut, wenn PQC-Zertifikate eingeführt werden und sich die Annahmen zur Größe des ersten Aufbaus als falsch erweisen. Schlimmer noch: Ein Team, das sich ausschließlich auf die Einhaltung der 47-Tage-Frist konzentriert, implementiert möglicherweise eine Automatisierungsinfrastruktur, die nicht für die Nutzdaten von PQC-Zertifikaten ausgelegt ist. Dies führt zu einem zweiten, vermeidbaren Sanierungsprojekt mit einem engen Zeitplan, sobald die PQC-Migration ansteht. Die Kombination beider Aspekte in einer einzigen Infrastrukturinvestition, die von Anfang an für beide Anforderungen dimensioniert ist, vermeidet diesen zusätzlichen Aufwand vollständig.

Was wir tatsächlich empfehlen würden

Behandeln Sie die Einhaltung der Zertifikatslebensdauer und die PQC-Bereitschaft als eine einzige Infrastrukturinvestition und nicht als zwei separate Projekte mit separaten Budgets und Zeitplänen. Dimensionieren Sie jede neue Automatisierungsinfrastruktur jetzt für die PQC-Zertifikatsnutzdaten, auch wenn die Einführung der PQC-Zertifikate erst später erfolgt. Anstatt für die heutigen klassischen Zertifikatsgrößen zu entwickeln und diese nach der Einführung von PQC anzupassen, sollten Sie die Automatisierung der Registrierung gleichzeitig anhand beider Dimensionen testen: der tatsächlichen Erneuerungshäufigkeit und der tatsächlichen Zertifikatsgröße. Anstatt jede Anforderung isoliert anhand der jeweils einfacheren Vergleichsgrundlage zu validieren, sollten Sie die Anforderungen nicht einzeln prüfen.

Wie Verschlüsselungsberatung helfen kann

CertSecure Manager ist so konzipiert, dass er beide Dimensionen dieser Konvergenz von einer einzigen Plattform aus bewältigen kann: automatisierte Ausstellung und Erneuerung im 47-Tage-Rhythmus, ausgelegt für klassische, hybride und reine PQC-Zertifikatnutzlasten, sodass die Infrastrukturinvestition beide Anforderungen abdeckt und nicht neu aufgebaut werden muss, wenn die zweite Anforderung hinzukommt.

Unser PQC Advisory Services- Plan sieht die Einhaltung der Zertifikatslaufzeit und die PQC-Bereitschaft als kombiniertes Programm vor, wobei die Investitionen in die gemeinsame Automatisierungsinfrastruktur sowohl an den gestaffelten Fristen des CA/Browser Forums als auch an Ihrem eigenen PQC-Migrationszeitplan ausgerichtet werden.

Ein Infrastrukturproblem, nicht zwei

Die Komprimierung der Zertifikatslebensdauer und die PQC-Migration wurden von verschiedenen Normungsgremien aus unterschiedlichen Gründen entwickelt und laufen dennoch nahezu zeitgleich auf derselben Registrierungsautomatisierung, derselben CA-Hierarchie und derselben Zertifikatsverwaltungsplattform. Sie als zwei separate Initiativen zu planen, bedeutet, dieselbe Automatisierungsinfrastruktur zweimal und einmal falsch dimensioniert aufzubauen. Die gemeinsame Planung, bei der von Anfang an sowohl die 47-tägige Erneuerungsfrequenz als auch die PQC-Zertifikatnutzdaten berücksichtigt werden, reduziert das kombinierte Risiko und die Kosten beider Transformationen, die gleichzeitig auf derselben Infrastruktur implementiert werden.

Häufig gestellte Fragen

Welche gestaffelten Reduzierungen der TLS-Zertifikatslebensdauer sieht das CA/Browser-Forum vor?

200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029, gemäß Wahlzettel SC-081v3.

Warum macht die 47-tägige Gültigkeitsdauer des Zertifikats die Automatisierung obligatorisch und nicht optional?

Bei einer maximalen Gültigkeitsdauer von 47 Tagen müssen Zertifikate etwa 7.7 Mal pro Jahr erneuert werden, anstatt nur einmal. Die manuelle Zertifikatsverwaltung ist in dieser Häufigkeit für jede Organisation, die mehr als eine Handvoll Zertifikate verwaltet, betrieblich nicht praktikabel.

Warum sollten die Einhaltung der Zertifikatslaufzeit und die PQC-Bereitschaft gemeinsam geplant werden?

Da beide auf derselben Plattform für Registrierungsautomatisierung, CA-Hierarchie und Zertifikatsverwaltung basieren, birgt eine separate Planung das Risiko, eine Automatisierungsinfrastruktur aufzubauen, die nur für klassische Zertifikate ausgelegt ist und dann für PQC-Zertifikate mit deutlich größeren Datenmengen neu aufgebaut werden muss.

Um wie viel größer sind PQC-Zertifikate im Vergleich zu klassischen Zertifikaten?

Je nach Algorithmus und Parametersatz sind die Signaturen etwa 15 bis 50 Mal größer; eine ML-DSA-65-Signatur umfasst etwa 3,309 Bytes, im Vergleich zu etwa 64 Bytes bei ECDSA.

Sollte die Automatisierung der Registrierung anhand der heutigen Zertifikatsgrößen oder zukünftiger PQC-Größen getestet werden?

Zukünftige PQC-Größen, selbst wenn die Ausstellung von PQC-Zertifikaten erst später erfolgt. Tests, die sich ausschließlich auf die heute üblichen kleineren Zertifikate beschränken, validieren eine Infrastruktur, die nach der Einführung größerer PQC-Zertifikate überarbeitet werden muss.