I received an email from Google Cloud[1] about the usage of X.509 Common Name, which will be not supported anymore, just the X.509 Subject Alternative Name (SAN) fields
1 -
[Action Required] Ensure compatibility of your Kubernetes Engine certificates before upgrading to version 1.23
How can I discover what kind of SSL certificate my application is using?
The Google email is not necessarily referencing your application certificates. It is about certificates used for webhooks inside Kubernetes. This is the announcement from the upstream release notes:
Kubernetes is built using golang 1.17. This version of go removes the ability to use a GODEBUG=x509ignoreCN=0 environment setting to re-enable deprecated legacy behavior of treating the CommonName of X.509 serving certificates as a host name. This behavior has been disabled by default since Kubernetes 1.19 / go 1.15. Serving certificates used by admission webhooks, custom resource conversion webhooks, and aggregated API servers must now include valid Subject Alternative Names. If you are running Kubernetes 1.22 with GODEBUG=x509ignoreCN=0 set, check the apiserver_kube_aggregator_x509_missing_san_total and apiserver_webhooks_x509_missing_san_total metrics for non-zero values to see if the API server is connecting to webhooks or aggregated API servers using certificates that will be considered invalid in Kubernetes 1.23+.
Google also offers a way to check whether this applies to your cluster or not: Ensuring compatibility of webhook certificates before upgrading to v1.23
In case you do not have Google Logging enabled, you can also check the metric apiserver_kube_aggregator_x509_missing_san_total via Prometheus or the k8s API server directly as suggested by this Red Hat Bug Ticket.
