Bug 1889204

Sally, I'm sending this your way, since you were involved in tracking this.

Workloads team is discussing what actions need to be taken from client-side, if any.  We'll update here during this sprint.

Adding UpcomingSprint to keep tracking this. We are waiting for oc to build with updated golang that will enable the following:

with a new env var:
x509warnCN=1

Which when set, in conjunction with
x509ignoreCN=0

Will give users both functionality and warning that it will break in the future. Without this new env var, when the golang var is set (x509ignoreCN=0) users may not be aware that they are depending upon a certificate without SAN.  The extra warning we will provide will motivate users to update their certificates as golang could in future releases remove the ability to set x509ignoreCN=0.

*** Bug 1895297 has been marked as a duplicate of this bug. ***

This is causing production issue to my customer as they can't scaleup the cluster due to this bug, the ignition while trying to communicate with api-int is getting this error. from my understanding we shouldn't update the api-int certificate. and this is not an oc command that I can add GODEBUG=x509ignoreCN=0, so what are my options

Looking into this this sprint, specifically this: "ignition while trying to communicate with api-int is getting this error" might move this issue along to the installer group? Actively working on this, will report back.

#comment 5 indicates the problem in the installer code, not with oc, moving accordingly.

Can you provide some examples of how one can reproduce this?

Please follow the step build an image registry

https://docs.openshift.com/container-platform/4.2/installing/install_config/installing-restricted-networks-preparations.html#installation-creating-mirror-registry_installing-restricted-networks-preparations

and download the 4.6 version oc cli will meet the errors

the problem usually happens on upgrade customer from the old ocp4 version, I think

Created attachment 1754528 [details]
run of oc mirroring a repository

I am unable to reproduce the problem based on the provided instructions. oc version 4.6.15 was used for this test.

We're going to close this for now.  It doesn't seem like we have the full steps to reproduce.  Feel free to reopen if you can provide the steps or have more logs to share.

Moving back to installer. These certs are created by the installer. If installer allows(ed) customers to have certs that are broken after an upgrade, it is installer's responsibility to guide the customer through steps to fix the situation. As nobody owns or controls the LBs after installation, a doc solution is probably the only way to solve this.

Architecture discussions are in progress to determine how to handle these resources.

Given that this is related to upgrade issues, moving this to the OTA team.

We don't think this would be solved in code with the installer.  Since the load balancers are not managed by the cluster, the certs would be a day-2 operation, possibly handled with a doc update.

Will review to get an updated problem space to figure out what needs to be done to address.

Hello Team,

Any updates on this?

As per 4.6 release notes [1] "The behavior of falling back to the Common Name field on X.509 certificates as a host name when no Subject Alternative Names (SANs) are present is removed. Certificates must properly set the Subject Alternative Names field. " 

It seems all users have fixed the the certificate and the issues have been resolved. Also we do not hear about the issue in recent releases i.e. 4.8, 4.9, 4.10, 4.11 etc.  So closing this bug as not a bug. 

Please re-open or file a new bug if you disagree.

[1] https://access.redhat.com/documentation/en-us/openshift_container_platform/4.6/html/release_notes/ocp-4-6-release-notes#ocp-4-6-tls-common-name