Settings → System → CA Certificates

Some of the systems MisterShell connects out to — your identity provider, mail relay, AI model endpoint, or a webhook / log-forwarding destination — may present a certificate signed by a private or internal certificate authority instead of a public one. The CA Certificates tab is where you upload those internal root and intermediate certificates so MisterShell can verify connections to those systems instead of only trusting the public certificate authorities every computer ships with.

Certificates you add here are trusted workspace-wide: once loaded, every feature below picks them up automatically whenever its own Verify TLS toggle is turned on. Adding a certificate here does nothing on its own for a feature whose toggle is off.

What you can do

• Paste one certificate, or a bundle containing several, in PEM format. A PEM that contains private-key material is rejected outright — only certificates are accepted, so a combined key + certificate file must have the key removed first.
• Certificates are de-duplicated automatically — pasting the same certificate twice (even inside a larger bundle) is a no-op, not an error.
• Enable or disable a certificate without deleting it, to pull it out of the trust set temporarily.
• See each certificate’s subject, issuer, and expiry at a glance, with a warning chip as expiry approaches and an error chip once it has passed.
• Delete certificates you no longer need.

Common tasks

Add a certificate

1. Click Add Certificate.
2. Give it a Name — any label that helps you recognize it later.
3. Paste the certificate’s PEM content into the Certificate field. You can paste a bundle with more than one certificate in it; each one is parsed and added separately.
4. Click Add Certificate. A confirmation reports how many certificates were added and how many were already present (and therefore skipped).

Newly added certificates are enabled immediately.

Enable or disable a certificate

Use the toggle in the Enabled column. Disabling a certificate removes it from the trust set on the next connection attempt without deleting it, so you can re-enable it later.

View, rename, or delete a certificate

Each row carries three actions: View opens the certificate’s details, Edit lets you rename it, and Delete (with a confirmation) removes it.

Certificate list

Column	Notes
Name	The label you gave it when adding it.
Subject	The certificate’s subject, with the issuer shown underneath.
Valid from	The start of the certificate’s validity period.
Expires	The certificate’s expiry date.
Validity	A badge: green valid, orange expiring within 30 days of expiry, red expired once it has passed. Expired or soon-to-expire certificates are still trusted until you disable or delete them — MisterShell does not automatically stop trusting an expired certificate.
Enabled	Whether the certificate is currently part of the trust set.
Actions	View / Edit / Delete.

Which features honor this store

Any feature that connects out over an encrypted connection and offers a Verify TLS (or “Verify TLS certificate”) toggle honors this store when that toggle is on:

• Identity providers — Auth Providers (LDAP and OIDC connections to your directory / identity provider).
• Email — the SMTP relay configured in Advanced Settings (and the Config wizard’s Email step).
• AI model providers — Models, for providers that call out to a custom or self-hosted endpoint.
• Automation webhook actions — the webhook action in an automation playbook (see Automation Studio).
• Log forwarding destinations — both syslog and webhook destinations on the Log Forwarding tab.

If a connection’s certificate can’t be validated against the public certificate authorities or this store, the connection is refused — there is no silent fallback to trusting it anyway.

Verify TLS toggles and their defaults

Each feature above carries its own Verify TLS toggle, and the defaults are not all the same:

Feature	Toggle default
LDAP provider	On when creating a provider; a saved provider with no explicit value uses Off
OIDC provider	On
SMTP (email)	Off by default; the Config wizard turns it on for a fresh setup
AI model provider	On (where the provider supports it — see below)
Automation webhook action	Set per action; unset defaults to on
Log forwarding destination (syslog / webhook)	The destination form’s toggle starts off. Destinations created via the API without an explicit value verify by default

Check the Verify TLS value on each saved LDAP provider and SMTP relay. A connection with verification off does not validate the server’s certificate. For an internal certificate authority, load its CA certificate(s) into the store before enabling verification to avoid interrupting sign-in or email delivery.

A couple of AI providers call out through a vendor SDK that does not accept a custom certificate list, so the Verify TLS toggle doesn’t apply to them and is hidden on the model form; those providers always use their SDK’s own certificate handling.

Container CA mount (self-hosted deployments)

If you run MisterShell’s containers yourself, you can also make an internal CA trusted at the container level, independent of the CA Certificates tab. Mount your certificate file(s) — .crt or .pem, PEM format — into /etc/certs inside the container:

docker run -d \
  -v /path/to/internal-ca.crt:/etc/certs/internal-ca.crt:ro \
  mistershell/core:latest

This applies to every MisterShell container image — the core, and every remote worker, proxy, and sensor — so it’s the right mechanism for trusting a private CA on components that don’t have their own settings UI, including a remote worker’s, proxy’s, or sensor’s own connection back to the core. Certificates mounted this way are trusted everywhere in that container, regardless of any per-feature Verify TLS toggle.

The two mechanisms are complementary: the CA Certificates tab is for certificates the core process itself needs at runtime (and is the only option in a managed/hosted deployment), while the container mount is for self-hosted deployments that want the trust baked into the container at startup, or that need it on a worker, proxy, or sensor.

Web-resource “Ignore certificate errors”

Individual Web Application resources have their own, separate setting: Ignore certificate errors, in the resource’s connection settings. It is off by default. Turning it on makes the browser-based session for that one resource accept an invalid, expired, or self-signed certificate outright, without needing a CA certificate at all.

Security caveat: this does not verify the resource’s identity at all — it accepts any certificate, valid or not. Only enable it for trusted internal devices whose network path you control, and prefer loading the device’s actual certificate authority into the CA Certificates store instead, when that’s possible. See Web Application.

Permissions

• View certificates: app.settings.read.
• Add / enable / disable / delete certificates: app.settings.write.