Skip to main content
sesame trust installs your tenant’s root certificate into the operating system trust store. Run it once per machine, before (or after) sesame launch — it is idempotent.

When you need it

sesame launch establishes trust through environment variables (SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, CURL_CA_BUNDLE, GIT_SSL_CAINFO, …), which covers Python, Node, curl, git — and Go programs on Linux. Anything that verifies against the system trust store instead of those env vars is the exception — most commonly Go programs on macOS (Go’s darwin builds use the Security framework and silently ignore SSL_CERT_FILE), but also Electron apps and Swift/URLSession tools. Any such process routed through the edge proxy — gh, terraform, kubectl, Go- or binary-distributed MCP servers — fails like this on every brokered host until the tenant root is in the keychain:
If you see x509: … certificate is not trusted naming a Sesame Online Intermediate, this is that gap — run sesame trust.

What it does

  • macOS — adds the root to your login keychain with trust restricted to SSL only (never code signing). No sudo; macOS asks for your login password to confirm the trust-settings change.
  • Linux — copies the root into the distro’s CA anchor directory and rebuilds the store (update-ca-certificates on Debian/Ubuntu, update-ca-trust on RHEL/Fedora). Needs root — when not run as root, it prints the exact sudo commands instead of executing.
  • Java (if a JDK is on PATH) — additionally imports the root into the default JVM keystore via keytool -cacerts, since JVMs consult neither the CA env vars nor the OS store. Best-effort: a read-only system JDK gets the sudo command printed instead.
The root is per-tenant (self-hosted brokers each have their own), stable for 10 years, and only ever signs your own broker’s short-lived per-host leaves.

Runtime coverage at a glance

Options

Restart any running Go tools after installing — they load trust once at process start.