Description of problem:
For oc commands that require TLS verification, if the certificates do not set a Subject Alternative Name, verification does not fall back to the Common Name field and the command fails with the following error:
x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0
Version-Release number of selected component (if applicable):
Steps to Reproduce:
As a workaround, you can either use a certificate with a proper Subject Alternative Name set, or precede the oc command with GODEBUG=x509ignoreCN=0 to temporarily override this behavior
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:
Which when set, in conjunction with
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
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.