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