qrkourier
commented
4 months ago Notes to validator:
Read the ClientHello with openssl.
openssl s_client -connect ziti.example.com:1280 -tls1_2 -showcerts -msg -debug </dev/nullWith TLS 1.2, the client API's ClientHello should have a non-zero-length list of acceptable CA DNs (not a trailing 00 00)
<<< TLS 1.2, Handshake [length 0023], CertificateRequest
0d 00 00 1f 02 01 40 00 18 08 04 04 03 08 07 08
05 08 06 04 01 05 01 06 01 05 03 06 03 02 01 02
03 00 00With TLS 1.3, the ClientHello should have certificate_authorities extension (00 2f) present (it's missing in this example).
openssl s_client -connect ziti.example.com:1280 -tls1_3 -showcerts -msg -debug </dev/null<<< TLS 1.3, Handshake [length 002d], CertificateRequest
0d 00 00 29 00 00 26 00 05 00 00 00 12 00 00 00
0d 00 1a 00 18 08 04 04 03 08 07 08 05 08 06 04
01 05 01 06 01 05 03 06 03 02 01 02 03
The client API indiscriminately requests any client certificate. The client API should send the list of trusted CAs (the edge signer CA's distinguished name, and the DNs of any additional, verified CAs).
This allows the client to filter the available client certificates and present an acceptable certificate.
Without this info the client UX is degraded in the following way in Chrome (desktop and Android, at least): clients are unnecessarily prompted to select a client certificate in the web browser if the browser has ANY client certificates available.
For example, if I have imported a p12 for ANY site, then I'm prompted to pick a client cert every time I navigate to a BrowZer-enabled site or the ZAC SPA, even if I don't use client certs with those sites.
About BrowZer - no client certificates are EVER presented to the client API by ZBR clients (no mTLS for ZBR<==>client-management), so the indiscriminate client cert prompt is always unnecessary. When a crypto fob like a YubiKey is attached, the web browser will unnecessarily prompt the user to unlock it so that client certificates may be used. It is possible to work around this BrowZer UX issue by using a reverse proxy for the client API that does not request a client certificate.
About ZAC - it's possible to work around this with a reverse proxy for ZAC if using only password auth. If using cert auth to log in to ZAC then there's no work around because the TLS server must receive a trusted client cert.