Bug 1401081

Summary:	Reencypt routes should be able to use cluster-signed certificates without providing the CA explicitly
Product:	OpenShift Container Platform	Reporter:	Ben Bennett <bbennett>
Component:	RFE	Assignee:	Marc Curry <mcurry>
Status:	CLOSED WONTFIX	QA Contact:	Meng Bo <bmeng>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.5.0	CC:	aos-bugs, bbennett, bmeng, eparis, jcosta, jforrest, jokerman, mcurry, mmccomas, myllynen, trankin
Target Milestone:	---	Keywords:	NeedsTestCase
Target Release:	---
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:	2019-06-12 11:58:23 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:

Description Ben Bennett 2016-12-02 18:28:08 UTC

Description of problem:
When cluster-signed certificeates (https://docs.openshift.com/container-platform/3.3/dev_guide/secrets.html#service-serving-certificate-secrets) are used the CA is not included in the default root of trust.  When the defaultCACertificate is not specified by the user, we should include our CA by default.

Version-Release number of selected component (if applicable):
3.3 and 3.4.

How reproducible:
Always

Steps to Reproduce:
1) Make a re-encrypt Route
2) Make a service using https://docs.openshift.com/container-platform/3.3/dev_guide/secrets.html#service-serving-certificate-secrets
3) The router needs to reference the CA for the reencrypt, but can't
4) The pods will have the generated secret mounted into them, and the servers running inside the pods will be using that cert
5) I dont want to have to set the CA on the route since as a platform consumer i'm using a route generated by the platform and service cert generated by the platform, the CA for the latter should just automatically work with the former


Actual results:

The reencrypt fails because the CA is not trusted.


Expected results:

It should work

Additional info:

Comment 1 Ben Bennett 2016-12-02 18:31:45 UTC

Note:
  oc extract $(oc get secret -o name | grep -- "-token-" | head -n1 ) --keys service-ca.crt

Gets you the ca cert that you can then put into the route to make it work.  But that's ugly.

Comment 2 Clayton Coleman 2016-12-02 18:34:01 UTC

Requirements:

1. User specifies reencrypt with no destinationCACertificate or destination cert
2. Router has to use client-ca.crt (if it exists, back compat with older routers) as well as root CA's
3. Router has to set the backend server to SERVICE.NAMESPACE.SVC.CLUSTER.LOCAL and turn hostname verification on (otherwise bad guys can MITM).

Comment 10 Kirsten Newcomer 2019-06-12 11:58:23 UTC

With the introduction of OpenShift 4, Red Hat has delivered or roadmapped a substantial number of features based on feedback by our customers.  Many of the enhancements encompass specific RFEs which have been requested, or deliver a comparable solution to a customer problem, rendering an RFE redundant.

This bz (RFE) has been identified as a feature request not yet planned or scheduled for an OpenShift release and is being closed. 

If this feature is still an active request that needs to be tracked, Red Hat Support can assist in filing a request in the new JIRA RFE system, as well as provide you with updates as the RFE progress within our planning processes. Please open a new support case: https://access.redhat.com/support/cases/#/case/new 

Opening a New Support Case: https://access.redhat.com/support/cases/#/case/new 

As the new Jira RFE system is not yet public, Red Hat Support can help answer your questions about your RFEs via the same support case system.