#Hosting · 4 Min. Lesezeit · Tim Rinkel

AUSFALL-WOCHENENDE! Bei Cloudflare brennt’s gleich doppelt — Dallas-Panne und ein TLS-Bug legen Webseiten lahm

AUSFALL-WOCHENENDE! Bei Cloudflare brennt’s gleich doppelt — Dallas-Panne und ein TLS-Bug legen Webseiten lahm

Ein unruhiges Wochenende für Cloudflare: Gleich zwei Störungen trafen den Infrastruktur-Riesen kurz hintereinander. Erst zickten bestimmte Let’s-Encrypt-Zertifikate, dann legte eine Hardware-Panne im Rechenzentrum Dallas Teile des Traffics lahm. Wir fassen ruhig zusammen, was passiert ist — und was du daraus mitnehmen kannst.

Panne 1: Hardware-Fehler in Dallas

Am Samstag, 6. Juni, sorgte ein Hardware-Defekt im Cloudflare-Rechenzentrum in Dallas, Texas für Probleme. Ab dem späten Nachmittag (Ortszeit) häuften sich HTTP-500-Fehler und erhöhte Latenzen für Traffic, der über dieses Rechenzentrum lief. Die gute Nachricht: Cloudflare hatte das Problem nach rund 20 Minuten im Griff. Wer Pech hatte, sah in diesem Fenster kurzzeitig Fehlermeldungen statt der gewünschten Seite.

Panne 2: Der Let’s-Encrypt-Zertifikatsfehler

Schon am Freitag, 5. Juni, hatte Cloudflare ein anderes Problem entdeckt: Bei einem Teil der Let’s-Encrypt-Zertifikate sorgte eine fehlerhafte Bündelung der Zertifikatskette (im Fachjargon „unsupported CA bundling“) dafür, dass die TLS-Verbindung für manche Besucher scheiterte. Im Klartext: Einige Nutzer kamen nicht sicher auf betroffene Seiten, weil der Browser der Zertifikatskette nicht traute.

Und noch eine Kleinigkeit

Obendrein meldete Cloudflare Verzögerungen beim Benachrichtigungs-Produkt — manche Alerts kamen verspätet an. Das betraf laut Cloudflare ausschließlich die Benachrichtigungen, nicht die eigentliche Sicherheits-, CDN- oder Netzwerk-Funktion. Kein Drama, aber ein weiteres Puzzlestück eines turbulenten Wochenendes.

Was lernen wir daraus?

Cloudflare leitet einen gewaltigen Teil des weltweiten Web-Traffics. Wenn dort etwas hakt, spürt es das halbe Internet — auch wenn die einzelnen Vorfälle hier schnell eingedämmt waren. Das ist die Kehrseite der Zentralisierung: enorme Effizienz, aber eben auch ein gemeinsamer Single Point of Failure. Solche Wochenenden sind eine nüchterne Erinnerung daran, dass „die Cloud“ eben doch aus echten Rechenzentren mit echter Hardware besteht.

Was du konkret tun kannst

Für die meisten gilt: abwarten und kurz prüfen. Wenn deine Seite über Cloudflare läuft und Besucher Fehler melden, lohnt ein Blick auf die offizielle Status-Seite, bevor du in Panik deine eigene Konfiguration zerlegst. Wer es robuster mag, denkt über Monitoring und einen Fallback nach — etwa eine zweite Auflösung per DNS oder eine schlanke Status-Seite außerhalb des Hauptanbieters. Und bei TLS-Themen hilft es, die eigene Zertifikatskette sauber zu halten und ab und zu mit einem externen Checker zu testen.

Single Point of Failure — und die Alternative

Das Wochenende zeigt ein Muster, das uns immer wieder begegnet: Wenige große Anbieter tragen einen Riesenteil des Internets. Das ist bequem und meist extrem stabil — bis es das eben kurz nicht ist. Komplett entkommen kannst du dem nicht, aber du kannst die Abhängigkeit streuen. Ein zweiter DNS-Anbieter, ein unabhängiger Status-Endpunkt und sauberes Monitoring sorgen dafür, dass du im Ernstfall schnell siehst, ob das Problem bei dir oder beim großen Dienstleister liegt. Diese Minuten Klarheit sparen dir im Stress eine Menge Fehlersuche.

Häufige Fragen

Was war bei Cloudflare am Wochenende los?
Zwei Störungen: Am 6. Juni führte ein Hardware-Defekt im Rechenzentrum Dallas zu HTTP-500-Fehlern und Latenz, behoben nach rund 20 Minuten. Schon am 5. Juni verursachte ein fehlerhaft gebündeltes Let’s-Encrypt-Zertifikat TLS-Verbindungsprobleme für manche Besucher.
War meine Webseite betroffen?
Nur, wenn dein Traffic über das Dallas-Rechenzentrum lief oder ein betroffenes Let’s-Encrypt-Zertifikat im Spiel war. Viele Seiten merkten gar nichts. Im Zweifel zeigt die offizielle Cloudflare-Status-Seite, was wann gestört war.
Was bedeutet ‚unsupported CA bundling‘?
Dabei ist die Kette der Zertifikate fehlerhaft zusammengestellt, sodass der Browser ihr nicht vollständig vertrauen kann. Folge: Die verschlüsselte TLS-Verbindung scheitert für manche Besucher, obwohl das Zertifikat an sich gültig ist.
Wie schütze ich mich vor solchen Ausfällen?
Ganz verhindern kannst du fremde Infrastruktur-Pannen nicht. Aber Monitoring, eine saubere Zertifikatskette und ein Fallback — etwa eine zweite DNS-Auflösung oder externe Status-Seite — reduzieren den Schaden, wenn ein großer Anbieter mal wackelt.

Quellen

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert