← Alle Beiträge
· Claus Lindemann

PQC Quick Win 10: Zertifikatslaufzeiten kürzen – Krypto-Agilität in der Praxis

ZertifikatslaufzeitKrypto-AgilitätACMEAutomatisierungCABFQuick Win

PQC Quick Win 10: Zertifikatslaufzeiten kürzen – Krypto-Agilität in der Praxis

Kürzere Zertifikatslaufzeiten klingen auf den ersten Blick nach reinem Compliance-Thema: Das CA/Browser Forum hat mit Ballot SC-081 einen Stufenplan beschlossen, der die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate schrittweise auf am Ende 47 Tage senkt. Wer das nur als Pflichtprogramm betrachtet, übersieht den eigentlichen Wert: Wer seine Zertifikate ohnehin im 47-Tage-Rhythmus austauscht, hat die wichtigste Voraussetzung für Krypto-Agilität bereits geschaffen. Quick Win 10 macht aus der Pflicht ein Werkzeug.

Warum kurze Laufzeiten der entscheidende PQC-Hebel sind

Die spätere PQC-Migration besteht in vielen Schritten aus genau einer Operation: ein Zertifikat (oder ein Schlüsselpaar) wird gegen ein neues, post-quanten-resistentes ausgetauscht. Wer diese Operation nur einmal im Jahr durchläuft, übt sie nie ein – jede Umstellung ist ein Einzelereignis mit hohem Risiko. Wer sie alle 47 Tage durchläuft, hat eine geprobte Routine: Werkzeuge, Monitoring, Rollback, alles steht.

Das ist Krypto-Agilität nicht als Architekturvision, sondern als Betriebspraxis. Im PQC-Ernstfall macht es den Unterschied, ob die Umstellung “in den nächsten Tagen” passiert oder “in den nächsten Monaten”.

Was Ballot SC-081 konkret vorsieht

Der CABF-Ballot definiert einen Stufenplan, der über mehrere Jahre läuft und am Ende bei 47 Tagen maximaler Gültigkeit für öffentliche TLS-Zertifikate landet. Parallel verkürzt der Plan auch die Wiederverwendungsdauer der Domain-Validierungsdaten. Wer öffentlich vertrauenswürdige Zertifikate einsetzt, muss sich mit diesen Schritten ohnehin beschäftigen – also bietet sich an, den Schritt sofort vollständig zu gehen, statt ihn jeweils minimal mitzumachen.

Für interne CAs gilt der Ballot nicht. Aber Sie sind frei, sich an derselben Logik zu orientieren: Mit kurzen internen Laufzeiten verlassen Sie sich nicht auf einen jährlichen Erneuerungsritus, sondern auf einen funktionierenden Prozess.

Welche Stufen Sie in der eigenen Landschaft gehen

Realistisch sind drei Stufen über die nächsten Quartale:

  • Stufe 1: Automatisierungsgrad anheben. Mit den Ergebnissen aus Quick Win 9 wissen Sie, welche Zertifikatsklassen heute manuell erneuert werden. Ziel ist, jede Klasse mindestens auf “halbautomatisch” zu heben – ACME, Intune-Profil, EJBCA-Schnittstelle, je nach Klasse.
  • Stufe 2: Laufzeit halbieren. Wer heute auf 12-Monats-Laufzeiten arbeitet, geht zunächst auf sechs Monate. Wer auf zwei Jahren steht, geht auf ein Jahr. Wichtig: Die Halbierung erfolgt zusammen mit der Automatisierung, nicht ohne sie.
  • Stufe 3: 90-Tage-Standard. Mit ACME-Strecken (Let’s Encrypt et al.) ist der 90-Tage-Standard längst Routine. In dieser Stufe wird er zur Norm für möglichst viele Zertifikatsklassen. Der CABF-Endpunkt von 47 Tagen ist dann die letzte Verkürzung, die kaum noch Mehrarbeit bedeutet.

Wo Sie automatisieren – und wie

Die wichtigsten Werkzeuge im KMU-Stack:

  • ACME (RFC 8555) für öffentlich vertrauenswürdige Webserver-Zertifikate (Let’s Encrypt, ZeroSSL, BuyPass, kommerzielle CAs mit ACME-Schnittstelle). Webserver wie nginx (mit acme.sh), Caddy (eingebaut), Traefik (eingebaut) erledigen den Rest.
  • MDM-/Endpoint-Profile für Client- und Geräte-Zertifikate – Intune SCEP/PKCS, Jamf, Workspace ONE.
  • EJBCA / ADCS REST-Schnittstellen für eigene CA-Strecken, z. B. in CI/CD-Pipelines, Containern, Kubernetes-Ingress (cert-manager).
  • Code-Signing über HSM mit kurzer Lebensdauer – die Signaturen selbst bleiben länger gültig (Zeitstempel sei Dank), die ausstellenden Zertifikate werden häufiger gewechselt.

Wichtig: Automatisierung darf nie auf “vergessenes Stück Skript auf einem Admin-Laptop” enden. Erneuerung gehört in eine kontrollierte, dokumentierte Pipeline mit Monitoring.

Was bei kurzen Laufzeiten zwingend dazugehört

  • Monitoring der Erneuerungen: Wer kürzer rotiert, hat mehr Termine, an denen etwas schiefgehen kann. Eine Alarmierung “Zertifikat läuft in 7 Tagen ab” muss verlässlich greifen.
  • CT-Log-Überwachung: Wer kurze Laufzeiten fährt, will sicher sein, dass nur die vorgesehenen Zertifikate ausgestellt werden. CT-Log-Monitoring (z. B. via crt.sh-Subscriptions) ist hier Standard.
  • Klare Owner pro Klasse: Aus der Inventur in Quick Win 9 wird in dieser Stufe ein Betriebsmodell.

Was Sie diese Woche tun sollten

  • Aus der PKI-Inventur (Quick Win 9) die Klassen herausziehen, die heute am längsten laufen und am wenigsten automatisiert sind.
  • Pro Klasse einen Pilot-Endpunkt auswählen und auf halbe Laufzeit + Automatisierung umstellen.
  • Monitoring scharfschalten – sowohl auf Ablauf als auch auf CT-Log-Veränderungen.
  • Ergebnis im IT-Team und in der Geschäftsführung als das benennen, was es ist: ein Schritt Krypto-Agilität, nicht nur eine Compliance-Pflicht.
  • Wiedervorlage in einem Quartal: weitere Klassen auf die kürzere Laufzeit ziehen.

Fazit

Der Schritt zu kürzeren Zertifikatslaufzeiten verbindet zwei Welten, die in vielen KMU unverbunden nebeneinanderstehen: Compliance (“wir müssen ohnehin auf 47 Tage”) und Krypto-Agilität (“wir wollen jederzeit Verfahren wechseln können”). Wer beide Linien zusammenführt, hat keinen Migrations-Stress, wenn der PQC-Wechsel ansteht – er hat einen geprobten Prozess. Das ist der vielleicht stärkste einzelne PQC-Hebel, den ein Mittelständler heute betätigen kann.

Quellen

pqconsult: Ihre Partner bei der PQC-Migration

Wir helfen Ihnen, Ihre Zertifikatslandschaft Klasse für Klasse auf kurze, automatisierte Laufzeiten zu heben – als praktischen Einstieg in eine Krypto-Agilität, die im PQC-Ernstfall trägt. Sprechen Sie uns an.

Haben Sie Fragen zu diesem Thema?

Kontakt aufnehmen