Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1848180

Summary:	unable to setup tls-e with public tls certs
Product:	Red Hat OpenStack	Reporter:	Ade Lee <alee>
Component:	openstack-tripleo-heat-templates	Assignee:	Ade Lee <alee>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jeremy Agee <jagee>
Severity:	high	Docs Contact:
Priority:	high
Version:	16.1 (Train)	CC:	amcleod, hrybacki, mburns, ramishra, rheslop, sclewis, scohen
Target Milestone:	ga	Keywords:	Triaged
Target Release:	16.1 (Train on RHEL 8.2)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Known Issue
Doc Text:	There is a known issue where a heat parameter `InternalTLSCAFile` is used during deployment when the undercloud contacts the external (public) endpoint to create initial resources and projects. If the internal and public interfaces have certificates from different Certificate Authorities (CAs), the deployment fails. Either the undercloud fails to contact the keystone public interface, or the internal interfaces receive malformed configuration. + This scenario affects deployments with TLS Everywhere, when the IPA server supplies the internal interfaces but the public interfaces have a certificate that the operator supplies. This also prevents 'brown field' deployments, where deployments with existing public certificates attempt to redeploy and configure TLS Everywhere. + There is currently no workaround for this defect.	Story Points:	---
Clone Of:
Clones:	1852620 (view as bug list)		Environment:
Last Closed:	2020-09-09 19:17:47 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:
Bug Depends On:
Bug Blocks:	1852620

Description Ade Lee 2020-06-17 20:51:19 UTC

Description of problem:

There was an error in the fix that was committed in commit 42cfbbc8bfbaa401d6e774b58cb78f4bbaccc2d9 in THT. The relevant data that is written to clouds.yaml is constructed here:

https://github.com/openstack/tripleo-heat-templates/blob/master/deployment/keystone/keystone-container-puppet.yaml#L746-L760

The problem here is that the auth_url refers to the public endpoint, whereas the CA cert defined there is for the internal endpoint. That is, the parameter InternalTLSCAFile is only supposed to be used to refer to the ca cert used for TLS on internal endpoints.

Now, you would not see a problem if you had a deployment with TLS-Everywhere where all the certs (both public and private) are issued by the IPA server.

Nor would you see a problem with just public TLS - although this is somewhat lucky because the parameter InternalTLSCAFile is really being used incorrectly to refer to where the public TLS CA cert is located. In this case, the deployment can work because the InternalTLSCAFile is not being used on the internal interfaces. It can however lead to weird upgrade problems and has in fact led to some infrared failures.

Where you will definitely see a problem though is when you try to set up an environment where the public interface cert is issued by a given cert ("public TLS") and the internal interfaces are protected by certs issued by IPA. This is essentially the environment that is set up when we try to do a brownfield deployment. That is , update a public TLS only system to have tls-everywhere but keep the public certs intact.

It won't work because what you need to insert to allow the undercloud to reach keystone in cloud.yaml (on the public interface) is not the same as what is needed to set up the internal interfaces correctly.

I tested this - and there is simply no way to make it work. You can't use the same parameter to make both public and private interfaces happy.

What I did test though, was adding a new parameter ExternalTLSCAFile - which I defaulted to "" to the keystone template. This is after all exactly what we are describing in clouds.yaml. With that change, I was able to get the brownfield deployment to work.

This is blocking the verification of:

   https://bugzilla.redhat.com/show_bug.cgi?id=1715592

and the resolution here will obsolete: 

   https://bugzilla.redhat.com/show_bug.cgi?id=1845091

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: