Your own root certificate (CA)

Make the machine running the Outpost trust an internal root certificate when your network inspects TLS.

Many corporate networks inspect outbound HTTPS: a firewall or web proxy decrypts the connection and re-encrypts it with its own root certificate. To the Outpost this looks like a foreign certificate on bridge.meingpt.com — and it aborts, which is exactly what it should do.

To let it work anyway, the machine itself has to trust your root certificate. There is no setting for this in the Outpost — the certificate belongs in the operating system's own certificate store, on the machine running the Outpost.

How you know this is the problem

The Connection tab and the wizard share the same button: Run check. The TLS certificate check then fails and names the issuer — for the common appliances, by name, e.g. Zscaler Root CA. That is the unambiguous diagnosis; without it, a failed pairing is just as often a firewall rule or a proxy.

Check first, act second

Rolling out a root certificate because pairing does not work is guessing. Run the check: it tells you whether DNS, TCP, TLS, reaching MeinGPT or the system clock is the problem.

Setting it up

Get the certificate

Ask IT for the root CA certificate behind your TLS inspection, in PEM, CRT, or CER format.

If the chain consists of a root plus intermediates, the machine needs both — most rollout paths (group policy, MDM) already push the whole chain.

Add it to the operating system's certificate store

This is an operating-system setting, not an Outpost setting:

  • Windows: usually already handled by group policy — whoever runs the TLS inspection typically rolls the root certificate out to managed machines anyway. Manually, use certlm.mscTrusted Root Certification AuthoritiesImport Certificate.
  • macOS: import the certificate into Keychain Access (the System keychain), then set it to Always Trust under the certificate's Trust settings.
  • Linux: place the certificate under /usr/local/share/ca-certificates/ (Debian/Ubuntu) or /etc/pki/ca-trust/source/anchors/ (RHEL/Fedora) and run update-ca-certificates or update-ca-trust.

The Outpost reads this store on every connection attempt — the same one the machine's browser already trusts.

Run the check again

Restart the Outpost, then Run check. If TLS certificate passes, you are done; pairing works afterwards.

If the check stays red, the chain in the operating system is usually incomplete — ask IT for the intermediates and add them to the store as well.

What this affects

The operating system's certificate store applies to all outbound connections of the Outpost: the tunnel to MeinGPT, the MeinGPT API, and your own embedding endpoint if you use one. Publicly trusted certificates stay untouched — your root certificate is added, it replaces nothing.

If your root certificate is already rolled out on the machine by group policy or MDM — the normal case on a managed corporate machine — you do not need this page: the Outpost trusts what the machine trusts, with nothing further to do.

Limits

  • This applies to the machine, not only the Outpost. There is no way to scope the trust to the Outpost alone — changing the operating system's certificate store changes it for every application on that machine.
  • A restart is required. The Outpost only picks up a newly imported certificate store on its next start.
  • This is not a client certificate. If your proxy requires client-certificate authentication, that is a different case — talk to us (enterprise@meingpt.com).
Was this page helpful?