I seem to be having a variant of this problem.
Did you ever make progress on it?
In my specific case, I am using Vault as the CA for Connect.
I have an existing PKI root mounted on Vault which is an intermediate CA from an offline root CA, and this is being used as the “root” from Connect’s perspective; it’s then standing up its own “intermediate” in Vault, which is then being used to sign the various service certificates.
The PKI root for Vault knows nothing about Connect; it’s just a regular CA; it doesn’t have any .consul DNS SAN or SPIFFE URI SAN. The Connect intermediate from Vault is signed with a couple of SANs, e.g.:
DNS:pri-1gbfprc.vault.ca.1421127e.consul, URI:spiffe://1421127e-5e51-9ed2-8543-ab686fc4a16f.consul
The service leaf certs also look fine, and are signed with SANs like:
DNS:echo.svc.default.1421127e.consul, URI:spiffe://1421127e-5e51-9ed2-8543-ab686fc4a16f.consul/ns/default/dc/dc1/svc/echo
I have validated the entire chain with openssl and it’s OK.
When you ask Connect for the root CA, it gives back the Vault root which (still) doesn’t have any of the Consul DNS or SPIFFE SANs - this conflicts with that documentation mentioned above.
This setup works fine for the builtin Connect proxy. It comes up with a message like:
2020-05-08T12:21:02.073Z [INFO] proxy: Parsed TLS identity: uri=spiffe://1421127e-5e51-9ed2-8543-ab686fc4a16f.consul/ns/default/dc/dc1/svc/echo roots=["<my Vault root CN>"]
I am able to get the builtin proxy to connect and behave just fine. When I try to switch to Envoy, the wheels come off and Envoy gives errors indicating the CA is untrusted exactly as described in the posts above.
If it makes a difference the offline root and the Vault PKI root are RSA, but the Connect certificates (intermediate and leaf) are ECDSA. I am using Vault 1.4.1, Consul 1.7.3 and Envoy 1.13.0.