add `ca.crt` into served up cert

[travisghansen]

Description:

If the ca.crt is present in the cert secret we should probably load it up to create a more complete chain.

I think this should be possible to make it fairly bullet proof and handle scenarios where the CA may already be in tls.crt etc.

For example, cert-manager does the following:

• when using acme, the CA is injected into tls.crt and ca.crt is not present in the secret
• when cert is selfsigned the same cert is in both tls.crt and ca.crt
• when cert is issued from a ca issuer, the CA is placed into ca.crt and not present in tls.crt

I think this is just good best practice but there may be some side effects to consider.

I ran into this issue when attempting to utilize the new ocsp feature (#3826). We had a cert where the CA was only present in ca.crt. In such a case envoy was sending the ocsp response as appropriate when using raw openssl commands, but when trying to verify the cert via curl it would fail. After some debugging it was determined this was due to the incomplete chain.

# served up an ocsp response
echo '' | openssl s_client -servername some.host.foo -connect ip:443 -status

# would fail the check with the following error: Error computing OCSP ID
curl --cert-status "https://some.host.foo/" -v

[Aditya7880900936]

Hi maintainers,
I’d like to take ownership of this issue if it’s still unassigned.

I’ll start by reviewing how certificate chains are currently constructed from secrets, especially the handling of tls.crt vs ca.crt, and compare this with cert-manager behaviors.

I’ll share findings or open a PR once I validate a safe approach that avoids duplicating or breaking existing chains.
Thanks!