add support for mTLS on incoming client connections

[TheConcierge]

Description & motivation 💭

In production temporal, we currently have an nginx proxy sitting between envoy and the ui-server. At this point, it mainly serves the purpose of TLS termination and cert reloading. The nginx proxy has been giving us (minor) issues and it makes more sense to remove it instead of trying to troubleshoot.

This change adds support for mTLS between the ui-server and incoming client connections, removing the need for an intermediary proxy. Considering we also want to utilize the cert loader, this was moved out into a shared library so both upstream and downstream connections can utilize the same code.

Screenshots (if applicable) 📸

Design Considerations 🎨

The main thing is, since this is open source, we are introducing new configuration options that we are likely bound to support in whichever format we ship. I'm unsure if we have teams or team members who have strong opinions on this, but if so, happy to change whatever.

Testing 🧪

How was this tested 👻

• Manual testing
• E2E tests added
• Unit tests added

Manual testing was a bit weird on this one. I ended up porting this change to the ui-server repo, forking it, replacing the dependency in our internal build repo, and manually patching a cell with the new version (as well as rerouting traffic away from the nginx reverse proxy). From there, I loaded up a workflow page, making sure that everything still loaded, and checked the logs to make sure traffic was, indeed, flowing through the new web api instance.

Steps for others to test: 🚶🏽‍♂️🚶🏽‍♀️

My testing was...a fairly manual setup. I'm happy to share some of those internal changes or codify my steps in a runbook if you all think that this is a decent enough testing strategy. If there is a better strat, please let me know and I'm happy to try another way.

Checklists

Draft Checklist

Merge Checklist

Issue(s) closed

Docs

Any docs updates needed?

I'm not seeing anywhere in the README or docs.temporal.io that reference any of the TEMPORAL_UI_SERVER vars. This may be something to address in general.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
holocene	Ready	Preview	Oct 1, 2026 7:50pm UTC

[CLAassistant]

All committers have signed the CLA.

[TheConcierge]

this is actually a behavior change i'd like to point out explicitly.

Before, if you were missing one of these, we'd just default to no TLS. this could silently cause insecure connections when slightly misconfigured, which didn't seem desirable. The Validation now explicitly rejects when only one of these are set, as we can't know which they intended (no tls or are expecting working tls).

If we anticipate this being a problem for some subset of open source users (and care about the backward compatibility with configuration), I'm open to changing how strict validation is.