Bug 1492700

Summary:	implement a consistency check for p11-kit source trust data, to be used by update-ca-trust
Product:	Red Hat Enterprise Linux 7	Reporter:	Frankie <Frank.Botte>
Component:	p11-kit	Assignee:	Daiki Ueno <dueno>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.4	CC:	mgrepl
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-02-11 15:39:55 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 Frankie 2017-09-18 13:48:15 UTC

Description of problem:

update-ca-trust does not give any feedback at all. Even if there are invalid certificates (without CA Flag) in /etc/pki/ca-trust/source/anchors/ no error message is given, the script even exists with a zero status

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

Name        : ca-certificates
Version     : 2017.2.14
Release     : 71.el7

How reproducible:

Just put a normal certificate (without CA Flag) in /etc/pki/ca-trust/source/anchors/ and run update-ca-trust. No error message or warning is given.

Actual results:

no output

Expected results:

There should be some kind of warning or error message if the certificate in /etc/pki/ca-trust/source/anchors/  can not be used as a CA.

Additional info:

Comment 2 Kai Engert (:kaie) (inactive account) 2017-10-17 14:40:15 UTC

The CA certificates are processed by p11-kit, so I'm reassigning the component.

I think it's a good idea to have a consistency check for the data stored in the source directories, and get a report, that update-ca-certificates could display.

This functionality would have to be implemented by the upstream p11-kit project.

Comment 3 Daiki Ueno 2018-06-07 08:00:15 UTC

Although I filed a PR in upstream some time ago, I am tempted to withdraw the change:
https://github.com/p11-glue/p11-kit/pull/124

The rationale is, while anchors are typically a CA certificate, there may be a use-case of marking end entity certificates trusted or distrusted, as it was possible with the trust assertions (the predecessor of trust policies):
https://p11-glue.github.io/p11-glue/doc/pkcs11-trust-assertions/

The design document of trust policies also has this paragraph:
"At one end of a certificate chain is the end entity certificate, which is the certificate that is being validated. At the other end the certificate chain is anchored by a trust anchor. This is a public key that is explicitly trusted by the local system, either by default or by a deliberate configuration choice. Usually this public key is represented as a certificate. The anchor is usually, but not always, a root self-signed certificate authority."

I read this as the trust of a certificate chain could be asserted out-of-band (by the local system configuration), such as only taking into account of partial certificate chain.

Comment 5 Simo Sorce 2019-02-11 15:39:55 UTC

This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.