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.
About the author
More like this
Browse by channel
Automation
The latest on IT automation that spans tech, teams, and environments
Artificial intelligence
Explore the platforms and partners building a faster path for AI
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
Explore how we reduce risks across environments and technologies
Edge computing
Updates on the solutions that simplify infrastructure at the edge
Infrastructure
Stay up to date on the world’s leading enterprise Linux platform
Applications
The latest on our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Developer resources
- Customer support
- Red Hat value calculator
- Red Hat Ecosystem Catalog
- Find a partner
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit