Die neue Gültigkeitsdauer von TLS-Zertifikaten

Zertifikate sollen in Zukunft nur noch 47 Tage lang gültig sein, was eine Automatisierung unerlässlich macht. Vor diesem Vorschlag von Apple hatte sich Google für eine maximale Gültigkeitsdauer von 90 Tagen ausgesprochen, schloss sich jedoch praktisch sofort der Meinung von Apple an.

Der Zeitplan:

Die maximale Zertifikatsgültigkeitsdauer wird reduziert:

• • Zwischen heute und dem 15. März 2026 beträgt die maximale Gültigkeitsdauer eines TLS-Zertifikats 398 Tage.
  • Ab dem 15. März 2026 beträgt die maximale Gültigkeitsdauer von TLS-Zertifikaten 200 Tage.
  • Ab dem 15. März 2027 beträgt die maximale Gültigkeitsdauer von TLS-Zertifikaten 100 Tage.
  • Ab dem 15. März 2029 beträgt die maximale Gültigkeitsdauer von TLS-Zertifikaten 47 Tage.

Ich erkläre hier mit der Hilfe des Blogs von DigiCert, was der aktuelle Stand ist und wie wir als AVANTEC das Thema sehen und angehen.

47 Tage mögen willkürlich erscheinen, lassen sich aber einfach erklären:

• 200 Tage = maximale Anzahl von Tagen innerhalb von 6 Monaten (184 Tage) + die Hälfte eines Monats von 30 Tagen (15 Tage) + 1 Tag zusätzlich
• 100 Tage = maximale Anzahl von Tagen innerhalb von 3 Monaten (92 Tage) + ~ ein Viertel eines Monats von 30 Tagen (7 Tage) + 1 Tag zusätzlich
• 47 Tage = maximale Anzahl von Tagen innerhalb von 1 Monat (31 Tage) + die Hälfte eines Monats von 30 Tagen (15 Tage) + 1 Tag zusätzlich

Als Begründung führte Apple bei der Abstimmung zahlreiche Argumente auf, von denen eines besonders hervorzuheben ist. Das CA/B-Forum habe durch die stetige Verkürzung der maximalen Laufzeiten seit Jahren deutlich gemacht, dass Automatisierung für ein effektives Zertifikatslebenszyklusmanagement unerlässlich sei.

In der Abstimmung heisst es, dass kürzere Laufzeiten aus vielerlei Gründen notwendig sind:

• Die Informationen in Zertifikaten verlieren mit der Zeit an Vertrauenswürdigkeit, ein Problem, das nur durch häufige Revalidierung der Informationen verbessert werden kann.
• Der Widerruf mit CRLs und OCSP sei unzuverlässig. Tatsächlich ignorieren Browser diese Funktionen häufig. Es gibt viele Mängel des Widerrufs von Zertifikaten. Eine kürzere Laufzeit mindert die Auswirkungen der Verwendung potenziell kompromitierter Zertifikate.
• Im Jahr 2023 unterstrich das CA/B-Forum dann noch seine Auffassung, indem es kurzlebige Zertifikate ohne CRL oder OCSP genehmigte, die innerhalb von 7 Tagen ablaufen.

Zwei Punkte der Neuregelung könnten für Verwirrung sorgen:

1. Die Regeln ändern sich in den Jahren 2026, 2027 und 2029, wobei der Abstand zwischen den beiden letzten Jahren zwei Jahre beträgt.
2. Ab dem 15. März 2029 beträgt die maximale Lebensdauer eines TLS-Zertifikats 47 Tage, die maximale Wiederverwendung von Domainvalidierungsinformationen beträgt jedoch nur 10 Tage. Eine manuelle Revalidierung ist zwar technisch weiterhin möglich, wird aber garantiert zu Fehlern führen.

Die Zertifizierungsstelle und wir als AVANTEC werden von Kunden häufig gefragt, ob ihnen für häufigere Zertifikatserneuerungen höhere Kosten entstehen. Die Antwort ist nein. Es handelt sich um ein Jahresabonnement und wir haben festgestellt, dass Nutzer häufig ihre Zertifikate freiwillig schneller austauschen, sobald sie auf Automatisierung umsteigen.

Deshalb und da selbst die Änderungen an 100-Tage-Zertifikaten im Jahr 2027 mit manuellen Verfahren nicht mehr zu bewerkstelligen sein werden, erwarten wir einen schnellen Umstieg auf Automatisierung lange vor dem Inkrafttreten der Änderungen im Jahr 2029.

Die Aussage von Apple zur automatisierten Verwaltung des Zertifikatslebenszyklus ist richtig und etwas, worauf wir uns lange vorbereitet haben. DigiCert bietet mit dem Trust Lifecycle Manager und CertCentral verschiedene Automatisierungslösungen, einschliesslich Unterstützung des ACME-Protokolls. Das ACME-Protokoll von DigiCert ermöglicht die Automatisierung von DV-, OV- und EV-Zertifikaten und umfasst die Unterstützung von ACME Renewal Information (ARI). Zu ARI: «ARI is a related standard by which the server can suggest a schedule so the client knows to renew the certificate before it expires. Properly configured, ARI can instruct the client to renew if the certificate has been revoked, preventing an outage».

Viele Appliance- und Software-Hersteller verfügen noch über keinen automatischen Zertifikatsaustausch auf ihren Devices.

Da bleibt nicht mehr viel Zeit für eine brauchbare Anbindung. DigiCert zum Beispiel bietet bereits eine Variante mit DNS-Hosting und Automatisierung an. Von SwissSign wissen wir, dass sie daran arbeiten. Auf dem freien Markt ist „Let’s Encrypt“ schon länger mit Unterstützung von ACME oder anderen automatischen Updates präsent. Was mich hier stört, ist ein Ansatz, wo ich per Port 80 auf einen Webserver Zugriff für den automatischen Prozess zulassen muss. In der heutigen Zeit bin ich Fan von «alle Verbindung von mir weg» und nicht zu mir. Da ist mir dann die Überprüfung über einen DNS-TXT Hasheintrag viel sympathischer. Doch wie kann ich automatisch einen Eintrag in den TXT machen? Nicht alle Hoster erlauben dies. Wenn ich Zugriff auf den DNS habe, geht bei „Let’s Encrypt“ die sogenannte DNS-01-Challenge ebenfalls: https://letsencrypt.org/de/docs/challenge-types/#dns-01-challenge. Auch in diesem Bereich ist noch viel Potenzial nach oben zur Unterstützung. DigiCert macht es so, dass sie gleich die Domänen hosten und dadurch dies ‘intern’ machen können. Unter dem Kapitel Ergänzungen sehen wir, dass man nicht auf deren DNS gezwungen wird. Das ist noch recht sympathisch.

Dieses Thema würde einen eigenen Blog-Artikel benötigen. Vielleicht gibt es in naher Zukunft einen darüber 😉.

Gemäss https://docs.digicert.com/en/trust-lifecycle-manager/enroll-and-manage-certificates/enrollment-protocols-and-apis.html gibt es unterschiedliche Protokolle und APIs.
Bei welchen Herstellern findet man Unterstützung zu CMP, EST, SCEP und REST API? Oft ist leider bei ACME Ende der Fahnenstange.

Über das Thema „Managed Automation Lösungen“ finden wir eine Menge an Informationen bei DigiCert.

https://docs.digicert.com/en/trust-lifecycle-manager/automate-management-of-certificates/managed-automation-solution.html

Es überlässt uns mit viele offnen Fragen. Wir möchten möglichst alle Phasen des Zertifikatslebenszyklus automatisiert bekommen. Dies wird im Link genauer erläutert. Hier sehen wir noch viel Arbeit!

Zusammenfassend:

Da kommt eine grosse Welle auf uns zu und niemand will es so richtig wahrhaben. Wir bleiben aufmerksam und halten kontinuierlich nach möglichen Ansätzen Ausschau, damit wir in naher Zukunft bereit sind, passende Lösungen mit unseren Produkten umzusetzen.

Gerne möchte ich noch diese wichtige Information erwähnen.

Gemäss diesem Artikel wird die «Client Authentication EKU» bis am 1. Mai 2026 komplett entfernt. Die Vorgaben vom Google Chrome Root Program verlangen spezifische TLS-Root-Hierarchien, deren Policies aus Sicherheitsgründen «Client Authentication» und «Code Signing» nicht mehr unterstützen. Der erwähnte Link ist ein Dokument, in dem die aktuellsten Stati angepasst werden und auch die zeitlichen Schritte und das «Wieso» genauer beschrieben ist.

Was im Kontext von QC (Quantum Cryptography) resistenter Kryptografie gern erwähnt wird:
Man gewinnt auch etwas Crypto-Agilität für den Wechsel auf PQC-Algorithmen.

Es muss wohl nicht nur DNS bei DigiCert sein. Viele weitere werden unterstützt.