Wildcard Let’s Encrypt Certificate Necessary for BrowZer, or Can I Use Multiple Individual Certificates?

1

Hi there,

I’m setting up OpenZiti with BrowZer following the quickstart guide (BrowZer | OpenZiti), which recommends using a wildcard Let’s Encrypt certificate for the controller and BrowZer bootstrapper (e.g., *.example.com for controller.example.com and browzer.example.com, edge-router.example.com). I have two main questions about this approach:

Is a wildcard certificate truly necessary?

Can I instead use separate Let’s Encrypt certificates for the controller and bootstrapper (e.g., one for controller.example.com and another for browzer.example.com)? Alternatively, would a single certificate with Subject Alternative Names (SANs) listing both subdomains work?

Are there specific requirements in the BrowZer architecture that make a wildcard certificate the only viable option, or is it recommended purely for convenience?

How safe is it to use the same wildcard certificate for both components?

I’m concerned about the security implications of sharing a single wildcard certificate (and its private key) across the controller and bootstrapper, especially if they’re on different servers. It feels risky to have one private key that could potentially affect all subdomains if compromised.

Are requests from the browzer bootstrapper only verified using the Let's Encrypt certs or are the Let's Encrypt also signed by the Ziti CA? In other words, if someone would gain access to the Let's Encrypt private key, would the whole Ziti Infrastructure be compromised?

Thanks
Dominik

2

No, it's not necessary to use a wildcard certificate or to share a certificate between hosts.

The BrowZer Bootstrapper's certificate, the controller's edge-client and edge-oidc alternative certificate, and the router's WSS edge listener alternative certificate must be publicly trusted with SANs that match their addresses.

For the Bootstrapper's certificate, those addresses include the subdomains representing Ziti services, not merely the Bootstrapper itself. Using a wildcard certificate allows the Bootstrapper to terminate TLS with a publicly trusted certificate that has SANs matching all possible Ziti service addresses provided by BrowZer.

For the controller and router, the trusted alternative certificates must have Subject Alternative Names (SANs) that are distinct from the other certificates bound to those same TLS listeners, i.e., the certificates used by Ziti's internal PKI with SANs for the Ziti controllers' and routers' advertised addresses.

You may find it more secure or convenient or both to position an ACME HTTP solver in front of the Bootstrapper with a separate configuration listing the Bootstrapper's address and the SANs you plan to use as Ziti services via BrowZer so that the proxy can manage the certificates on behalf of the Bootstrapper and the services it provides. In this scenario, the Bootstrapper's locally configured TLS server certificate is presented only to the upstream/origin side of the reverse proxy.

Yes.

I know you wish to avoid sharing certificates between applications. Still, if you're saying the controller and Bootstrapper are on the same host, then you could share a certificate that has all SANs required for both sets of requirements, i.e., the Bootstrapper and its Ziti service subdomains, and the controller's edge-client and edge-oidc alternative server certificate.

That's valid. The quickstart is optimized for simplicity and convenience.

No. If the Bootstrapper's private key were compromised, then the attacker could impersonate that identity and serve a malicious website, application, or service on any address matching that certificate's Subject Alternative Names (SANs).

1 Like