No. It's vital in only two/three situations I can think of (two come to mind immediately, there might be others I'm forgetting) when using alt-server certs. Any time you decide to use an alt-server cert, you must ensure the alt-server cert does not overlap with the component's "advertise" address or SNI is indeterminate.
The two times I can think of are:
- the OpenZiti controller APIs (management/client/oidc)
- the OpenZiti controller with the /zac binding (to deliver the ZAC via a url that doesn't give people the scary untrusted warning)
- a router configured with web socket bindings to support BrowZer
In all of these situations an HTTP listener is desired to provide endpoints pre-configured with trust via the OS truststore.
Well, different ports are still the same domain name... So "no" to that. Recently I discussed something related with HAproxy on this discourse post. There's an associated video on that post too and github repo you might find value in. Each component is it's own server and OpenZiti will not tolerate TLS being terminated anywhere BUT that component, so each component will have it's own TLS context.
The four domains you listed would be perfect, yes. Controller.ziti.domain.net, router1.ziti.domain.net, router2.ziti.domain.net would all use the private PKI established when creating the OpenZiti overlay and zac.domain.net would use LE (matching *.domain.net only) and would be fine. You'll ALSO be able to access the zac from controller.ziti.domain.net/zac if you wanted to. Are you deploying the ZAC as part of the controller? I only ask because you might just end up using "https://ziti.domain.net/zac" or something like if you do (not zac.domain.net)
Hopfeully all that's clear 