Invalid ssl using ssl-passthrough in ziti controller

Correct, you can restrict access to the managementApi cluster service for administrative management tasks with the console and CLI.

There's not because alt ingresses for client and mgmt APIs are for things like the console and BrowZer, not the router ctrl plane which always uses Ziti's edge signer PKI.

ok cool , that clears a lot . Thanks for the patience

You're welcome! Let us know if you have any more questions.

1 Like

Hi @qrkourier, I tested this .

I'm wondering what would the client url be used for then ? since the jwt's decode to the client url itself but we really cant create identities .. etc using the url

Ziti identities and routers use the client API to communicate with the Ziti controller with mutual TLS.

Correct, a Ziti identity and a Ziti router one-time enrollment token both contain the URL of the client API as an issuer (iss) claim. Both submit their enrollment materials to this URL and receive a client certificate used to authenticate from that point forward.

There are no management operations available via the client API, only the management API. The client API and management API provide distinct sets of API operations. Either or both set may be "bound" to a web listener. For security, it's a good idea to bind the management API to a separate listener for which you control administrative access. That is where the CLI and console will connect. The client API provides public-facing operations so that all Ziti identities and all Ziti routers can connect to the controller with mutual TLS.

1 Like