Bug 1889204 - oc failed when the certificates do not set a Subject Alternative Name
Summary: oc failed when the certificates do not set a Subject Alternative Name
Status: NEW
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 4.6
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.7.0
Assignee: Sally
QA Contact: zhou ying
: 1895297 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2020-10-19 02:18 UTC by zhou ying
Modified: 2020-11-20 08:04 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

Description zhou ying 2020-10-19 02:18:16 UTC
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):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
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

Comment 1 Maciej Szulik 2020-10-19 10:37:41 UTC
Sally, I'm sending this your way, since you were involved in tracking this.

Comment 2 Sally 2020-10-23 16:33:37 UTC
Workloads team is discussing what actions need to be taken from client-side, if any.  We'll update here during this sprint.

Comment 3 Sally 2020-11-12 17:36:46 UTC
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.

Comment 4 Sally 2020-11-12 17:51:18 UTC
*** Bug 1895297 has been marked as a duplicate of this bug. ***

Comment 5 Feras Al Taher 2020-11-17 08:14:07 UTC
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

Note You need to log in before you can comment on or make changes to this bug.