search

openziti / ziti

The parent project for OpenZiti. Here you will find the executables for a fully zero trust, application embedded, programmable network @OpenZiti
https://openziti.io
Apache License 2.0
2.31k stars 137 forks source link

Enrollment JWT Signer resolution with multiple hostnames/ips fails #1193

Open andrewpmartinez opened 1 year ago

andrewpmartinez commented 1 year ago

Experienced

When configuring a controller with multiple hostnames/IPs SANs resolution to reach the API is correct, but which public key that is used to sign enrollment JWTs doesn't always match the intended case.

Expected

Enrollment JWTs can be created using a "default" hostname/IP or a specific hostname/IP on a case-by-case basis. The hostname/ip for the controller inside the JWT should match the signer.

Reproduction 1) Standup a controller with a private CA ("primary CA") 2) Enroll the controller with a public CA or a different private CA and ensure the SNA IP/DNS in the public certificate are different than the initial server certificate ("secondary CA") 3) Configure the Edge APIs to use the certificates from the secondary CA via alt_server_certs. 4) Set the advertised URL for enrollment to the secondary CA-issued certificates 5) Do not configure the root identity with any certs other than the default primary CA-issued ones 6) Attempt to enroll a new router or identity

dovholuknf commented 10 months ago

the "address" configured in the controller config file must align to the sever_cert/key in the identity block, not the alt_server_certs specified. It would be best if the controller would inspect the resolved server_cert and ensure the cert contains a SANS entry for the address specified. if not the controller should panic and inform the operator to fix the server_cert and that it must have a corresponding SANS for the address entered.

qrkourier commented 10 months ago

One solution is for the controller to enforce that the same private key is used whenever there are multiple server certs presented for the client API, selected by SNI. This works because the server's private key signs the OTT, and the server cert only serves to present the public key to the enrollee which then verifies the JWT's signature. If all server certs are presenting the same public key then JWT signatures will always be verifiable irrespective of which server cert is encountered.

qmugnier commented 3 weeks ago

Quick question, was this fixed? Because I think I encounter the same issue.