MangedCluster.managedClusterClientConfigs[].caBundle is wrongly populated when using externally signed certs

Description of problem:

From https://github.com/stolostron/api/blob/main/cluster/v1/0000_00_clusters.open-cluster-management.io_managedclusters.crd.yaml#L97-L100 we are told that: "CABundle is the ca bundle to connect to apiserver of the managed cluster. System certs are used if it is not set."

That field is correctly populated with the public key of the CA in a stock deployment, I correctly fetch that field and use it to connect to API endpoints of remote servers, so far so good.

The problem arises whenever we stop using the internal self-signed certificates, but start using a certificate generated via letsencrypt: in this scenario "caBundle" should be either empty or contain the root CA bundles. Instead it contains the API's endpoint public certificate.

So in the "normal" OCP deployment where the API certificate has been signed by an internally generated CA we get a proper caBundle that can be used to verify connections to the API endpoint:

oc get ManagedCluster/local-cluster -o jsonpath='{.spec.managedClusterClientConfigs[0].caBundle}' | base64 -d | openssl x509 -noout -subject -issuer -ext basicConstraints
subject=OU = openshift, CN = kube-apiserver-lb-signer
issuer=OU = openshift, CN = kube-apiserver-lb-signer
X509v3 Basic Constraints: critical
    CA:TRUE

But whenever we replace the API endpoint certificate with one signed by a proper CA (letsencrypt in this case) we get the following in the caBundle field:

oc get ManagedCluster/local-cluster -o jsonpath='{.spec.managedClusterClientConfigs[0].caBundle}' | base64 -d | openssl x509 -noout -subject -issuer -ext basicConstraints
subject=CN = api.mcg-hub.blueprints.rhecoeng.com
issuer=C = US, O = Let's Encrypt, CN = R3
X509v3 Basic Constraints: critical
    CA:false

Now we get a simple certificate and not a CA's certificate and this is problematic because now the caBundle cannot be used as a ca bundle to connect to the apiserver as it is not a CA.

The desired outcome in this case would be either to have an empty caBundle or the root caBundle that is normally used inside OCP. I.e. the caBundle should be usable to verify the connection to the API endpoint

Version-Release number of selected component (if applicable):

I hit this with ACM 2.6

How reproducible:

100%

Steps to Reproduce:

1. Configure the API endpoint with a cert signed by an external CA
2. Import the cluster. Observe the caBundle with the server cert

Actual results:

caBundle contains the server cert and not the caBundle

Expected results:

I expect either the certificate authority cert that signed the server cert or an empty field.

Additional info:

A reproducing env can be provided, just ping me