invalid signature: parent certificate cannot sign this kind of certificate

[brandond]

from @Dridge in #8252 (comment)

Hi, wonder if you can help, is it expected that this feature would need a k3s restart? I can't disable the option at the moment, true or false in the k3s server command doesn't appear to make a difference. /usr/local/bin/k3s server --tls-san-security=false ...

I see this error when trying to access a docker registry in my k3s cluster:
tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate" while trying to verify candidate authority certificate "myhostname")"

It is a self signed certificate created through ansible, with a common name set, and even explicitly adding a SAN has the same issue.

Despite trying this flag and trying to add the SAN explicitly to the docker registries certificate I have to perform a k3s restart near the end of my ansible deployment. Is that expected?

[brandond]

The invalid signature: parent certificate cannot sign this kind of certificate error you're seeing would not be caused by SAN filtering. This error suggests that there is a problem with the certificate chain, such as certificate being signed by an issuer whose certificate does not allow operation as a CA, or does not allow signing certificates of specific types.

All of the certificates generated internally by K3s should be set up properly with the correct usages, so I suspect you have an incorrectly configured certificate elsewhere in your environment. If you are able to provide more context on this error message I might be able to help narrow down where that might be.

[Dridge]

Thanks for your help. I will take a closer look at the certificates. It's strange that a k3s restart currently seems to resolve the problem. But it might be a P.I.C.N.I.C issue with the manual testing I'm doing. Will confirm shortly i hope.

[Dridge]

I got to the bottom of this issue, it looks related to our usecase, but specifically it only occurs when we change the clustername during the upgrade to latests k3s. And how we manage the credential data etc. It looks unrelated to k3s repo changes. Thanks for the swift response!