[IAM] [EKS] [IRSA] Allow Uploading Private CA to OpenID Connect Provider

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**

We use a self-hosted distribution of kubernetes. The certificate api-server is signed with a private certificate authority. api-server does not present a certificate chain that includes the CA during tls handshake - it only presents the server certificate (first in chain). The CA is available for the clients to trust separately, for example it is bundled in the KUBECONFIG that is issued for the clients.

IAM OIDC does not support trusting a CA for the jwt issuer like standard tls clients. It only accepts a thumbprint and tries to match it with any certificate that appears the certificate chain presented by the jwt issuer's https endpoint. Just putting the thumbprint of a private CA that does not appear in the chain explicitly does not work - we get this auth error:
> InvalidIdentityToken: OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint
status code: 400, ...

IAM OpenID Connect providers for IRSA should allow uploading private CA for trusting the k8s jwt issuer like standard tls clients.

**Which service(s) is this request for?**

IAM OpenID Connect for IRSA to self-hosted kubernetes distributions.

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

Stabilize the IRSA-based connectivity between our kubernetes workloads and AWS services.

**Are you currently working around this issue?**

We are forced to put the thumbprint of the server certificate, not the CA. Unlike the CA, the server certificate changes frequently (k8s upgrades, landscape changes, ...) and causes us to run into outages as we lose connectivity to aws services.

**Additional context**

IAM OIDC does server verification in a non-standard way. This is the definition of a certificate chain according to RFC 5246:

This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

No repository files, tests, or implementation entry points are identified in the issue. Start by reviewing the IAM OpenID Connect provider and IRSA behavior described here; done would mean private CA trust is supported for self-hosted Kubernetes JWT issuers without relying on frequently changing server-certificate thumbprints.

Written by the indexing model from the issue text.