Certificate verification doesn't support intermediate CA chains

[banks]

https://github.com/haproxytech/haproxy-consul-connect/blob/556c75e4dede0754103b0b39b4d3f523be90cc13/haproxy/spoe.go#L45-L47

Verifying certificates is not providing intermediates that may be present. That means it will only work in the Primary DC and even then it will only work for CA providers that choose to sign directly with their root key. (In the future this will likely be zero providers!).

The easiest thing to do is to follow the code in our SDK here: https://github.com/hashicorp/consul/blob/fd3c56ff68829821da4be139185c0a96938e1929/connect/tls.go#L265

At a high level it:

• Parses the certificate given by the client as a bundle - the first certificate present is always the leaf, any other certificates presented are assumed to be intermediates, either from the current CA or cross-signed by previous CAs during a rotation.
• Add the intermediates, if any to an intermediates x509.Pool
• Call verify with the roots and intermediates etc.

[ShimmerGlass]

@banks what's the advantage of doing the TLS validation in the Connect code? Could we let HAProxy do the verification and just use the client certificate to get the client URI and validate the intentions?

[banks]

That's possible. Envoy sidecars validate the certificate before the AuthZ callback for example. Also assuming

• that HAProxy will load intermediates that are bundled with the client cert of the connection as described above (pretty sure this is standard usage but worth noting to test)
• that HAProxy will be configured with all the intermediates as well as just the root certs in the trust bundle

Originally I assumed that there was a good reason to do validation here so was just pointing out how to do it correctly, but if HAProxy can do it first before making the SPOE call then that's great.

[ShimmerGlass]

Thank you, I had the impression that for Envoy the certificate validation was done on the consul connect but it looks like I was mistaken.