2

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?

Rodrigo
  • 135
  • 4
  • 45
  • 107
  • 2
    try `openssl x509 -noout -text -in /path/to/certificate.crt` to get the details about the certificate. – P.... Apr 04 '22 at 16:55
  • 1
    With current versions of openssl (1.1.1+), you can run `openssl x509 -noout -ext subjectAltName -in /path/to/certificate.crt` - you'll want to make sure that one of the DNS entries matches the expected FQDN of the web hook. – Gari Singh Apr 05 '22 at 08:36
  • 1
    You can run `openssl x509 -noout -text -in /path/to/certificate.crt | grep DNS` as well – Gari Singh Apr 05 '22 at 08:36
  • I found this X509v3 Subject Alternative Name: DNS:mycompany.com, DNS:staging.mycompany.com, DNS:www.mycompany.com this mean that I am running "X.509 Subject Alternative Name (SAN) fields" right? – Rodrigo Apr 05 '22 at 10:57

1 Answers1

0

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.

Christian
  • 1,487
  • 1
  • 14
  • 11