Das kleine Schloss neben der Adresse im Browser ist für die meisten Besucher kein Technikdetail, sondern ein Urteil: Diese Seite ist in Ordnung. Dahinter steht ein Zertifikat, das die Verbindung verschlüsselt und bestätigt, dass die Adresse zu dem Server gehört, der antwortet. Dieses Zertifikat hat ein Ablaufdatum, und die Abstände zwischen zwei Ablaufdaten werden gerade deutlich kürzer. Seit dem 15. März 2026 darf ein neu ausgestelltes Zertifikat höchstens 200 Tage gelten, ab dem 15. März 2027 noch 100 Tage und ab dem 15. März 2029 noch 47 Tage (CA/Browser Forum). Gleichzeitig ist Chrome 154 seit dem 22. September 2026 im Stable-Kanal (Chrome Releases), und Google hat angekündigt, mit dieser Version vor dem ersten Aufruf jeder öffentlichen Seite ohne HTTPS um Erlaubnis zu fragen (Google). Beides zusammen macht aus einer Aufgabe, die früher einmal im Jahr anstand, eine Daueraufgabe. Dieser Beitrag erklärt aus Sicht des Inhabers, was sich ändert, woran man ein ablaufendes Zertifikat erkennt und welche Fragen an den eigenen Dienstleister gehören.
Was das Schloss im Browser für Besucher bedeutet
Ein Zertifikat erfüllt zwei Aufgaben zugleich. Es verschlüsselt, was zwischen Besucher und Website hin- und hergeht, also Formulareingaben, Anmeldedaten und die Seiten selbst.
Und es bestätigt, dass die Adresse im Browser tatsächlich zu dem Server gehört, der antwortet. Ausgestellt wird es von einer Zertifizierungsstelle, die vorher prüft, ob der Antragsteller die Domain kontrolliert. Nach welchen Regeln das geschieht, legt das CA/Browser Forum fest, nach eigener Beschreibung ein freiwilliger Zusammenschluss von Zertifizierungsstellen und Herstellern von Browsern und anderer Software, die sich auf Zertifikate verlässt (CA/Browser Forum). Seine Baseline Requirements sind der Grund, warum sich die Laufzeiten ändern: Browser nehmen nur Zertifikate an, die diesen Regeln folgen. Wie HTTPS in eine breitere Absicherung der Website passt, beschreibt der Beitrag über eine kleine Angriffsfläche für die Firmenwebsite; hier geht es allein um das Zertifikat und seine Laufzeit.
Solange das Zertifikat gültig ist, merkt niemand etwas davon. Das ändert sich am Tag nach dem Ablauf. Der Browser baut die Verbindung dann nicht mehr stillschweigend auf, sondern zeigt eine ganzseitige Warnung: Die Verbindung sei nicht sicher, Dritte könnten Daten mitlesen. In Chrome steht darunter der Fehlercode NET::ERR_CERT_DATE_INVALID. Weiter kommt nur, wer die erweiterten Angaben öffnet und die Warnung bewusst übergeht. Wer eigentlich nur eine Telefonnummer oder die Öffnungszeiten sucht, schließt an dieser Stelle eher den Tab und ruft den nächsten Treffer auf. Im Betrieb selbst fällt das oft spät auf: Die eigene Seite ruft man selten neu auf, und die Warnung wird erst bemerkt, wenn jemand anruft und fragt, ob die Website gehackt sei.
- Die Website öffnet sich nicht mehr, stattdessen erscheint eine ganzseitige Warnung vor einer unsicheren Verbindung
- Anfragen über das Kontaktformular bleiben aus, ohne dass beim Betrieb eine Fehlermeldung ankommt
- Eingebundene Teile wie ein Terminbuchungsfenster oder ein Shop auf einer Nebenadresse bleiben leer, während die Hauptseite noch lädt
- Links aus Newslettern, Anzeigen und QR-Codes führen auf die Warnseite statt auf das Angebot
- Kundinnen und Kunden melden sich telefonisch und fragen, ob mit der Seite etwas nicht stimmt
Zertifikat und Domain sind zwei verschiedene Dinge
Die Laufzeit schrumpft: 398, 200, 100, 47 Tage
Bis März 2026 war die Rechnung einfach. Ein Zertifikat, das vor dem 15. März 2026 ausgestellt wurde, durfte bis zu 398 Tage (CA/Browser Forum) gelten, also gut ein Jahr.
Viele Betriebe haben es entsprechend behandelt: einmal im Jahr eine Rechnung, einmal im Jahr eine Verlängerung, oft von Hand im Kundenmenü des Hosters erledigt. Seit dem Stichtag ist diese Rechnung vorbei. Für Zertifikate, die ab dem 15. März 2026 und vor dem 15. März 2027 ausgestellt werden, liegt die Obergrenze bei 200 Tagen (CA/Browser Forum). Maßgeblich ist das Ausstellungsdatum: Ein Zertifikat, das Anfang März 2026 noch mit der alten Höchstlaufzeit ausgestellt wurde, bleibt bis zu seinem Ende gültig. Wer bisher nichts bemerkt hat, bemerkt es darum spätestens bei der nächsten Verlängerung, denn das neue Zertifikat läuft nur noch etwa halb so lange.
Die nächsten Stufen stehen bereits fest. Ab dem 15. März 2027 sind es höchstens 100 Tage, ab dem 15. März 2029 höchstens 47 Tage (CA/Browser Forum). Dazu kommt eine zweite Frist, die weniger bekannt ist. Bevor eine Zertifizierungsstelle ein Zertifikat ausstellt, prüft sie, ob der Antragsteller die Domain kontrolliert, und das Ergebnis dieser Prüfung darf sie eine Zeit lang wiederverwenden. Ab dem 15. März 2026 sind das höchstens 200 Tage, ab dem 15. März 2027 100 Tage und ab dem 15. März 2029 nur noch 10 Tage (CA/Browser Forum). Praktisch heißt das: Ab 2029 wird bei nahezu jeder Verlängerung die Domain neu geprüft. Das gelingt nur, wenn der Nachweis dafür, etwa ein DNS-Eintrag oder eine Datei auf dem Server, zu diesem Zeitpunkt noch stimmt.
Tabelle waagerecht wischen
| Zertifikat ausgestellt | Höchstlaufzeit | Domainprüfung wiederverwendbar | Ausstellungen pro Jahr, rechnerisch mindestens |
|---|---|---|---|
| vor dem 15.03.2026 | 398 Tage | nach älterer Regel | 1 |
| ab 15.03.2026 | 200 Tage | 200 Tage | 2 |
| ab 15.03.2027 | 100 Tage | 100 Tage | 4 |
| ab 15.03.2029 | 47 Tage | 10 Tage | 8 |
Die letzte Spalte ist eine einfache Rechnung: 365 Tage geteilt durch die Höchstlaufzeit, aufgerundet. In der Praxis liegt die Zahl höher, weil niemand ein Zertifikat bis zum letzten Tag laufen lassen sollte; sinnvoll ist eine Verlängerung mit Vorlauf, damit ein Fehlschlag noch vor dem Ablauf auffällt. Bei 47 Tagen Laufzeit (CA/Browser Forum) bleibt für diesen Vorlauf nicht viel Spielraum. Genau hier endet das Modell „Kalendereintrag einmal im Jahr“. Wer heute noch von Hand verlängert, muss das ab 2027 mindestens viermal und ab 2029 mindestens achtmal im Jahr tun, jeweils pünktlich und für jede Adresse. Das ist kein Fehler, den man einmal behebt, sondern ein Ablauf, der von Anfang an so gebaut sein sollte, dass er ohne Erinnerung auskommt.
Die Kalenderprobe
Chrome 154: Rückfrage vor Seiten ohne HTTPS
Die zweite Änderung kommt vom Browser. Ende Oktober 2025 hat das Chrome-Sicherheitsteam angekündigt, mit Chrome 154 im Oktober 2026 die Einstellung „Always Use Secure Connections“ standardmäßig einzuschalten (Google).
Chrome bittet dann um Erlaubnis, bevor eine öffentliche Seite ohne HTTPS zum ersten Mal geöffnet wird. Neu ist die Einstellung nicht: Es gibt sie seit 2022 als freiwillige Option (Google). In diesem Modus versucht Chrome jede Verbindung zuerst über HTTPS und zeigt eine Warnung, die sich übergehen lässt, wenn HTTPS nicht verfügbar ist. Neu ist, dass sie für alle gelten soll, die an der Voreinstellung nichts ändern.
Seit dem 22. September 2026 ist Chrome 154 im Stable-Kanal für Windows, Mac und Linux; die Auslieferung läuft nach Angabe des Chrome-Teams über die folgenden Tage bis Wochen (Chrome Releases). Ob und wann die Rückfrage bei einem bestimmten Besucher erscheint, hängt also davon ab, wann sein Browser aktualisiert und die neue Voreinstellung wirksam wird. Vorgeschaltet war ein Zwischenschritt: Mit Chrome 147 im April 2026 sollte die Einstellung für die mehr als 1 Milliarde Nutzer eingeschaltet werden, die den erweiterten Safe-Browsing-Schutz in Chrome aktiviert haben (Google). Abschalten lässt sich die Warnung weiterhin, indem man die Einstellung deaktiviert (Google). Für einen Betrieb ist das kein Trost: Wer eine Seite zum ersten Mal besucht, liest die Rückfrage, bevor er irgendetwas vom Angebot sieht, und schaltet dafür kaum eine Einstellung um.
Das bedeutet, dass Chrome vor dem ersten Zugriff auf eine öffentliche Website ohne HTTPS um die Erlaubnis des Nutzers bitten wird.
Warum gerade jetzt? Google veröffentlicht einen HTTPS-Transparenzbericht, der misst, welcher Anteil der Seitenaufrufe in Chrome über HTTPS läuft. Der Wert lag 2015 bei etwa 30 bis 45 Prozent und erreichte um 2020 einen Bereich von 95 bis 99 Prozent (Google). Seitdem ist er nach Googles Darstellung weitgehend stehen geblieben (Google). Rechnet man Aufrufe privater Adressen im Heim- oder Firmennetz heraus, steigt der Anteil unter Windows von 95 auf 98 Prozent, unter Android und Mac auf über 99 Prozent (Google). Übrig bleibt ein kleiner Rest öffentlicher Seiten ohne HTTPS, und genau auf diesen Rest zielt die neue Voreinstellung: alte Nebenadressen, vergessene Aktionsseiten, Buchungsformulare auf einem eigenen Server.
Für die Besucher soll die Umstellung wenig Aufwand bedeuten. Chrome warnt nicht bei jedem Aufruf, sondern nur, wenn eine Seite ohne HTTPS neu ist oder länger nicht besucht wurde; statt bei etwa 1 von 50 Seitenaufrufen erscheint die Warnung damit deutlich seltener (Google). In einem Versuch mit einem kleinen Teil der Nutzer lag der Anteil der Aufrufe mit Warnung deutlich unter 3 Prozent, und im Median sah ein Nutzer weniger als eine Warnung pro Woche (Google). Für einen Betrieb liest sich dieselbe Zahl anders herum: Die Warnung trifft ausgerechnet die neuen Besucher, also die Menschen, die zum ersten Mal über eine Suche, eine Anzeige oder einen QR-Code auf die Seite kommen. Stammkunden, die die Seite regelmäßig aufrufen, sehen sie nicht wiederholt; wer die Seite zum ersten Mal öffnet, dagegen schon.
Vergessene Adressen: shop., termin., aktion.
Die Hauptadresse eines Betriebs ist heute in aller Regel verschlüsselt. Das Risiko liegt an den Rändern.
Über die Jahre sammeln sich Nebenadressen an: shop. für einen Onlineshop, der irgendwann eingestellt wurde, termin. für das Buchungssystem eines früheren Anbieters, aktion. oder sommer. für eine Kampagne, die längst vorbei ist. Manche dieser Adressen zeigen noch auf einen Server, auf dem kein Zertifikat mehr erneuert wird oder nie eines lag. Solange niemand sie aufruft, fällt das nicht auf. Sobald aber ein alter Flyer, ein Eintrag in einem Branchenverzeichnis oder eine Gutscheinkarte darauf verweist, landet ein neuer Besucher entweder vor der Chrome-Rückfrage oder vor einer Zertifikatswarnung. Besonders heikel sind Seiten, auf denen Geld oder Daten fließen, etwa beim Verkauf von Gutscheinen über die Website: Dort kostet eine Warnung unmittelbar einen Abschluss.
Ein zweiter typischer Fall sind gedruckte Wege auf die Website. Ein QR-Code auf einem Plakat oder einer Visitenkarte führt nur dann zur Rückfrage, wenn die Adresse dahinter kein HTTPS anbietet. Chrome versucht in dieser Einstellung zuerst die verschlüsselte Verbindung, auch wenn im Code noch http:// steht. Scheitert das, weil die Nebenadresse auf einem alten Server ohne Zertifikat liegt, erscheint die Warnung. Wie sich QR-Codes und Zielseiten in der Offline-Werbung sauber planen lassen, steht in einem eigenen Beitrag. Die Suche nach alten Adressen ist dabei eng verwandt mit der Suche nach alten Aussagen: Wer ohnehin Website-Texte auf Aussagen mit Verfallsdatum durchsieht, kann die Liste der verlinkten Adressen im selben Durchgang prüfen.
- Die Adresse mit und ohne www: Beide Varianten brauchen ein gültiges Zertifikat, auch wenn eine davon nur weiterleitet
- Nebenadressen für Shop, Terminbuchung, Kundenportal oder Downloads
- Alte Kampagnenadressen, die auf Flyern, Plakaten, Fahrzeugbeschriftungen oder in QR-Codes stehen
- Zusätzliche Domains, etwa die Schreibweise mit Bindestrich oder eine zweite Endung, die auf die Hauptseite weiterleiten
- Adressen, die ein früherer Dienstleister eingerichtet hat und die in keinem laufenden Vertrag mehr auftauchen
- Links in E-Mail-Signaturen, Newsletter-Vorlagen und Einträgen in Branchenverzeichnissen
Adresse Zweck Zertifikat bis Zuständig
www.ihr-betrieb.example Hauptseite ____________ ____________
ihr-betrieb.example Weiterleitung auf www ____________ ____________
shop.ihr-betrieb.example Onlineshop, noch aktiv? ____________ ____________
termin.ihr-betrieb.example Terminbuchung ____________ ____________
aktion.ihr-betrieb.example alte Kampagne ____________ ____________
ihr-betrieb-zwei.example Zusatzdomain ____________ ____________Auch Weiterleitungen brauchen ein Zertifikat
Erinnerungsmails sind kein Netz mehr
Lange gab es ein Sicherheitsnetz, auf das sich viele verlassen haben, ohne es zu wissen: Die Zertifizierungsstelle schickte eine E-Mail, wenn ein Zertifikat bald ablief. Dieses Netz wird dünner.
Die Zertifizierungsstelle Let's Encrypt hat ihre Erinnerungsmails zum 4. Juni 2025 eingestellt (Let's Encrypt). Begründet wurde das unter anderem damit, dass in den vergangenen 10 Jahren immer mehr Kunden eine verlässliche Automatik für die Verlängerung eingerichtet hätten (Let's Encrypt). Die Botschaft dahinter gilt unabhängig von der Zertifizierungsstelle: Die Verlängerung soll ohne menschliches Zutun laufen, und wer auf eine Mail wartet, wartet unter Umständen vergeblich. Selbst wo Erinnerungen noch verschickt werden, gehen sie an die Adresse, die bei der Einrichtung hinterlegt wurde, und das ist nicht selten das Postfach einer früheren Agentur oder eines ausgeschiedenen Mitarbeiters.
Dazu kommt ein zweites Problem, das mit jeder Stufe wächst. Bei 200 Tagen Laufzeit steht eine Verlängerung rechnerisch zweimal im Jahr an, bei 100 Tagen viermal, bei 47 Tagen (CA/Browser Forum) achtmal. Jeder dieser Termine ist eine Gelegenheit, bei der eine Automatik scheitern kann: weil sich ein DNS-Eintrag geändert hat, weil ein Server umgezogen ist oder weil eine Zugangsberechtigung abgelaufen ist. Deshalb reicht es nicht, dass automatisch verlängert wird; es muss auch jemand erfahren, wenn es nicht klappt. Wer bei seinem Dienstleister ohnehin Vertrag und Zugänge prüft, sollte diese Frage gleich mit auf die Liste setzen.
Automatisch mit Rückmeldung
Die Verlängerung läuft ohne Zutun, und bei einem Fehler geht eine Meldung an eine Stelle, die sie liest und handelt. Das ist das Modell, das auch bei 47 Tagen Höchstlaufzeit trägt.
Von Hand nach Kalender
Jemand verlängert nach Termin im Kundenmenü des Hosters. Bei 398 Tagen war das ein Termin im Jahr, bei 200 Tagen sind es rechnerisch zwei, ab 2029 mindestens acht.
Beim Dienstleister, ohne Einblick
Hoster oder Agentur kümmern sich, aber im Betrieb weiß niemand, wie und wann. Das kann gut gehen, lässt sich aber erst beurteilen, wenn die Antworten auf die fünf Fragen weiter unten vorliegen.
Ein ablaufendes Zertifikat ist im Übrigen ein Fall, den eine einfache Erreichbarkeitsprüfung unter Umständen nicht bemerkt: Der Server antwortet ja, nur eben mit einem Zertifikat, das der Browser ablehnt. Ob eine Prüfung das erkennt, hängt davon ab, ob sie Zertifikatsfehler auswertet. Wie eine Überwachung der Erreichbarkeit aufgebaut ist und was sie abdeckt, ist ein eigenes Thema. Für das Zertifikat genügt eine schlichte Regel in der Pflegeroutine für die Website: Einmal im Monat das Ablaufdatum aller Adressen ansehen und mit dem Datum der letzten Verlängerung vergleichen.
Fünf Fragen an den eigenen Dienstleister
Die meisten Betriebe verlängern ihr Zertifikat nicht selbst, sondern haben es mit dem Hosting oder dem Website-Vertrag an einen Dienstleister gegeben. Das ist vernünftig, solange klar ist, was dort geschieht.
Die folgenden fünf Fragen lassen sich per E-Mail stellen und in wenigen Zeilen beantworten. Wer die Antworten schriftlich hat, weiß danach, ob die nächste Laufzeitstufe ein Thema ist oder nicht.
- Wer verlängert das Zertifikat für unsere Adressen, und unter welchem Namen läuft der Auftrag bei Ihnen?
- Geschieht die Verlängerung automatisch oder von Hand, und ist der Ablauf auf die Höchstlaufzeiten von 100 Tagen ab März 2027 und 47 Tagen ab März 2029 eingestellt?
- Wer wird benachrichtigt, wenn eine Verlängerung scheitert, auf welchem Weg und wie schnell?
- Sind alle Adressen abgedeckt: mit und ohne www, Nebenadressen, Zusatzdomains und Weiterleitungen?
- Wo kann ich das Ablaufdatum selbst nachsehen, ohne Sie jedes Mal fragen zu müssen?
Tabelle waagerecht wischen
| Antwort des Dienstleisters | Was sie bedeutet | Nächster Schritt |
|---|---|---|
| „Das läuft automatisch.“ | Ein guter Anfang, aber noch unvollständig: Offen ist, wer einen Fehlschlag bemerkt. | Frage 3 nachreichen und die Antwort schriftlich festhalten |
| „Wir verlängern einmal im Jahr.“ | Das Verfahren stammt aus der Zeit vor dem 15.03.2026 und passt nicht mehr zur Höchstlaufzeit. | Umstellung vereinbaren, bevor das nächste Zertifikat ausläuft |
| „Sie bekommen eine Mail vor dem Ablauf.“ | Die Erinnerung ersetzt keine Verlängerung und hängt an einem Postfach, das gelesen werden muss. | Empfängeradresse prüfen und klären, wer handelt, wenn die Mail kommt |
| „Die Hauptadresse ist abgedeckt.“ | Nebenadressen und Weiterleitungen sind möglicherweise nicht dabei. | Die Adressliste schicken und Zeile für Zeile bestätigen lassen |
| „Das sehen Sie nicht, das machen wir.“ | Sie haben keinen eigenen Einblick in den Zustand. | Ablaufdatum im Browser selbst nachsehen und im Kalender notieren |
Keine dieser Antworten ist für sich ein Grund zur Sorge. Sie zeigen nur, an welcher Stelle ein Ablauf von einer einzelnen Person abhängt, die gerade im Urlaub sein könnte. Wichtig ist der Zeitpunkt: Die nächste Stufe greift für Zertifikate, die ab dem 15. März 2027 ausgestellt werden (CA/Browser Forum). Wer die Fragen im Herbst 2026 stellt, hat also mehrere Monate Vorlauf, um ein Verfahren in Ruhe umzustellen, statt es unter Zeitdruck zu reparieren.
Das Ablaufdatum selbst nachsehen
So läuft es bei XICflow
Bei XICflow gehört das Zertifikat zum Verbinden der Domain. Nach der ersten Veröffentlichung ist eine Website zunächst unter einer Vorschauadresse der Form ihr-kurzname.xicflow.com erreichbar, und diese Adresse ist verschlüsselt.
Wird eine eigene Domain verbunden, durchläuft die Aktivierung mehrere Schritte; einer davon heißt „3 · Zertifikat ausstellen“. Dabei erscheint die Meldung „Domain wird aktiviert (SSL-Zertifikat wird ausgestellt).“, und XICflow vermerkt das Ablaufdatum des Zertifikats. In der Domainübersicht tragen aktive Domains zusätzlich die Kennzeichnung „SSL“; sie bedeutet, dass für diese Adresse eine Verschlüsselung eingerichtet ist. Wie die einzelnen Schritte ablaufen und was bei einer Meldung zu tun ist, beschreibt das Handbuch zum Veröffentlichen und Verbinden von Domains.
Die Domain selbst bleibt dabei, wo sie ist. Sie ändern bei Ihrem Anbieter nur die DNS-Einträge; die Domain bleibt in Ihrem Besitz und bei Ihrem Anbieter. Für Adressen, die nicht über XICflow laufen, etwa einen Shop oder ein Buchungssystem bei einem anderen Anbieter, gilt der Abschnitt über Nebenadressen weiter: Deren Zertifikat liegt bei dem Anbieter, der sie betreibt, und gehört mit auf die Adressliste. Einen Überblick über den Funktionsumfang gibt die Seite mit den Leistungen von XICflow; wie eine Website von der Vorschau bis zur eigenen Domain entsteht, zeigen die ersten Schritte im Handbuch.
Was am Ende zählt