Eigenes Stammzertifikat (CA)

Den Rechner, auf dem der Outpost läuft, ein internes Stammzertifikat vertrauen lassen, wenn euer Netz TLS aufbricht.

Viele Unternehmensnetze prüfen ausgehendes HTTPS: eine Firewall oder ein Web-Proxy entschlüsselt die Verbindung und verschlüsselt sie mit einem eigenen Stammzertifikat neu. Für den Outpost sieht das aus wie ein fremdes Zertifikat auf bridge.meingpt.com — und er bricht ab, denn genau das soll er tun.

Damit er trotzdem arbeitet, muss der Rechner selbst eurem Stammzertifikat vertrauen. Es gibt dafür keine Einstellung im Outpost — das Zertifikat gehört in den Zertifikatspeicher des Betriebssystems, auf dem der Outpost läuft.

Woran ihr erkennt, dass es das ist

Der Reiter Verbindung und der Assistent haben denselben Knopf: Prüfung starten. Die Prüfung TLS-Zertifikat schlägt dann fehl und nennt den Aussteller — bei den verbreiteten Appliances mit Namen, etwa Zscaler Root CA. Das ist die eindeutige Diagnose; ohne sie ist eine gescheiterte Kopplung genauso oft eine Firewallregel oder ein Proxy.

Erst prüfen, dann handeln

Ein Stammzertifikat auszurollen, weil die Kopplung nicht funktioniert, ist Raten. Lasst die Prüfung laufen: sie sagt euch, ob DNS, TCP, TLS, die Erreichbarkeit von meinGPT oder die Systemuhr das Problem ist.

Einrichten

Zertifikat besorgen

Fragt die IT nach dem Stamm-CA-Zertifikat eurer TLS-Inspektion, im PEM-, CRT- oder CER-Format.

Falls die Kette aus Stamm- und Zwischenzertifikaten besteht, braucht der Rechner beide — die meisten Verteilwege (Gruppenrichtlinie, MDM) rollen ohnehin die ganze Kette aus.

In den Zertifikatspeicher des Betriebssystems aufnehmen

Das ist eine Einstellung des Betriebssystems, nicht des Outpost:

  • Windows: meist bereits per Gruppenrichtlinie erledigt — der Admin, der die TLS-Inspektion betreibt, rollt das Stammzertifikat üblicherweise ohnehin auf verwaltete Rechner aus. Manuell geht es über certlm.mscVertrauenswürdige StammzertifizierungsstellenZertifikate importieren.
  • macOS: Zertifikat in Schlüsselbundverwaltung importieren (Bereich System), dann im Zertifikat unter Vertrauen auf Immer vertrauen setzen.
  • Linux: Zertifikat nach /usr/local/share/ca-certificates/ (Debian/Ubuntu) bzw. /etc/pki/ca-trust/source/anchors/ (RHEL/Fedora) legen und update-ca-certificates bzw. update-ca-trust ausführen.

Der Outpost liest bei jedem Verbindungsaufbau diesen Speicher — es ist derselbe, dem auch der Browser des Rechners vertraut.

Erneut prüfen

Outpost neu starten, dann Prüfung starten. Steht TLS-Zertifikat auf bestanden, ist es erledigt; die Kopplung funktioniert danach.

Bleibt die Prüfung rot, ist die Kette im Betriebssystem meistens unvollständig — fragt die IT nach den Zwischenzertifikaten und nehmt auch sie in den Speicher auf.

Was das betrifft

Der Zertifikatspeicher des Betriebssystems gilt für alle ausgehenden Verbindungen des Outpost: den Tunnel zu meinGPT, die meinGPT-API, und einen eigenen Embedding-Endpoint, falls ihr einen nutzt. Öffentlich vertrauenswürdige Zertifikate bleiben davon unberührt — euer Stammzertifikat kommt hinzu, es ersetzt nichts.

Ist euer Stammzertifikat auf dem Rechner bereits per Gruppenrichtlinie oder MDM ausgerollt — der Normalfall auf einem verwalteten Firmenrechner —, braucht ihr diese Seite nicht: der Outpost vertraut dem, was der Rechner vertraut, ohne weiteres Zutun.

Grenzen

  • Das gilt für den Rechner, nicht nur für den Outpost. Es gibt keine Möglichkeit, das Vertrauen auf den Outpost allein zu begrenzen — wer den Zertifikatspeicher des Betriebssystems ändert, ändert ihn für jede Anwendung darauf.
  • Neustart nötig. Der Outpost übernimmt einen neu importierten Zertifikatspeicher erst beim nächsten Start.
  • Client-Zertifikate sind das nicht. Verlangt euer Proxy eine Authentifizierung mit Client-Zertifikat, ist das ein anderer Fall — sprecht uns an (enterprise@meingpt.com).
War diese Seite hilfreich?