Using an intermediate CA whose certificate is signed by a self-signed root CA certificate

Does anyone use own certificate chains for Kubernetes clusters?

There’s an issue with such kind of setup, and I would be grateful for any ideas on how to solve it.

Let’s assume we have a Root CA which certificate is self-signed. Also we have an Intermediate CA which certificate is signed by the Root CA. We make a certification chain (by concatenating both PEM containers in one file) and set up Kubernetes with that. Almost everything works perfectly: Kubernetes works fine, Kubernetes clients works fine, Kubernetes operators works fine… Life is good.

But there is one thing that we have to keep in mind. All Secret object that contains security tokens for the ServiceAccount objects have “shortened” versions of the CA certificate. The “shortened” version doesn’t contain the Root CA certificate, only the Intermediate one.

As I can see, for the most of TLS libraries that is enough. A piece of software establishes a TLS connection with the Kubernetes API Server, makes sure that the server’s certificate is signed by a trusted CA (assuming that the Intermediate CA certificate that is gotten from the related Secret is trusted) and everything works smoothly.

But sometimes we have a problem. When we a piece of software (for example a Kubernetes operator or any other program that needs to communicate with Kubernetes API Server) that uses a little bit more strict TLS library - we are in trouble. In this case we have to provide this tool with the version of the certification chain (containing both the Intermediate CA certificate and the Root one), because the “shortened” version which is provided by Kubernetes is not enough. And that’s OK if we are able to provide this tool with the full certificate chain, but sometimes that’s not possible, so it takes the “shortened” CA certificate from /var/run/secrets/ and that’s not easy to persuade it to take the CA certificate from another source. :frowning:

My question is the following: is there any way to make Kubernetes create these Secret objects with the full version of the certification chain? And if there is, will it cause another kind of difficulties (e.g. if the software that will be provided with the full chain will glitch)? Or, perhaps, there could be another workaround?

Thanks in advance.