Ein Zertifikat nur für sich selbst

Die Warnung, die im ersten Moment falsch wirkt

Wer JiCo zum ersten Mal im Browser öffnet, sieht etwas, das zunächst misstrauisch macht: eine Zertifikatswarnung, wie man sie sonst von schlecht gepflegten Webseiten kennt. Das wirkt paradox für ein Programm, das ausschließlich lokal läuft und nie das eigene Gerät verlässt — warum überhaupt eine HTTPS-Verbindung, wenn Absender und Empfänger derselbe Rechner sind?

Die Antwort liegt genau in dem, was über diese Verbindung tatsächlich läuft: das Jira-Zugangstoken, die Freigabe-Entscheidungen, der gesamte Chat mit dem Modell. Eine unverschlüsselte lokale Verbindung wäre zwar bequemer, aber angreifbar für jedes andere Programm auf demselben Rechner, das mitzulesen versucht — ein Klartext-Protokoll für ausgerechnet die sensibelste Verbindung im ganzen System wäre die falsche Stelle zum Sparen.

Ein Zertifikat, das nur eine einzige Aufgabe hat

Das Panel stellt sich deshalb selbst ein Zertifikat aus — ausdrücklich ohne die Rechte einer echten Zertifizierungsstelle. Es gilt ausschließlich für 127.0.0.1 und localhost, kann also niemals für eine andere Adresse missbraucht werden, selbst wenn es kopiert würde. Die Gültigkeit ist auf höchstens 825 Tage begrenzt — dieselbe Obergrenze, die große Browserhersteller inzwischen für alle Zertifikate durchsetzen, weil ein kürzeres Zeitfenster die Folgen eines gestohlenen privaten Schlüssels begrenzt.

Damit der Browser dieses Zertifikat überhaupt als vertrauenswürdig anzeigt, muss es einmalig im Schlüsselbund des Systems (macOS) beziehungsweise im Zertifikatspeicher des Benutzers (Windows) eingetragen werden — mit ausdrücklicher Rückfrage beim Panel-Start, nicht automatisch im Hintergrund. Dieser Schritt wird protokolliert, mit Fingerabdruck des Zertifikats, und lässt sich über denselben Weg wieder entfernen.

Warum diese Rückfrage kein Kontrollverlust ist

Ein selbstsigniertes Zertifikat im eigenen Schlüsselbund einzutragen bedeutet formal, dem System ein Stück weit zu vertrauen — deshalb ist genau dieses Vertrauen in JiCos eigenem Prüfprogramm für Sicherheitsverantwortliche als das benannt, was es ist: eine Grenze, keine unsichtbare Nebensache. Das System selbst begrenzt dieses Vertrauen technisch so eng wie möglich: Die Werkzeuge, mit denen ein Zertifikat überhaupt in den Systemspeicher eingetragen werden kann (security unter macOS, certutil unter Windows), lässt der Egress-Wächter ausdrücklich nur mit genau den Unterbefehlen zu, die für dieses eine, konkrete Zertifikat nötig sind — nicht als generelle Erlaubnis für beliebige Zertifikatsoperationen.

Wer die Details zentral steuern möchte, statt jede Rückfrage einzeln zu beantworten, kann das Zertifikat auch per Mobile-Device-Management an alle Rechner im Unternehmen verteilen — ein Weg, der für IT-Abteilungen ohnehin der übliche ist, wenn viele gleichartige Installationen anstehen.

Nicht jedes Betriebssystem behandelt das gleich

macOS und Windows bringen beide einen eigenen, systemweiten Zertifikatspeicher mit, in den sich das Panel-Zertifikat mit einer einzigen Rückfrage eintragen lässt — dort verankert es der jeweilige Systemdialog, den JiCo direkt anspricht. Unter Linux gibt es diesen einen gemeinsamen Speicher in dieser Form nicht; dort unterscheidet sich der Weg zusätzlich je nach verwendetem Browser, weshalb JiCo an dieser Stelle auf eine ausführlichere Anleitung verweist, statt einen einzigen automatisierten Schritt zu versprechen, den es technisch gar nicht einheitlich geben kann. Das ist kein Vorwand, um Linux schlechter zu unterstützen, sondern eine ehrliche Konsequenz der unterschiedlichen Vertrauensmodelle der jeweiligen Plattform.

Was diese Konstruktion bewusst nicht ist

Ein selbstsigniertes, auf Loopback-Adressen beschränktes Zertifikat ist ausdrücklich keine echte Zertifizierungsstelle — es kann kein weiteres Zertifikat für irgendeine andere Adresse ausstellen und wäre für einen Angreifer wertlos, selbst wenn er es in die Hände bekäme, solange er nicht auch physischen oder administrativen Zugriff auf genau diesen einen Rechner hat. Das ist der entscheidende Unterschied zu einer kompromittierten öffentlichen Zertifizierungsstelle, deren Missbrauch ganz andere Kreise ziehen könnte.

Die ehrliche Kehrseite steht ebenfalls im eigenen Prüfprogramm: Wer lokale Administratorrechte auf dem Gerät hat, kann sich grundsätzlich jede Datei der lokalen Ablage aneignen — auch unter Windows mit einer eingeschränkten Zugriffsliste. Das Zertifikat allein schützt also nicht vor einem kompromittierten Administratorkonto; dagegen hilft nur die Geräteverwaltung selbst, also die Frage, wer überhaupt Administratorrechte besitzt, und eine ordentliche Festplattenverschlüsselung.

Eine kleine Entscheidung mit großer Symbolkraft

Ein einzelnes, lokal begrenztes Zertifikat wirkt auf den ersten Blick wie eine technische Fußnote. Es ist aber ein anschauliches Beispiel für ein Muster, das sich durch JiCo insgesamt zieht: statt sich auf eine einzige, bequeme Maßnahme zu verlassen, mehrere Schichten übereinanderzulegen, die sich gegenseitig eng begrenzen — ein Zertifikat, das nur für sich selbst gilt, eine Wache, die nur zwei konkrete Systembefehle erlaubt, eine Rückfrage, die niemals stillschweigend übersprungen wird. Klein für sich genommen, aber konsequent an jeder einzelnen Stelle durchgehalten.