Why do OpenSSL connections to Let's Encrypt fail after 30 September 2021?

You experience connectivity issues with OpenSSL versions before 1.1 against websites with the default Let's Encrypt configuration.

When you try to connect to websites that have the default Let's Encrypt configuration by using OpenSSL you see an error message similar to the following.

bad result:
connection failed
verify depth is 1
CONNECTED(00000003)
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
verify error:num=10:certificate has expired
notAfter=Jan 30 14:01:15 2021 GMT
140672978626200:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

Certificates that are automatically generated by Red Hat OpenShift on IBM Cloud have a cross-signature "DST Root CA X3" which expires on 30 September 2021.

Usually, there is no impact due to the certificates having the root certificate "ISRG Root X1", which is trusted by most modern operating systems and web browsers. However, for TLS clients with the containers.appdomain.cloud subdomain that were automatically generated for your cluster during initial cluster provisioning, or those created by using the ibmcloud ks nlb-dns command might be impacted.

TLS clients using OpenSSL 1.1 or greater and newer web browsers aren't impacted. Impacted TLS clients include clients using versions before OpenSSL 1.1. and also have the "DST Root CA X3" in their root truststore.

No actions need to be taken to Red Hat OpenShift on IBM Cloud or Satellite. However, if there are TLS clients connecting to the Kubernetes Ingress controller, OpenShift router, or custom services with a containers.appdomain.cloud subdomain, it is recommended that these clients be updated to the latest version to prevent downtime.

For more information, see the following links.