2026-10-20 · RESEARCH · The Offensive Technology team

Gilt die 200-Tage-Zertifikatsregel bereits?

Kurze Antwort: Ja, aber exakt nur im erforderlichen Umfang. Die Obergrenze des CA/Browser Forums für die Gültigkeit öffentlicher TLS-Zertifikate sank am 15. März 2026, vor sieben Monaten, von 398 Tagen auf 200 Tage. Wir haben die öffentliche Certificate Transparency-Historie von 702 Top-Domains ausgewertet, 1,359,618 deduplizierte geloggte Zertifikate von 2013 bis heute, und das Gültigkeitsfenster jedes Zertifikats vor und nach diesem Stichtag verglichen. In den zwei Jahren vor der Umstellung waren 75.3% der Zertifikate bereits 200 Tage oder kürzer. In den sieben Monaten danach liegt dieser Wert bei 99.91%, praktisch vollständige Compliance. Die eigentliche Erkenntnis liegt jedoch darin, wo die einzelnen Zertifizierungsstellen unter dieser neuen Obergrenze landen. Kostenlose, automatisierte Aussteller, darunter Let’s Encrypt und Google Trust Services, verharren bei einem Median von 90 Tagen, völlig unbeeinflusst von der Regel, da sie dieser bereits um Jahre voraus waren. Die großen kommerziellen CAs, DigiCert, Amazon, Microsoft, GlobalSign, fielen von einem Median von 324 bis 397 Tagen direkt auf 198 oder 199 Tage ab: genau die Grenze dessen, was die Regel nun erlaubt, keinen Tag kürzer. Eine von ihnen, Sectigo, durchbrach dieses Muster. Hier sind die vollständigen Daten, unsere Messmethodik und was sich im März 2027 erneut ändert.

Der Zeitplan und der aktuelle Stand

Ballot SC-081v3, “Introduce Schedule of Reducing Validity and Data Reuse Periods,” wurde am 11. April 2025 im CA/Browser Forum angenommen: Die Zertifikatsaussteller stimmten mit 25-0-5 (fünf Enthaltungen) ab, die Browser-Gruppe bestehend aus Apple, Google, Microsoft und Mozilla stimmte mit 4-0-0 dafür. Der Vorschlag stammte von Apple. Er sieht eine schrittweise Verkürzung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate vor, sowie eine parallele, noch steilere Verkürzung der Frist, für die eine CA eine vorherige Domain-Control-Validation wiederverwenden darf:

• Bis einschließlich 14. März 2026: 398 Tage maximale Gültigkeit, 398 Tage Wiederverwendung der Validierung.
• 15. März 2026: 200 Tage maximale Gültigkeit, 200 Tage Wiederverwendung der Validierung. Dieser Schritt ist bereits vollzogen.
• 15. März 2027: 100 Tage maximale Gültigkeit, 100 Tage Wiederverwendung der Validierung.
• 15. März 2029: 47 Tage maximale Gültigkeit, 10 Tage Wiederverwendung der Validierung.

Stand heute ist der 200-Tage-Schritt sieben Monate her, der 100-Tage-Schritt steht in etwa fünf Monaten an, und der 47-Tage-Schritt folgt in rund zweieinhalb Jahren. Dieser Beitrag befasst sich damit, was der erste Schritt in der Praxis tatsächlich verändert hat, nicht mit dem Zeitplan an sich: Jeder Registrar und jede CA-Knowledge-Base erklärt diese Termine bereits. Wir wollten wissen, ob sich die tatsächliche Ausstellungspraxis pünktlich zum Stichtag bewegt hat, und wir hatten dreizehn Jahre eigener passiver CT-Daten zur Hand, um das zu prüfen.

Zwei Lager, eine Frist

Zunächst der Blick auf das große Ganze. Über alle Aussteller hinweg stieg der Anteil neu ausgestellter Zertifikate mit 200 Tagen oder kürzer von 75.3% in den zwei Jahren vor dem Cap auf 99.91% in den sieben Monaten danach. Das ist ein nahezu lückenloser Übergang zur Compliance, genau wie man es von einer strikten Deadline der Baseline Requirements erwartet: Hält man sie nicht ein, verweigern Browser dem Zertifikat das Vertrauen. Dieser Teil funktionierte wie vorgesehen.

Im Detail betrachtet teilt sich das Ökosystem jedoch in zwei Gruppen, die sich sehr unterschiedlich oder überhaupt nicht bewegt haben:

• Bereits am Ziel. Let’s Encrypt und Google Trust Services, die beiden mit großem Abstand volumenstärksten Aussteller in unserer Stichprobe, setzten schon lange vor dieser Regel auf einen 90-Tage-Standard, da ihre Ausstellung kostenlos und automatisiert ist und von Beginn an auf häufige Erneuerung ausgelegt war. Ihr Median nach dem Stichtag liegt bei 90 Tagen. Ihr Median vor dem Stichtag lag ebenfalls bei 90 Tagen. Apples eigene per ACME ausgestellte Zertifikate und die neuere, auf Automatisierung ausgelegte CA Certainly zeigen mit 86 beziehungsweise 30 Tagen dasselbe Bild, völlig unbeeindruckt vom Stichtag. Für diese Gruppe hat der 15. März 2026 nichts geändert, weil die Regulierung lediglich aufgeschlossen hat zu dem Standard, den sie längst lebten.
• Exakt an der Grenze gelandet. DigiCert, Amazon, Microsoft und GlobalSign verzeichneten alle einen drastischen Rückgang, doch jede einzelne von ihnen landete bei 198 oder 199 Tagen, genau einen Tag unter der neuen 200-Tage-Obergrenze, nicht nennenswert darunter. Vor dem Cap lief ein typisches Zertifikat dieser Anbieter zwischen 180 und 397 Tagen. Danach konvergieren alle vier bis auf einen einzigen Tag an das rechtliche Maximum heran. Das ist Regeltreue nach dem Buchstaben eines Gesetzes, das die Branche explizit zu kurzlebigeren Zertifikaten bewegen sollte, ohne dessen Geist zu übernehmen.

Sectigo ist der einzige Aussteller in unserer Stichprobe, der in keines der beiden Muster sauber hineinpasst. Der Median vor dem Stichtag lag bei 366 Tagen, also eindeutig im Legacy-Lager. Nach dem Stichtag sank der Median jedoch auf 90.4 Tage, wobei 55.6% der Zertifikate nach der Umstellung bereits bei 90 Tagen oder weniger lagen. Das ist eine echte Verschiebung hin zum Verhalten der automatisierten Gruppe und kein bloßes Herunterrutschen an die neue Obergrenze. Anhand der CT-Metadaten allein lässt sich der Grund nicht belegen. Das Verhalten ist vereinbar mit einer Umstellung der Ausstellungs-Pipeline oder der ACME-Integration, die Sectigo-Kunden in unserer Stichprobe nun nutzen, bestätigen können wir diesen Mechanismus jedoch nicht.

Microsoft verdient eine gesonderte Erwähnung, da sich die Kennzahl auf dem Papier in die falsche Richtung bewegt hat: Ein Median von 180 Tagen vor dem Stichtag kletterte nach dem Stichtag auf 198 Tage. Wir interpretieren dies so, dass Microsoft zuvor bereits etwas kürzere Laufzeiten nutzte als die alte 398-Tage-Obergrenze erlaubte, und sich dann knapp unter dem neuen 200-Tage-Deckel neu eingependelt hat. Es handelt sich um dasselbe Ausreizen des Limits wie bei den anderen Enterprise-CAs, nur ausgehend von einer etwas kürzeren Baseline. Dies ist kein Beweis dafür, dass Microsofts Zertifikate unsicherer geworden sind; Gültigkeitsdauer und Sicherheitsniveau liegen nicht auf derselben Achse, was auch Thema unseres nächsten Abschnitts ist.

Die Akteure in Zahlen

Jeder der oben genannten Aussteller unterschritt die 200-Tage-Grenze bei praktisch 100% seiner Zertifikate nach Inkrafttreten der Regel in unserer Stichprobe. Wir haben keine Verstöße gegen die Baseline Requirements festgestellt, was man von Root-Programmen, die dies aktiv prüfen, auch erwartet. Die Erkenntnis ist nicht mangelnde Compliance. Sie besteht vielmehr darin, dass Compliance in zwei grundverschiedenen Ausprägungen auftritt. Die Spanne zwischen “automatisiert, ohnehin kurz” und “Enterprise, nun direkt am Limit” beträgt bei den tatsächlichen Tagen immer noch etwa den Faktor zwei, 90 zu 198 Tage, und das innerhalb einer einzigen Regel, die beide Gruppen gleichermaßen erfüllen.

Unsere Messmethodik

Ein Skeptiker sollte in der Lage sein, dies von Grund auf nachzuvollziehen.

• Die Grundgesamtheit. Dieselben rund 700 Certificate Transparency-Historien von Tranco-Top-Domains, ausgelesen über crt.sh, die wir bereits für unsere CT-Logging-Delay-Erhebung und unsere Erhebung zu internen Hostname-Leaks. Für diesen Beitrag haben wir null neue Netzwerk-Requests abgesetzt; der gesamte Datensatz war bereits aus früheren Arbeiten zwischengespeichert.
• Die Metrik. Für jedes deduplizierte geloggte Zertifikat berechnet sich die Gültigkeitsdauer aus not_after minus not_before, gerundet auf den nächsten vollen Tag vor der Gruppierung, da ein nominelles “90-Tage”-Zertifikat häufig 90 Tage plus einige Stunden Zeitstempel-Drift aufweist, bedingt durch die Tageszeit der Ausstellung.
• Die Aufteilung. Wir haben Zertifikate danach gruppiert, ob not_before vor oder am/nach dem 15. März 2026 lag. Für den Vergleich pro Aussteller verwendeten wir ein passendes Zwei-Jahres-Fenster unmittelbar vor der Umstellung (15. März 2024 bis 14. März 2026) anstelle der gesamten Historie, damit jahrzehntealte Legacy-Zertifikate einer CA deren Vorher-Wert nicht verzerren.
• Was wir nicht getan haben. Wir haben zu keinem Zeitpunkt ein Zertifikat angefordert, uns mit einem Webserver verbunden oder Scans durchgeführt. Das Auslesen eines öffentlichen CT-Logs ist ein Lookup, kein aktiver Scan.
• Was wir gespeichert haben. Aggregierte Zählwerte, Mediane und Perzentile pro Aussteller und Zeitraum. Der Datensatz enthält keinerlei Domain- oder Subdomain-Namen.

Was dies nicht beweist

Ehrliche Grenzen der Analyse, denn eine Zahl ohne ihre Einschränkungen ist reines Marketing.

• Eine kürzere Zertifikatsgültigkeit bedeutet nicht automatisch eine kürzere Lebensdauer des privaten Schlüssels. Eine CA oder ein Antragsteller kann ein Zertifikat beliebig oft alle 90 oder 200 Tage auf Basis desselben Schlüsselpaars erneuern. Die grundlegenden Metadaten eines crt.sh-Eintrags enthalten keinen Fingerprint des öffentlichen Schlüssels des Subjects. Daher können wir anhand dieser Daten nicht feststellen, ob Schlüsselmaterial zusammen mit dem Zertifikat tatsächlich rotiert wird. Der Sicherheitsgewinn kürzerer Gültigkeitsdauern hängt jedoch genau von dieser Rotation ab; wir haben sie hier nicht gemessen.
• Sieben Monate Daten nach dem Stichtag sind eine vorläufige Momentaufnahme. Das reicht aus, um das Muster der anfänglichen Compliance-Reaktion aufzuzeigen, nicht aber, um daraus ein dauerhaftes Gleichgewicht der Branche unter dem 200-Tage-Cap abzuleiten. Wir planen, dies beim nächsten Stichtag im März 2027 erneut zu überprüfen.
• Nicht jeder Aussteller liefert ein belastbares Vorher-Nachher-Bild. Bei einigen CAs in unserem Cache, darunter GoDaddy und mehrere kleinere oder regionale Aussteller, war die Stichprobe nach dem Stichtag in unserem 700-Domain-Panel zu klein für eine verlässliche Aussage. Wir haben nur Aussteller tabellarisch erfasst, für die auf beiden Seiten ausreichend Daten vorlagen.
• Die Stichprobe tendiert zu reichweitenstarken Domains. Die Spitzengruppe von Tranco stützt sich stark auf ressourcenstarke Organisationen und große CDNs. Das Ausstellungsverhalten für den Long Tail kleinerer Websites, die häufig über andere Automatisierungswege hinter denselben großen CAs liegen, kann davon abweichen.
• Dies misst Zertifizierungsstellen, nicht direkt das Angreiferrisiko. Ein kürzeres Limit verkleinert das maximale Zeitfenster, in dem ein Zertifikat gültig bleibt, falls etwas schiefläuft. Dies ist jedoch nur ein Faktor innerhalb einer längeren Kette, zu der auch Revocation, Schlüsselhygiene und Monitoring gehören.

Warum das wichtig ist

Das zentrale Argument für die Verkürzung von Zertifikatslaufzeiten ist das Expositionsfenster: Ein kompromittiertes oder fehlerhaft ausgestelltes Zertifikat, das nach der alten Regel 398 Tage gelaufen wäre, ist jetzt höchstens 200 Tage gültig, künftig maximal 100 und im weiteren Verlauf noch 47 Tage. Diese Argumentation greift jedoch nur dann, wenn sich das Ökosystem tatsächlich in Richtung kürzerer Laufzeiten bewegt und nicht bloß knapp unter der jeweils rechtlich zulässigen Obergrenze bleibt. Nach sieben Monaten zeigen die Daten, dass beides gleichzeitig zutrifft. Die Regel erfüllte ihren Zweck als harte Vorgabe: Die Compliance stieg von drei Vierteln auf praktisch 100%, für Branchenverhältnisse über Nacht. Der Großteil des Volumens, der sich bewegte, ging jedoch nur genau so weit wie zwingend gefordert und landete bis auf einen Tag an der 200-Tage-Grenze statt auch nur in der Nähe von 90. Die Aussteller, die bereits kurze Laufzeiten nutzten und deren Geschäftsmodell auf günstiger, häufiger und automatisierter Erneuerung basiert, blieben unberührt, da sie ihre Systeme Jahre vor dem verpflichtenden Forum-Beschluss darauf ausgelegt hatten. Es ist dasselbe Muster, das wir beobachtet haben, als wir analysierten, wie schnell Zertifikate in CT geloggt werden: Die Bereiche dieses Ökosystems, die wirksamer Durchsetzung unterliegen, bewegen sich exakt so schnell wie gefordert, keinen Deut schneller.

Gilt die 200-Tage-Zertifikatsregel bereits: Kurze Antworten

Wann trat die 200-Tage-Zertifikatsregel in Kraft?

Am 15. März 2026 durch CA/Browser Forum Ballot SC-081v3, beschlossen am 11. April 2025. Damit wurde die maximale Gültigkeit öffentlicher TLS-Zertifikate von 398 auf 200 Tage verkürzt. Die nächste Reduzierung auf 100 Tage folgt am 15. März 2027; eine finale Reduzierung auf 47 Tage greift am 15. März 2029.

Müssen bestehende Zertifikate unter dem neuen Limit neu ausgestellt werden?

Nein. Die Obergrenze gilt nur für Zertifikate, die am oder nach dem Stichtag ausgestellt wurden. Ein unter der alten 398-Tage-Regel ausgestelltes Zertifikat bleibt gemäß seiner ursprünglichen Laufzeit gültig.

Wird auch die Frist zur Wiederverwendung der Domain-Validierung verkürzt?

Ja, nach demselben Zeitplan: von 398 auf 200 Tage parallel zum Schritt im März 2026, danach 100 Tage im März 2027 und 10 Tage bis März 2029. Dies erzwingt unabhängig von der Zertifikatsgültigkeit selbst eine häufigere Neuüberprüfung der Domain-Kontrolle.

Wann tritt die 47-Tage-Zertifikatsregel in Kraft?

Am 15. März 2029, als letzter Schritt des SC-081v3-Zeitplans: 398 Tage bis 14. März 2026, 200 Tage ab 15. März 2026, 100 Tage ab 15. März 2027, 47 Tage ab 15. März 2029.

Wie wurde das gemessen?

Passiv. Wir haben über crt.sh die öffentliche CT-Historie von rund 700 Domains aus den Tranco Top-1,000 ausgelesen und die Gültigkeitsdauer jedes Zertifikats als NotAfter minus NotBefore berechnet. Es wurde kein Host kontaktiert, aufgelöst oder gescannt. Das Ergebnis sind 1,359,618 deduplizierte Log-Einträge von 2013 bis Oktober 2026.

Weiterführende Analysen

• Certificate Transparency Log-Verzögerung: Was 1.3M Zertifikate zeigen.
• Wie Certificate Transparency-Logs interne Subdomains leaken.
• Was die Zertifikate beweisen.