Should routable IPs be included in Ziti controller certificates?

Support General Questions
1

I'm setting up a 3-node HA controller cluster and I'm following the PKI example from the docs, where each controller's server cert is created like this:

ziti pki create server --pki-root ./pki --ca-name ctrl1 \
  --dns "localhost,ctrl1.ziti.example.com" \
  --ip "127.0.0.1,::1" \
  --server-name ctrl1 --spiffe-id 'controller/ctrl1'

As I understand it, that example runs all three controllers locally on a single host with unique tcp ports, which is why only loopback (127.0.0.1,::1) is in the IP SAN rather than any routable address. My understanding so far:

  • Controller-to-controller identity is carried by the SPIFFE ID (URI SAN), independent of DNS/IP.
  • The DNS SAN matches the FQDN used in advertiseAddress / bootstrapMembers for the router/SDK-facing TLS hostname verification.
  • The loopback IP SAN only enables local self-connectionsand never changes regardless of where the host lives.

My questions for a multi-host deployment:

  1. Should or can the host's actual routable IP be added to the server cert's IP SAN, or is it recommended to keep only loopback + FQDN and rely entirely on DNS for reachability?
  2. If I were to put the routable IP into the SAN, is there any security or functional benefit, or is it purely a convenience for connecting by IP literal?
  3. Most importantly: when a controller is relocated and gets a new IP, what's the recommended practice? If I use FQDN-only advertiseAddress and update DNS, do I avoid any cert re-issuance entirely? And conversely, if a routable IP is baked into the SAN, does an IP change force a re-issue (and would a stale IP SAN otherwise be harmless as long as nothing connects by IP literal)?
2

Hi @jnsfndr,

I suppose it depends on 'what' you want to use it for. You can certainly add any IPs or DNS SANS you wish to your certificates. Since you're making the server cert as shown, you can add as many IP/DNS as you like. You might want to add other entries later as well for example, I often like to split off APIs and I'll use an intercept to access those services like: my.secret.api (or whatever). To allow TLS for that address you'd need to have a DNS SANS that matches of course... So add as many as you want just make sure you don't REMOVE ones that need to be there... :slight_smile:

100% convenience. I can't think of any reason how adding more addresses/ips would possibly cause your controller any sort of security problem. You still need to authenticate so, hard to think there's any sort of worry there. I find using IP's "inconvenient" compared to a human-memorable address, but if you want to use an IP fine. It'll only be for you to access the REST api/ziti admin console. The control plane/routers will connect to whatever the advertised addresses are so any extra entries aren't going to be used by the overlay.

This is why using IP addresses is 'inconvenient'. It would invalidate the controller or you'd have to regenerate a server certificate with the new IP. It'll likely cause other configuration issues with the cluster (if you have more than one controller) and routers...

Yes. This is why using a FQDN is generally more convenient .

Depends I suppose on how many IPs you had on the cert and if the IP is included already, but that seems unlikely... So generally yes, you'd have to re-issue the cert.

It's nearly always best to use a FQDN instead of IP.