Die Seite ist „kaputt" — dabei läuft der Server

Stellen Sie sich vor, ein Kunde meldet, Ihre Website lasse sich nicht öffnen. Der Browser zeigt eine Warnung über eine unsichere Verbindung, kein Inhalt, nur eine rote Fehlerseite. Sie prüfen Ihren Server — er läuft einwandfrei. Die Datenbank antwortet, die Anwendung ist gesund, im Rechenzentrum ist alles in Ordnung. Trotzdem kommt niemand mehr auf Ihre Seite.

Genau diese Situation hat im Juni 2026 viele Betreiber getroffen. Schuld war nicht der eigene Server, sondern eine Schicht davor: die Verschlüsselung, über die der Browser eine sichere Verbindung aufbaut. Bei Cloudflare, einem der größten Anbieter für diese Schicht, kam es mehrfach zu Störungen bei den TLS-Zertifikaten. Die Server der Kunden liefen — erreichbar waren sie für einen Teil der Besucher trotzdem nicht.

Auf einen Blick

  • Nicht der Server fiel aus, sondern die Verschlüsselungsschicht davor — die Website war für betroffene Besucher unerreichbar, obwohl im Hintergrund alles lief.
  • Cloudflare hatte im Juni 2026 laut eigenen Statusmeldungen wiederkehrende Probleme mit Zertifikatsketten, die TLS-Verbindungen brechen ließen; die Störungen wurden jeweils zügig behoben.
  • Das Lehrstück dahinter: Zwischen Besucher und Server liegen mehrere Schichten — DNS, CDN, TLS-Zertifikat. Jede kann eigenständig ausfallen.
  • Der praktische Schluss ist nicht „weg von Cloudflare", sondern: eigene Erreichbarkeit unabhängig überwachen und einen Notfall-Ansprechpartner festlegen.

Was die TLS- und Zertifikatsschicht überhaupt ist

Wenn ein Browser Ihre Website öffnet, passiert mehr, als die meisten vermuten. Zuerst muss er die Adresse auflösen, also herausfinden, welcher Server hinter Ihrem Domainnamen steckt — das übernimmt das DNS. Dann läuft die Verbindung bei vielen Unternehmen nicht direkt zum Server, sondern über ein vorgelagertes Netz, ein sogenanntes CDN, das Inhalte schneller ausliefert und vor Angriffen schützt. Und bevor irgendein Inhalt fließt, handeln Browser und Server eine verschlüsselte Verbindung aus. Den Beweis, dass die Gegenstelle echt ist, liefert ein TLS-Zertifikat.

Dieses Zertifikat ist der unscheinbare, aber entscheidende Baustein. Stimmt damit etwas nicht — ist es abgelaufen, falsch zusammengesetzt oder lässt es sich nicht prüfen —, dann verweigert der Browser die Verbindung. Nicht aus Schikane, sondern aus gutem Grund: Eine Verbindung, deren Echtheit nicht belegt ist, gilt als unsicher. Für den Besucher sieht das Ergebnis allerdings gleich aus, egal ob Ihr Server brennt oder nur das Zertifikat klemmt: Die Seite ist nicht erreichbar.

Viele KMU lassen genau diese Schichten von einem Dienst wie Cloudflare übernehmen. Das ist sinnvoll und meist sicherer als die Eigenbastelei, weil solche Anbieter Verschlüsselung, Zertifikatserneuerung und Schutzmechanismen automatisiert und rund um die Uhr betreuen. Der Preis dafür ist eine Abhängigkeit, die im Alltag unsichtbar bleibt — bis sie es nicht mehr ist.

Was im Juni 2026 passiert ist

Im Juni 2026 traf genau diese Schicht eine Serie von Störungen. Nach den öffentlich einsehbaren Statusmeldungen von Cloudflare lag die Ursache in der Art und Weise, wie Zertifikatsketten zusammengesetzt wurden: Ein Baustein in der Kette passte nicht, sodass Browser die Verbindung nicht mehr als vertrauenswürdig einstufen konnten. Die TLS-Aushandlung brach ab, und betroffene Websites waren für einen Teil ihrer Besucher nicht erreichbar — obwohl die dahinterliegenden Server normal weiterliefen.

Das Tückische war die Wiederholung. Nach einem ersten Vorfall Anfang Juni trat dieselbe Ursache wenige Tage später erneut auf. Auch danach gab es weitere zertifikatsbezogene Verzögerungen, zuletzt um den 21. und 22. Juni, sowie geplante Wartungsarbeiten an einzelnen Standorten. Wir verzichten hier bewusst auf minutengenaue Zeitangaben, weil sich die exakte Dauer der einzelnen Störungen aus den verfügbaren Quellen nicht zweifelsfrei rekonstruieren lässt. Festhalten lässt sich: Es war kein einmaliger Ausrutscher, sondern ein Muster über mehrere Wochen.

Wichtig zur Einordnung: Cloudflare hat die Störungen jeweils zügig erkannt und behoben, betroffene Zertifikatsketten automatisch neu aufgebaut und Kunden mit dringendem Bedarf einen Weg gelassen, kurzfristig Ersatz zu beschaffen. Der Dienst bleibt für viele Unternehmen die richtige Wahl. Es geht hier nicht darum, einen Anbieter schlechtzureden — auch der sorgfältigste hat Vorfälle. Es geht um die Lehre dahinter.

Warum diese Abhängigkeit ein eigenes Risiko ist

Die meisten Notfallpläne in kleinen Unternehmen drehen sich um den Server: Backup, Wiederherstellung, ein Ersatzgerät. Was dabei oft übersehen wird, ist die Kette davor. DNS, CDN und Zertifikat sind drei eigenständige Schichten, und jede kann ausfallen, ohne dass an Ihrem Server irgendetwas falsch ist. Die Juni-Vorfälle führen das deutlich vor: Ein gesunder Server nützt nichts, wenn die Schicht, die ihn nach außen erreichbar macht, gerade nicht funktioniert.

Hinzu kommt ein blinder Fleck beim Thema Überwachung. Wer ausschließlich prüft, ob der eigene Server antwortet, sieht eine solche Störung gar nicht — der Server meldet ja „alles in Ordnung". Dass Besucher draußen vor verschlossener Tür stehen, bemerken Sie in diesem Fall zuletzt, nämlich erst durch verärgerte Anrufe. Genau diese Lücke lässt sich schließen, und zwar mit überschaubarem Aufwand.

Was Sie jetzt tun sollten

Die eigenen Schichten kennen

Verschaffen Sie sich Klarheit darüber, welcher Anbieter bei Ihnen welche Schicht betreut. Wo liegt das DNS? Läuft der Verkehr über ein CDN, und über welches? Wer stellt das TLS-Zertifikat aus, und wie wird es erneuert? Diese Fragen klingen technisch, sind aber im Kern eine simple Bestandsaufnahme. Wer nicht weiß, woraus die Kette besteht, kann im Ernstfall nicht gezielt prüfen, wo es hakt — und verliert wertvolle Zeit mit Raten.

Zertifikatsablauf und -erneuerung überwachen

TLS-Zertifikate haben eine Laufzeit und werden heute meist automatisch erneuert. Das funktioniert zuverlässig — bis es das einmal nicht tut, etwa wegen einer Fehlkonfiguration wie im Juni. Verlassen Sie sich deshalb nicht blind auf die Automatik, sondern lassen Sie zusätzlich überwachen, ob das Zertifikat gültig, korrekt zusammengesetzt und rechtzeitig vor Ablauf erneuert ist. Eine frühzeitige Warnung verwandelt einen drohenden Totalausfall in eine ruhige Korrektur.

Erreichbarkeit unabhängig überwachen

Lassen Sie Ihre Website von außen prüfen, und zwar so, wie ein echter Besucher sie sieht — über einen Dienst, der von außerhalb Ihrer eigenen Infrastruktur regelmäßig die vollständige Verbindung samt Verschlüsselung testet. So bemerken Sie eine Zertifikats- oder CDN-Störung in Minuten und nicht erst, wenn Kunden sich beschweren. Wichtig ist, dass diese Überwachung unabhängig vom betroffenen Anbieter läuft — sonst fällt im Zweifel beides gleichzeitig aus.

Einen Notfall-Ansprechpartner festlegen

Klären Sie vorab, wer im Störungsfall handelt. Wer hat Zugang zum DNS und zum CDN-Konto? Wer kann ein Zertifikat neu ausstellen oder den Verkehr notfalls umleiten? Halten Sie diese Zuständigkeiten samt Zugängen an einem sicheren, auch offline erreichbaren Ort fest. Im Ernstfall entscheidet nicht die Technik allein, sondern die Frage, ob jemand weiß, was zu tun ist — und die nötigen Rechte dafür hat.

Unsere Einschätzung

Die Cloudflare-Störungen im Juni 2026 sind kein Grund zur Panik und auch kein Argument gegen den Dienst. Sie sind eine nützliche Erinnerung daran, dass „Server läuft" und „Website erreichbar" nicht dasselbe sind. Zwischen beiden liegen Schichten, die viele Unternehmen gar nicht auf dem Schirm haben — bis eine davon ausfällt.

Die gute Nachricht: Sie müssen dafür kein Großprojekt aufsetzen. Zu wissen, wer welche Schicht betreut, das Zertifikat im Auge zu behalten, die Erreichbarkeit von außen zu überwachen und eine klare Zuständigkeit für den Ernstfall zu haben — das reicht bereits, um nicht mehr der Letzte zu sein, der von einer Störung erfährt. Wenn Sie nicht sicher sind, wie Ihre Kette aufgebaut ist und wo die Lücken liegen, schauen wir uns das gern mit Ihnen an.