What you need to know about HTTPS Common Name deprecation in OpenShift 4.10

RFC 2818, published in May 2000, deprecates the use of the Common Name (CN) field in HTTPS certificates for subject name verification. Instead, it recommends using the “Subject Alternative Name” extension (SAN) of the “dns name” type.

The Go programming language, which constitutes the majority of Kubernetes and OpenShift, followed suit in v1.15. OpenShift 4.6 reflected the deprecation in its release notes.

In Go 1.17, the deprecation is final. This change is reflected in OpenShift 4.10, and it is effectively enforced across all cluster components.

How does this deprecation impact my OpenShift cluster?

Every time a cluster component, such as a node, an operator, or a controller, makes a call to an HTTPS server, the certificate of the target server is automatically verified. If the target server’s domain name only appears in a CN field, the connection is aborted. In this case, OpenShift 4.10 components compiled with Go 1.17 will raise this error:

x509: certificate relies on legacy Common Name field, use SANs instead

All certificates that OpenShift produces for internal use contain the required SAN fields. This error may, however, appear when core components of OpenShift communicate with external, third-party servers.

For example: OpenShift can be set up to use an alternative identity provider. In that case, if an external provider is chosen, the authentication protocol may mandate direct communication from OpenShift to the identity provider. If the identity provider exposes the relevant information via HTTPS using an invalid certificate, then OpenShift will fail to authenticate the user.

Safely upgrading to OpenShift 4.10

The final release of OpenShift 4.9.z will contain new code that validates HTTPS certificates that are exposed by external servers that support core processes of OpenShift, including authentication and custom ingress routes (see Bug 2031839). The checks will raise NoUpgrade flags, with the effect of preventing the upgrade to 4.10, thus giving the opportunity to replace the certificates while the cluster is still functional.

However, non-core processes, especially on customised setups, may not be covered by automatic verification. You can verify these processes manually by running the following command, which will print the domain names of valid certificates:

host=example.com

port=443

openssl s_client -showcerts -servername "$host" -connect "$host:$port" </dev/null 2>/dev/null  | openssl x509 -noout -ext subjectAltName

If the output is empty, then the certificate has no SAN fields and must be replaced.

Installing or upgrading to OpenShift 4.10 on OpenStack

In addition to the previous advice, we provide a script that checks the validity of the certificates for the OpenStack APIs. Run it before installing or upgrading to avoid surprises.

Fixing your server certificates

If invalid HTTPS certificates are detected, you must replace them before installing or upgrading to OpenShift 4.10.

SAN fields can only be added by issuing a new certificate signing request with the appropriate extensions, and getting the CA to issue the certificate again.

Note that OpenSSL v1.1.1 does not automatically transfer extensions from the CSR to the certificate: they have to be re-added explicitly after issuing the certificate. OpenSSL v3 will be available out-of-the-box on RHEL9 and Fedora36.