HTTPS-Zertifikate: kürzere Laufzeiten ab 2026 einplanen

Welche Zertifikate ein Browser akzeptiert, entscheidet weder der Hoster noch die Zertifizierungsstelle allein. Die gemeinsamen Mindestanforderungen stehen in den TLS Baseline Requirements des CA/Browser Forum, eines Gremiums aus Zertifizierungsstellen und Browserherstellern. Wer dort gegen eine Vorgabe verstößt, verliert das Vertrauen der Browser, weshalb diese Regeln in der Praxis verbindlicher wirken als mancher Vertrag. Abschnitt 6.3.2 dieses Dokuments regelt die Gültigkeitsdauer eines Endkundenzertifikats, also genau die Spanne, die auf Ihrer Website zwischen zwei Erneuerungen liegt.

Die Vorgabe unterscheidet zwei Ebenen: Eine SOLL-Grenze nennt den empfohlenen Wert, eine MUSS-Grenze die harte Obergrenze. Für Zertifikate, die vor dem 15. März 2026 ausgestellt wurden, liegen diese Werte bei 397 und 398 Tagen (CA/Browser Forum). Für Ausstellungen am oder nach dem 15. März 2026 gelten 199 und 200 Tage (CA/Browser Forum). Ab dem 15. März 2027 sind es 99 und 100 Tage (CA/Browser Forum), ab dem 15. März 2029 dann 46 und 47 Tage (CA/Browser Forum). Entscheidend ist das Ausstellungsdatum: Ein Zertifikat, das kurz vor einer Stufe ausgestellt wurde, läuft seine Frist zu Ende und wird nicht vorzeitig ungültig.

Parallel verkürzt sich eine zweite Frist, die weniger bekannt ist und im Betrieb mehr auslöst: die Wiederverwendung geprüfter Freigabedaten. Hat eine Zertifizierungsstelle einmal geprüft, dass Sie über einen Domainnamen verfügen, darf sie dieses Prüfergebnis eine begrenzte Zeit weiterverwenden. Abschnitt 4.2.1 senkt diese Spanne für Domainnamen und IP-Adressen ab dem 15. März 2026 auf 200 Tage (CA/Browser Forum), ab dem 15. März 2027 auf 100 Tage (CA/Browser Forum) und ab dem 15. März 2029 auf 10 Tage (CA/Browser Forum). Der letzte Wert ist der eigentliche Einschnitt: Ab dann wird die Freigabe praktisch bei jeder Ausstellung neu geprüft. Wer diesen Nachweis per Hand über einen DNS-Eintrag oder eine Datei im Webverzeichnis erbringt, tut das dann in kurzem Takt.

HTTPS ist längst der Normalfall im Web. Der Web Almanac des HTTP Archive weist für die Ausgabe 2025 aus, dass 98,8 Prozent (Web Almanac 2025) aller Anfragen auf Mobilgeräten über HTTPS laufen; bei den Startseiten stieg der Anteil auf 97,3 Prozent (Web Almanac 2025). Verschlüsselung ist damit keine Zusatzleistung mehr, sondern Grundlage, und ein abgelaufenes Zertifikat fällt entsprechend hart auf. Der Browser zeigt keine kleine Warnung am Rand, sondern eine ganzseitige Unterbrechung, die die meisten Besucher nicht durchklicken.

Was sich mit kürzeren Laufzeiten ändert, ist weniger die Technik als die Häufigkeit. Jeder Schritt, der bei einer Erneuerung nötig ist, wiederholt sich öfter: Schlüssel erzeugen, Freigabe nachweisen, Zertifikat abholen, Dienst neu laden, Ergebnis prüfen. Ein Ablauf, der einmal jährlich über einen Kalendereintrag lief, wird bei mehreren Erneuerungen im Jahr zu einer wiederkehrenden Störquelle, besonders dort, wo mehrere Personen beteiligt sind oder dasselbe Zertifikat an mehreren Stellen liegt.

Diese sechs Punkte sind zusammen der Grund, warum die Umstellung selten an der Technik scheitert. Sie scheitert an Übersicht und Zuständigkeit: Der Webserver ist automatisiert, der Mailserver nicht; die Hauptdomain läuft, eine alte Aktionsadresse nicht. Wer die Grundlagen der Website-Sicherheit einmal geordnet hat, hat für diesen Schritt bereits die halbe Liste beisammen.

Vor jeder Automatik steht eine Liste. Ohne sie automatisiert man die Stellen, die man kennt, und übersieht die, die im Ernstfall auffallen. Die Liste entsteht nicht aus dem Gedächtnis, sondern aus drei Quellen: den DNS-Einträgen der Domain, den Diensten auf den beteiligten Servern und den Verträgen mit Dienstleistern, die eigene Namen betreiben.

Zu jedem Eintrag gehören vier Angaben: der Name, der ausliefernde Dienst, die Art der Erneuerung und die zuständige Rolle. Der Ablauftermin gehört bewusst nicht dazu; er ändert sich bei jeder Erneuerung und wird gemessen, nicht gepflegt. Messen lässt er sich mit Bordmitteln, ohne Zugriff auf die Verwaltungsoberfläche.

Der erste Aufruf zeigt, was der Server tatsächlich ausliefert, nicht, was in einer Oberfläche eingetragen ist. Das ist der Unterschied, der zählt: Ein erneuertes Zertifikat, das der Dienst nicht neu geladen hat, steht in der Verwaltung als aktuell und geht draußen trotzdem als altes über die Leitung. Der zweite Aufruf prüft denselben Punkt für den Mailnamen, der dritte zeigt, ob die Seite überhaupt antwortet.

Eine Automatik ohne Kontrolle ist eine Vermutung. Die Kontrolle misst deshalb nicht den Auftrag, sondern seinen Zustand: Was liefert der Server heute aus, und wie lange gilt es noch? Diese Messung läuft von außen, unabhängig vom erneuernden System, und sie läuft für jeden Namen aus dem Verzeichnis. Das Verzeichnis selbst kann eine einfache Datei sein; es muss lesbar, vollständig und aktuell sein, nicht schön.

Zwei Felder tragen die eigentliche Arbeit. warnung_tage legt fest, wie viele Tage vor dem Ablauf gemeldet wird; der Wert richtet sich nach der Reaktionszeit der Beteiligten, nicht nach der Laufzeit des Zertifikats. Und rolle mit dem Wert offen ist eine sichtbare Lücke, genau dafür wird die Datei überhaupt geführt. Eine Zeile, die auf manuell und offen steht, ist die Aufgabe der nächsten Wochen, kein Betriebszustand.

Aus derselben Datei entsteht der Nachweis. Wer nach einem Vorfall belegen will, dass Verschlüsselung nach dem Stand der Technik eingerichtet war, legt kein Zertifikat vor, sondern eine nachvollziehbare Regelung samt Kontrolle. Artikel 32 Absatz 1 DSGVO verknüpft genau das: den Stand der Technik, das Risiko und die geeigneten technischen und organisatorischen Maßnahmen. Ein gepflegtes Verzeichnis mit Zuständigkeit, Warnschwelle und Meldeweg ist dafür ein passender Beleg; den weiteren Rahmen fasst die DSGVO-Checkliste für Websites zusammen.

Für eine Website mit einer Domain, einem Hoster und einem Postfach ist der Aufwand überschaubar. In den meisten Hostingumgebungen ist die automatische Erneuerung bereits eingerichtet; dann bleibt zu prüfen, ob sie wirklich jeden Namen abdeckt und ob eine Meldung ankommt, wenn sie es einmal nicht tut. Das ist eine Stunde Arbeit, kein Projekt, und sie ist vor der ersten Stufe leichter zu erledigen als danach.

Aufwendiger wird es dort, wo über die Jahre etwas gewachsen ist: eine zweite Domain aus einer alten Kampagne, ein Shop auf einer eigenen Subdomain, ein Buchungssystem bei einem Dienstleister, ein Mailserver im eigenen Haus. Dann lohnt sich der Aufbau des Verzeichnisses, bevor die erste Stufe greift. Es ist derselbe Ordnungsschritt, den auch andere gewachsene Strukturen brauchen, etwa Kundengruppen und Preisregeln in einem B2B-Onlineshop: erst der Bestand, dann die Regel.

Wir übernehmen diesen Schritt als Teil der laufenden Betreuung: Wir nehmen auf, welche Namen im Einsatz sind, richten die automatische Erneuerung samt Neuladen der Dienste ein, bereinigen Weiterleitungen und gemischte Inhalte und legen eine Überwachung an, die vor dem Ablauf an eine benannte Rolle meldet. Den Stand halten wir schriftlich fest, damit die nächste Stufe erfahrungsgemäß ohne Eingriff durchläuft. Das passt zu Webhosting ebenso wie zu einer bestehenden Umgebung bei einem anderen Anbieter; den laufenden Teil beschreibt unsere Seite zur Website-Betreuung. Wenn Sie wissen möchten, wie Ihr Bestand heute dasteht, schreiben Sie uns über das Kontaktformular.