Die Fehlermeldung, die auf das falsche Problem zeigt
Über sechs Maschinen hinweg verlor die Verwaltungsebene unserer Backup-Cloud den Kontakt. Immer dasselbe Bild: Die TCP-Verbindung kam zustande, der Handshake begann, dann sechzig Sekunden Stille — und am Ende die Meldung, das Zertifikat sei nicht vertrauenswürdig.
Am Wochenende davor hatten wir planmäßig ein SSL-Zertifikat getauscht.
Diese beiden Sätze haben uns einen halben Tag gekostet.
Sechzig Sekunden sind keine Zufallszahl
Ein echtes Zertifikatsproblem scheitert sofort. Sobald die Kette vorliegt, ist die Prüfung entweder bestanden oder nicht — dafür braucht niemand eine Minute. Sechzigtausend Millisekunden sind kein Messwert, sondern ein konfigurierter Grenzwert. Was so aussieht, ist ein Transportproblem, kein Vertrauensproblem.
Wir haben trotzdem erst das Naheliegende geprüft: Kette, Bindung, Pinning, privater Schlüssel. Alles sauber. Jede einzelne Prüfung hat uns bestätigt, dass wir an der falschen Stelle suchen — und wir haben es als Zwischenstand verbucht statt als Hinweis.
Eine Fehlermeldung beschreibt, wo eine Software aufgibt. Nicht, warum.
Der Agent kann einen abgebrochenen Handshake nicht von einem ungültigen Zertifikat unterscheiden. Er meldet, was er zuletzt in der Hand hatte. Dass die Meldung in die Irre führt, merkt man nur an der runden Zahl daneben.
Drei Störer, einer nach dem anderen
Darunter lag, so schien es, kein Fehler, sondern drei — und jeder hielt das Symptom am Leben, nachdem der vorige behoben war.
Ein Betriebssystem-Update, das zwei Wochen unsichtbar lag. Unser erster Verdächtiger. Eingespielt hatte es sich automatisch, vierzehn Tage vor dem ersten Ausfall; der Zertifikatstausch am Wochenende war der erste erzwungene Neuaufbau aller Verbindungen danach. Die zeitliche Nähe reichte uns als Motiv.
Ein Neustart mitten im laufenden Deployment. Für die Deinstallation des Updates starteten wir einen Server neu, während eine Agent-Konfiguration bei sechzig Prozent lief. Ergebnis: ein inkonsistenter Zustand und derselbe Fehler auf einer Maschine, die bereits bereinigt war. Zwei Stunden Fehlersuche an einem Problem, das wir uns selbst gemacht hatten — der einzige des Tages, den wir vollständig zu verantworten hatten.
Ein EDR-Agent im Zwitterzustand. Der lehrreichste Befund. Auf beiden Servern galt der Agent seit Wochen als deaktiviert — allerdings nur auf Richtlinienebene. Auf dem Betriebssystem liefen seine Dienste, seine Netzwerkfilter waren im Stack registriert, und auf einer Maschine stand er seit unbekannter Zeit auf „Deinstallation ausstehend". Ein halb abgebauter Sicherheitsagent mit undefiniertem Verhalten genau dort, wo die Verschlüsselung ausgehandelt wird.
„Deaktiviert" heißt bei einem EDR nicht „wirkungslos". Wer ihn als Fehlerquelle ausschließen will, prüft auf Betriebssystemebene: Laufen die Dienste? Sind die Filtertreiber geladen? Hängt eine Deinstallation fest? Die Verwaltungskonsole beantwortet keine dieser Fragen.
Der Beweis, der keiner war
Nach der Deinstallation des Updates und einem Neustart lief der Handshake in Millisekunden durch. Sauberer geht ein Beleg kaum.
Er hat trotzdem nicht gehalten.
Am nächsten Morgen war die Störung zurück — die Update-Sperre hatte nicht gegriffen, und über Nacht war es erneut installiert worden. An dem Morgen haben wir vorsorglich unsere Partner vor dem Update gewarnt. Und wir haben daraufhin alles durchgetestet, was auf unserer Seite möglich war, bis hin zur vollständigen Neuinstallation der betroffenen Komponente. Der Fehler trat bei der fabrikneuen Installation identisch auf.
Damit fiel unsere eigene These. Eine Komponente ohne Vorgeschichte, ohne Altlast, ohne unsere Konfiguration — und dasselbe Verhalten. Das Update kann also nicht die vollständige Erklärung sein. Entweder ist es einer von mehreren Auslösern, oder der eine erfolgreiche Durchlauf hatte einen anderen Grund als angenommen. Vielleicht schlicht den Neustart.
Denn beim vermeintlichen Beweis hatten wir zwei Dinge auf einmal verändert: das Update entfernt und die Maschine neu gestartet. Ein Beleg, bei dem mehr als eine Variable bewegt wurde, belegt gar nichts. Das ist keine neue Erkenntnis — sie fällt einem nur nicht auf, wenn das Ergebnis das gewünschte ist.
Was wir bewusst nicht getan haben
Der Fall ging an die Herstellerentwicklung. Wir hätten längst einen Umweg fahren und die Verwaltungsebene wieder zum Laufen bringen können.
Wir haben es nicht getan, sondern die Umgebung im Analysezustand gelassen. Ein Hersteller kann eine Ursache nur beheben, solange sie reproduzierbar vorliegt — wer vorher aufräumt, tauscht die Behebung gegen eine Wiederkehr. Das ist eine Abwägung, die man aktiv trifft und der Kundenseite erklärt: eine bekannte, benannte Einschränkung gegen eine unbekannte Wahrscheinlichkeit, dass es wiederkommt.
Wichtig dabei, und der Grund, warum diese Abwägung überhaupt vertretbar war: Die Sicherungen selbst liefen die ganze Zeit durch. Betroffen war ausschließlich die Ebene, die darüber berichtet. Hätte es die Backups getroffen, wäre die Entscheidung eine andere gewesen — dann ist Wiederherstellen wichtiger als Verstehen.
Ein Vorschlag des Herstellersupports ging uns dabei zu weit: die betroffene Komponente aus der Verwaltung zu entfernen und neu aufzunehmen. In einer Umgebung mit vielen angebundenen Partnern und deren Endkunden ist das kein Handgriff, sondern ein Kollateralschaden. Wir haben begründet abgelehnt, und der Fall ließ sich ohne diesen Schritt zu Ende führen. Ein Support-Mitarbeiter kennt die Größe der Umgebung nicht, in der sein Vorschlag landet.
Wie es ausging
Die Entwicklung des Herstellers hat die Ursache bestätigt — aus dem Paketmitschnitt, den wir aus der stehengelassenen Umgebung liefern konnten: ein Fehler in der Verbindungsverarbeitung, der nur unter hoher gleichzeitiger Last auftritt, wenn viele Agenten auf einmal ihre Verbindung neu aufbauen. Genau das passiert nach einem Zertifikatstausch. Den Fix bekamen wir zuerst als Einzelbuild für unseren Fall; zwei Tage später erschien er als regulärer Build mit einem Eintrag in den Release Notes. Das Betriebssystem-Update, das wir zwei Tage lang für den Täter hielten, war nach Aussage der Entwicklung nicht ursächlich. Der EDR war am Ende auch nicht beteiligt — den Aufräumbedarf hatte er trotzdem.
Der eine „Beweis" mit der Deinstallation hatte mit dem Update also nichts zu tun. Warum er an dem Tag gelang, wissen wir nicht sicher — wahrscheinlich, weil nach dem Neustart weniger Agenten gleichzeitig ankamen als nach dem Zertifikatstausch. Die Warnung an unsere Partner haben wir zurückgenommen.
Was hier in einem Absatz steht, hat siebzehn Tage gedauert — und der Fix brachte ein zweites Problem mit, das größer war als das erste. Beides sind eigene Geschichten: 208 Bytes, dann Stille erzählt, wie aus „bitte neu installieren" ein Fall für die Entwicklung wurde. Und Das Backup-Unternehmen, das sich mit dem eigenen Backup rettete , wie es weiterging, als der Fix da war.
Was bleibt
Was wir mitnehmen, hängt an keinem Hersteller:
Nach jedem Fix isoliert nachweisen, dass er gewirkt hat. Nicht prüfen, ob das Gesamtsymptom verschwunden ist. Bei gestapelten Ursachen sieht ein wirksamer Fix genauso aus wie ein wirkungsloser, solange der nächste Störer das Symptom trägt.
Beim Nachweis immer nur eine Sache verändern. Sonst hat man am Ende ein Ergebnis und zwei Erklärungen.
Zeitgleiche Änderungen entkoppeln. Ein Betriebssystem-Patch und ein Zertifikatstausch im selben Fenster machen jede Korrelation wertlos. Wir haben beides zugelassen und dafür zwei Tage bezahlt.
Und der Satz, der uns diese Runde teuer geworden ist: Die Meldung beschreibt die Stelle, an der die Software aufgibt. Zur Ursache sagt sie nichts. Genauso wenig wie dreißig Wiederherstellungspunkte etwas über dreißig Tage sagen — oder ein Job-Name über die Aufbewahrung, die tatsächlich eingestellt ist.