Bereiten Sie sich auf die Verkürzung der Zertifikatsgültigkeit vor

Die maximale Gültigkeit eines öffentlichen TLS-Zertifikats wird in den kommenden Jahren schrittweise verkürzt:

• Bis zum 15. März 2026 beträgt die maximale Gültigkeit eines TLS-Zertifikats 398 Tage.
• Ab dem 15. März 2026 beträgt die maximale Gültigkeit eines TLS-Zertifikats 200 Tage.
• Ab dem 15. März 2027 beträgt die maximale Gültigkeit eines TLS-Zertifikats 100 Tage.
• Ab dem 15. März 2029 beträgt die maximale Gültigkeit eines TLS-Zertifikats 47 Tage.

Auch die maximale Dauer, für die Verifizierungsinformationen zu Domänen und IP-Adressen wiederverwendet werden können, wird verkürzt:

• Bis zum 15. März 2026 beträgt die maximale Dauer der Wiederverwendung von Verifizierungsdaten 398 Tage.
• Ab dem 15. März 2026 beträgt die maximale Dauer der Wiederverwendung von Verifizierungsdaten 200 Tage.
• Ab dem 15. März 2027 beträgt die maximale Dauer der Wiederverwendung von Verifizierungsdaten 100 Tage.
• Ab dem 15. März 2029 beträgt die maximale Dauer der Wiederverwendung von Verifizierungsdaten 10 Tage.

Die maximale Gültigkeit des Zertifikats bestimmt die maximale Anzahl von Tagen, für die ein Zertifikat als gültig angesehen wird. Damit eine Zertifizierungsstelle (CA) ein Zertifikat ausstellen kann, muss sie überprüfen, dass der Antragsteller tatsächlich die Kontrolle über die im Zertifikat angegebene Domäne oder IP-Adresse hat.

Wenn Sie derzeit ein Zertifikat haben und es einmal im Jahr gemäß den aktuellen Regeln erneuern, erfolgt bei jeder Erneuerung eine Überprüfung der Kontrolle über die Domäne.

Was aber, wenn Sie das Zertifikat vor der Erneuerung ersetzen müssen – beispielsweise wenn der private Schlüssel kompromittiert wurde? In einem solchen Fall kann die CA die Überprüfung, die bei der letzten Erneuerung erfolgte, erneut verwenden, sodass Sie eine erneute Validierung vermeiden können. Dies ist möglich, weil die maximale Dauer der Wiederverwendung der Domänenverifizierung noch nicht abgelaufen ist.

Die grundlegenden Anforderungen (sogenannte Baseline Requirements, also die Regeln des CA/B Forum für die Ausstellung von Zertifikaten) definierten immer beide Zeitlimits, aber sie waren im Allgemeinen auf den gleichen Wert festgelegt.

Die Änderung der letzten Phase neuer Regeln – bei der die maximale Gültigkeit des Zertifikats auf 47 Tage gesenkt wird, während die Domänenverifizierung nur für eine Dauer von 10 Tagen wiederverwendbar ist – zielt darauf ab, dass das Überprüfen häufiger erfolgt. Das CA/B Forum geht davon aus, dass Informationen zur Kontrolle über eine Domäne sehr schnell veralten.

Der gleiche Zeitrahmen für die Domänenverifizierung gilt auch für OV- und EV-Zertifikate. Es wird schrittweise erforderlich sein, die Domänenverifizierung in denselben Intervallen wie bei DV-Zertifikaten durchzuführen, das heißt alle 200 / 100 / 10 Tage.

Die übrigen in OV- und EV-Zertifikaten enthaltenen Informationen (z. B. der Name und die Adresse der Organisation) müssen jedoch nur alle 398 Tage erneuert werden. Während die Domänenverifizierung automatisiert werden kann und sollte, können diese zusätzlichen Informationen nicht vollständig automatisiert werden.

Nein, nicht ganz. Die Beschränkung betrifft, welche Zertifikate Zertifizierungsstellen (CA) ausstellen können, nicht, welche Zertifikate Browser akzeptieren können.

Ein Browser überprüft nur, ob das aktuelle Datum innerhalb der Gültigkeitsdauer des Zertifikats liegt.

Sobald die Änderungen der einzelnen Regeln in Kraft treten, können Zertifizierungsstellen keine TLS-Zertifikate mit einer Gültigkeit von mehr als 200 / 100 / 47 Tagen mehr ausstellen.

Ein Zertifikat mit einer Gültigkeit von 398 Tagen, das vor Inkrafttreten der Änderung ausgestellt wurde, bleibt bis zu seinem Ablauf gültig. Dasselbe gilt für Zertifikate mit einer Gültigkeit von 200 Tagen beim Übergang auf 100 Tage und für Zertifikate mit einer Gültigkeit von 100 Tagen beim Übergang auf 47 Tage.

Nein, die grundlegenden Anforderungen sind nur für öffentliche Zertifizierungsstellen verbindlich.

Interne PKI funktioniert innerhalb Ihres Netzwerks oder Ihrer Clouds. Sie umfasst Zertifizierungsstellen, aber die Richtlinien, die interne Zertifizierungsstellen anwenden – einschließlich der Gültigkeitsdauer der Zertifikate – legen Sie selbst fest. Es mag sinnvoll sein, eine kürzere Gültigkeitsdauer auch für interne PKI zu wählen, aber dies ist nicht verpflichtend. Den gesamten Softwarebetrieb für interne PKI können Sie selbst durchführen, es ist jedoch eine komplizierte und fehleranfällige Aufgabe. DigiCert bietet mehrere verschiedene Lösungen für interne PKI für Unternehmens-, Cloud- und Fertigungsszenarien.

Nein. Während der Laufzeit der Bestellung (in Jahren) fallen keine zusätzlichen Kosten für die Erneuerung oder den Ersatz von Zertifikaten an. Sie können während der Gültigkeit der Bestellung eine unbegrenzte Anzahl von Reissue durchführen.

Nein, sie betreffen nur End- (Leaf) Zertifikate, die von einer Zwischenzertifizierungsstelle ausgestellt werden. Es gibt keine Regeln vom CA/B Forum oder anderen Standardisierungsgremien, die die Gültigkeitsdauer von Wurzel- und Zwischenzertifikaten einschränken, aber es gibt allgemeine Best Practices, und Anbieter von Software, die Zertifikate verwenden, setzen ihre eigenen Regeln für ihre Trust Root-Programme fest, die sich erheblich unterscheiden können.

Die Mozilla Root Store Policy (Abschnitt 7.4) gibt an, dass Mozilla Wurzelzertifikaten 15 Jahre nach der Schlüsselerstellung nicht mehr vertraut.

Die Gültigkeitsregeln im Chrome Root Program Policy, Version 1.6 (15. Februar 2025), sind komplexer. Es gibt kein festgelegtes Ablaufdatum, aber „ein Wurzelzertifikat einer CA mit entsprechenden Schlüsselmaterial, das vor mehr als 15 Jahren generiert wurde, wird kontinuierlich aus dem Chrome Root Store entfernt“. Wurzeln mit Schlüsseln, die vor dem 16. April 2014 erstellt wurden, werden gemäß einem festen jährlichen Zeitplan entfernt, der in den Root Program Policy festgelegt ist.

Das Microsoft Trusted Root Program gibt an, dass „neu ausgestellte Root CA mindestens acht Jahre und maximal 25 Jahre ab dem Datum des Einreichens gültig sein müssen“. Der Unterschied in den Regeln zwischen den Richtlinien von Microsoft und anderen resultiert aus der Vielfalt der Anwendungen, die Microsoft in seiner PKI unterstützt, was ein deutlich breiteres Spektrum ist als bei anderen Browsern.

Eine vernünftige Best Practice besteht darin, dass ein CA Root-Zertifikat nicht vor einem verknüpften Zwischenzertifikat ablaufen sollte.

Schlechte Verwaltung des Lebenszyklus von CA Root- und Zwischenzertifikaten kann schwerwiegende Folgen haben, wie kürzlich bei einem scheinbar vergessenen Zwischenzertifikat von Google gezeigt wurde, das ablief und viele Google Chromecast-Geräte außer Dienst setzte.

Für übliche und einfache Fälle, wie Webserver und öffentliche TLS-Zertifikate, ist die Automatisierung für CertCentral-Kunden kostenlos dank der weit unterstützten Standards Automated Certificate Management Environment (ACME) und ACME Renewal Information (ARI).

Natürlich sind nicht alle Zertifikate öffentliche TLS und nicht alle Technologien unterstützen ACME. Für diese Fälle bietet DigiCert Trust Lifecycle Manager fortschrittliche Automatisierungs- und Integrationsmöglichkeiten.

Die Automatisierung mit ACME erfordert jedoch mehr als nur das Ankreuzen eines Kästchens. Es sind Änderungen am Gerät oder in der Anwendung erforderlich (typischerweise am Webserver), die das Zertifikat anfordert. Für die meisten Administratoren ist dieser Prozess jedoch unkompliziert und gut dokumentiert.

ACME steht für Automated Certificate Management Environment.
ARI steht für ACME Renewal Information.

ACME ist ein von allen großen Zertifizierungsstellen unterstützter Standard, bei dem Client-Software für Zertifikate (typischerweise ein Webserver) eine Zertifizierungsstelle um ein Zertifikat bittet und es auf dem Client installiert. (In diesem Szenario ist der Webserver der Client.)

Die Client-Software muss auch ACME unterstützen. Die Unterstützung ist weit verbreitet, aber nicht universell. Ein ACME-Client-Programm läuft normalerweise auf dem Client-System laut Zeitplan, etwa mit dem Linux cron oder dem Windows Taskplaner, aber es gibt auch andere Lösungen, die die Zeitplanung in größere Produkte integrieren.

ARI ist ein verwandter Standard, mit dem ein Server eine Zeitplanempfehlung aussprechen kann, damit der Client das Zertifikat vor dem Ablaufdatum erneuern kann. Bei korrekter Konfiguration kann ARI dem Client auch eine Erneuerung im Fall einer Sperrung (Revocation) anordnen, um einen Ausfall zu verhindern.

Gemäß den neuen Regeln für TLS-Zertifikate wird ab dem 15. März 2026 die Wiederverwendung von Verifizierungsinformationen zur Identität des Subjekts (Subject Identity Information, SII) nur noch 398 Tage lang möglich sein, anstatt 825 Tage.

Das bedeutet, dass der Hauptauswirkung auf Ihre OV und EV Zertifikate ist, dass Sie die Informationen zur Identität des Subjekts (SII) – das sind Informationen im Zertifikat, die Ihre Organisation identifizieren – jährlich und nicht alle zwei Jahre erneut verifizieren müssen.

Gemäß den TLS Baseline Requirements erfordert dies einen jährlichen Telefonanruf mit einem Vertreter von DigiCert, und daher kann dieser Prozess nicht vollständig automatisiert werden.

Bitte beachten Sie, dass OV- und EV-Zertifikate auch Domainnamen schützen, daher ändert sich deren Gültigkeitsdauer gemäß demselben Zeitplan wie bei DV-Zertifikaten: auf 200 Tage im Jahr 2026, auf 100 Tage im Jahr 2027 und auf 47 Tage im Jahr 2029. Die Notwendigkeit der Automatisierung der Verwaltung dieser Zertifikate ist daher genauso entscheidend wie bei DV-Zertifikaten.

Die Zahl 47 Tage mag willkürlich erscheinen, basiert jedoch auf einer einfachen Sequenz:

• 200 Tage = 6 maximale Monate (184 Tage) + 1/2 eines 30-Tage-Monats (15 Tage) + 1 Tag Reserve
• 100 Tage = 3 maximale Monate (92 Tage) + ungefähr 1/4 eines 30-Tage-Monats (7 Tage) + 1 Tag Reserve
• 47 Tage = 1 maximaler Monat (31 Tage) + 1/2 eines 30-Tage-Monats (15 Tage) + 1 Tag Reserve

Dieses Modell zur Festlegung „ungerader“ Gültigkeitsdauern mit zusätzlicher Reserve ist seit langem eine Standardpraxis des CA/B Forum. Das derzeitige Limit von 398 Tagen wurde gewählt als 1 maximales Jahr (366 Tage) + 1 maximaler Monat (31 Tage) + 1 Tag Reserve.

Ja, gemäß den Regeln ist es möglich, zusätzliche 398 Tage zu erhalten, wenn Sie Ihre Zertifikate vor dem 15. März 2026 erneuern. Dies ist jedoch eine einmalige Verlängerung – bei der nächsten Erneuerung wird die maximale Gültigkeitsdauer auf 100 Tage verkürzt. Stellen Sie deshalb sicher, dass Sie die Automatisierung rechtzeitig einstellen, um vorbereitet zu sein.

Wenn Sie den Zertifikatsschlüssel (Rekey) am oder nach dem 15. März 2026 erneut erstellen müssen, muss DigiCert (wie jede andere öffentliche Zertifizierungsstelle) den zu diesem Zeitpunkt geltenden Regeln entsprechen, was Ihnen im besten Fall ein Zertifikat mit einer Gültigkeit von 200 Tagen verschafft.

Der beste Zeitpunkt zur Automatisierung der Zertifikatsverwaltung ist so früh wie möglich – so stellen Sie sicher, dass Sie auf diesen Prozess vorbereitet sind, ohne die Gefahr von Ausfällen durch abgelaufene Zertifikate oder andere Probleme einzugehen.

Der Markt für öffentliche TLS-Zertifikate konzentriert sich größtenteils auf Zertifikate, die in Browsern verwendet werden, typischerweise auf einem Webserver installiert, aber es gibt auch andere Anwendungsfälle. Ein gutes Beispiel sind VPN-Gateways und einige Geräte des Internets der Dinge (IoT).

Auch diese Geräte müssen das Tempo des Zertifikatslebenszyklus-Managements (CLM) beschleunigen. Viele von ihnen unterstützen direkt ACME oder ein anderes Automatisierungsprotokoll, sodass die Änderung der Parameter kein grundlegendes Problem darstellen muss. In anderen Fällen kann eine Unterstützung für einen alternativen Automatisierungsmechanismus bestehen oder es gibt überhaupt keine Unterstützung – hier muss der Benutzer die Automatisierung programmatisch sicherstellen.

Die Anpassung an den neuen Zeitplan wird bei diesen Geräten ein häufiges Problem sein. Es ist wichtig, ein vollständiges Inventar der betroffenen Assets zu erstellen, und DigiCert kann dabei helfen.