Skip to main content
If a service Sage connects to over HTTPS presents a certificate signed by a private CA, put the CA bundle at certs/bundle.pem inside Sage’s directory. Typical cases are a self-hosted model gateway such as a LiteLLM proxy, an HTTP or SSE MCP server, and a BloodHound CE instance behind an internal certificate. At startup Sage concatenates it with the system CA store, writes certs/combined-bundle.pem, and points SSL_CERT_FILE at the result; private CAs are trusted in addition to the public roots, not instead of them. An SSL_CERT_FILE you set yourself takes precedence, and Sage leaves it alone. Without a bundle.pem, Sage logs that it is using system defaults and carries on. A trusted bundle is the alternative to turning verification off. An MCP server you would otherwise connect with "ssl_verify":false verifies normally once its CA is in the bundle.
Mythic is not a typical case. Sage reaches Mythic through its nginx endpoint (NGINX_HOST and NGINX_PORT, by default 127.0.0.1:7443 on the Mythic server). The Mythic API client Sage uses does not verify that certificate, so adding Mythic’s CA to the bundle changes nothing for ordinary Mythic API calls. The one exception is downloading a registered file from Mythic, which Sage does to inspect an enrolled executable: over HTTPS that request verifies against the bundle, including the hostname.

​
Under a Mythic install

The file goes in the mounted service directory. mythic-cli install creates that tree owned by root, so writing to it needs elevation:
Restart the Sage container to pick it up. The same root ownership applies to anything else you place in that directory.

​
Local development

There is no bind mount in local development; write directly to Payload_Type/sage/certs/bundle.pem. combined-bundle.pem is generated on every start, and both it and bundle.pem are gitignored; neither is ever baked into the image.