Bug 1671659

Summary:	pcs shall not generate a self-signed certificate but use indirection with it's own generated CA
Product:	Red Hat Enterprise Linux 8	Reporter:	Jan Pokorný [poki] <jpokorny>
Component:	pcs	Assignee:	Tomas Jelinek <tojeline>
Status:	CLOSED WONTFIX	QA Contact:	cluster-qe <cluster-qe>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	8.0	CC:	cfeist, cluster-maint, idevat, omular, tojeline
Target Milestone:	rc
Target Release:	8.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:	2021-02-01 07:32:25 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 Jan Pokorný [poki] 2019-02-01 08:17:41 UTC

The problem with the former is that, e.g., Firefox actively prevents
its durable installation (entrusting, "pre-trusting") since v54:

https://bugzilla.mozilla.org/show_bug.cgi?id=1294580

preventing all sorts of administrative simplifications (e.g. when
there's a way to administratively roll out set of trusted CAs to
the managed workstations).

As paradox, conga got this at least partially right, so the current
arrangement is effectively a downgrade.

Comment 1 Jan Pokorný [poki] 2019-02-01 13:59:29 UTC

For instance, with air-gapped (rigidly DMZ'd) internal networks,
there's no fear that trusting artificial and otherwise not
well-protected CA pair (cert+key) would lead a possible attacker
getting into its possession to eavesdropping or MITM'ing regular
traffic to Internet sites and services (which might be the main
barrier to import such additional CA to start with), whereas
unability to entrust the certificate programatically (which is
the case with singleton self-signed certificate) may be
inconvenient at times.

Note that this split arrangement (CA + anchored certificates) would, at 
the same time, solve a recent concern of having to have all the cluster
constituents be enumerated as a subject of a single certificate to be
shared amongst them, which hardly scales.

Comment 4 RHEL Program Management 2021-02-01 07:32:25 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.