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:
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-certificateson Debian/Ubuntu,update-ca-truston RHEL/Fedora). Needs root — when not run as root, it prints the exactsudocommands 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 thesudocommand printed instead.