This is not a defect in go, it is a feature. The check was added in 1.11, enabled by default in 1.15, and the opt-out will be removed in a future release. You need to update the certificate on the registry to correct the attributes.

https://golang.org/pkg/crypto/x509/#Certificate.VerifyHostname
https://go-review.googlesource.com/c/go/+/231379
https://golang.org/doc/go1.16#minor_library_changes

The GODEBUG=x509ignoreCN=0 flag will be removed in Go 1.17. It enables the legacy behavior of treating the CommonName field on X.509 certificates as a host name when no Subject Alternative Names are present.

Thanks - there I read:

"The legacy Common Name field is ignored unless it's a valid hostname, the certificate doesn't have any Subject Alternative Names, and the GODEBUG environment variable is set to "x509ignoreCN=0". Support for Common Name is deprecated will be entirely removed in the future. "

Do you have an idea which official RFC change defines the deprecation of the CN in PKI certificates?

There seems to have been some consensus among TLS clients to enforce the deprecation notice in RFC 2818, despite the fact that it's use is still required for strict conformance.

A good write-up on the issue is here: https://frasertweedale.github.io/blog-redhat/posts/2017-07-11-cn-deprecation.html

Chrome references:
https://developers.google.com/web/updates/2017/03/chrome-58-deprecations#remove_support_for_commonname_matching_in_certificates
https://www.chromestatus.com/feature/4981025180483584

RFC:
https://tools.ietf.org/html/rfc2818#section-3.1

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the Name instead.

As I have been hitting this problem now twice in customer environments I believe we should at least add this to our documentation and maybe also add this config option GODEBUG=x509ignoreCN=0 per default.

I don't think that's a good idea. These sort of certs have not been supported by browsers for 4 years, and future versions of golang will remove support for the opt-out debug variable. Better to fix the certificate.

In this case we should at least have this documented in the troubleshooting guide for RKE2 I assume..

That just feels like a short-term fix, it will break later when you upgrade to a version of Kubernetes built with a version of go that does not support the variable.

We don't currently have such a document, although field engineering may have something along those lines. I would probably recommend against documenting it on our side since it's a debug variable, and there are other knobs such as the insecure_skip_verify option in the registries.yaml configuration that can be used to more effectively disable cert validation on a per-registry basis in a forward-compatible manner without allowing invalid certs system-wide.

I believe there will be others that will run into the same problem - so troubleshooting guide and maybe a clear statement in the requirements for SSL certificates should be added? Maybe in the https://docs.rke2.io/known_issues/ ?

Do we have a tool that does a pre-check of a server and other dependencies before deploying RKE2?

I'd say that this is a super rare edge case where the root cause is a certificate management process that hasn't updated to the formally established standards in the past 4 years. As presales working in this realm of issues daily, I've only seen issues stemming from not setting SANs in a certificate one single other time in 1.5 years, which I would classify as a clear edge case and couldn't justify putting in a "known issues" section.

Maybe different customers and different scenarios. I had this problem twice in the last 4 weeks with different customers in post sales implementations with rke2, on-premise and airgapped.. and as I am pretty new to rke2 I am not sure how many customers will see this problem in the near future.. basically we have seen problems especially with the existing on premise registries and helm chart repos where customers have been using self-signed cents.....

It would be nice to habe a constructive solution. When hitting on that you get lost in the cert stuff. So when setting up k3s this will just be a time killer
Thank you for any help

This also applies when registering a new downstream RKE cluster through the UI on Rancher 2.6

This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.

I was having this problem for a long time with mongoexport. In some of my servers, setting export GODEBUG=x509ignoreCN=0 did not solve this problem. I know the modification of certificates way works. But today I discovered another solution:

--tlsInsecure

For people not caring about security of self-signed certificates and are working behind a firewall, this can be a game changer.