Certificate Renewal on Kubernetes without root


In the last 6 months, I have faced the same issue twice. After the renewal of the certificate, the root was lost from the chain causing issues in some applications.

It does not happen in each renewal but sometimes. I must manually add the root certificate each time I have this issue.

Root is always not included in chain in general


I have 3 different Kubernetes env and each Kubernetes env has 2-3 different certificates. I can see in the secrets that have created the root. As I said only two times after the renewal the secret was lost the root.

Not sure exactly what you mean by "secret".
Root certs are nothing "secret" - they are the exact opposite [well-known public information].

You should never have to provide the root cert with your certificate.
If a client is dumb enough to trust a connection because it includes the root cert, then it can be fooled to trust any cert by anyone including their own root cert = 100% encryption with 0% trust.


In a Kubernetes environment, when you utilize cert-manager to set up a cluster issuer with Let's Encrypt, the resulting certificate is stored within a Kubernetes secret of type kubernetes.io/tls. This secret holds both the certificate chain and the private key, and it gets automatically updated after each renewal.

However, I've encountered instances where, after the renewal process, the root certificate is missing from the certificate chain.

Root certificates should NEVER be included in any such certificate.
Root certificates should be known to all operating systems/browsers.
They get updated through trusted channels.
They should never be trusted, nor accepted, by any client via any other method.


If you have an example of such chains, maybe we can better understand the problem and explain the reason for it.

I suspect you might be confusing a "cross-signed [root] cert" with an actual "root cert".


Ah, I see, perhaps I wasn't clear. What I meant to convey is that the ISRG ROOT X1 certificate seems to be missing from the certificate chain after the renewal. Typically, a certificate chain consists of three components: the root certificate, intermediate certificate(s), and the server certificate.

Ah yes a terminology problem. Please see below announcement from last summer that describes what is happening to you


I understand why someone would believe this, but it is not correct. Typically a certificate chain consists of the server certificate and one or more intermediates, however many are necessary to get up to a root that the client already has in their trust store.

For the last several years, the default chain has had ISRG Root X1 acting as an intermediate: the version of that certificate presented in the chain was a cross-signed cert, issued by IdenTrust's DST Root CA X3, which used to be much more widely trusted than ISRG Root X1. So that chain had three certs, the server cert and two intermediates.

In the new default chain, that is no longer the case: ISRG Root X1 is acting as the root and is therefore not in the chain, and expected to be present in the client's trust store. So now the chain has only two certs, the server cert and one intermediate.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.