Bug 1883690

Summary:	[REGRESSION] with golang 1.15 certs with CN only are rejected, was: apiserver no longer recognizes webhook certificates with CN
Product:	OpenShift Container Platform	Reporter:	Marek Schmidt <maschmid>
Component:	Release	Assignee:	Luke Meyer <lmeyer>
Status:	CLOSED ERRATA	QA Contact:	Xingxing Xia <xxia>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.6	CC:	afield, aos-bugs, jokerman, mfojtik, sdodson, sttts, wking, xxia
Target Milestone:	---	Keywords:	Regression
Target Release:	4.6.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-10-27 16:46:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marek Schmidt 2020-09-29 21:20:50 UTC

Description of problem:

Some layered product webhooks generates certificates that OCP 4.6 doesn't accept anymore, and logs error instead, e.g.:

"""
W0929 21:02:01.197927      18 dispatcher.go:170] Failed calling webhook, failing open mutating.knativeserving.openshift.io: failed calling webhook "mutating.knativeserving.openshift.io": Post "https://admission-server-service.openshift-operators.svc:443/mutate-knativeservings?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0
E0929 21:02:01.197968      18 dispatcher.go:171] failed calling webhook "mutating.knativeserving.openshift.io": Post "https://admission-server-service.openshift-operators.svc:443/mutate-knativeservings?timeout=30s": 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):
4.6.0-0.nightly-2020-09-29-013537

How reproducible:
Always

Steps to Reproduce:
1. Install Serverless Operator 1.8.0 from OperatorHub
2. 

oc create -f - <<EOF
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: default
spec: {}
EOF

Actual results:

knativeserving.operator.knative.dev/knative-serving created

(note, this is wrong, the validating.knativeserving.openshift.io webhook is supposed to prevent creation of KnativeServing CRs outside the knative-serving NS)

Expected results:

Error from server (KnativeServing may only be created in knative-serving namespace): error when creating "STDIN": admission webhook "validating.knativeserving.openshift.io" denied the request: KnativeServing may only be created in knative-serving namespace

Additional info:
This is a regression, webhook works fine on OCP 4.5

Comment 2 Scott Dodson 2020-09-30 15:57:49 UTC

https://github.com/openshift/images/pull/43 sets the env var in the base layer unsure whether that PR should be linked against the bug it's currently linked against or this BZ.

Comment 5 Xingxing Xia 2020-10-12 09:55:48 UTC

Researched above links, get to know what the essential problem is. Verified in 4.6.0-0.nightly-2020-10-10-041109:
1. Install later Serverless Operator from OperatorHub in OpenShift web console.
2. After related pods become Running, run:
$ oc create -f - <<EOF
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: default
spec: {}
EOF

Got as expected as comment 0:
Error from server (KnativeServing may only be created in knative-serving namespace): error when creating "STDIN": admission webhook "validating.knativeserving.openshift.io" denied the request: KnativeServing may only be created in knative-serving namespace

Comment 7 errata-xmlrpc 2020-10-27 16:46:29 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4196