Bug 1492700 - implement a consistency check for p11-kit source trust data, to be used by update-ca-trust
Summary: implement a consistency check for p11-kit source trust data, to be used by up...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: p11-kit
Version: 7.4
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Daiki Ueno
QA Contact: BaseOS QE Security Team
Depends On:
TreeView+ depends on / blocked
Reported: 2017-09-18 13:48 UTC by Frankie
Modified: 2019-02-11 15:39 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-02-11 15:39:55 UTC
Target Upstream Version:

Attachments (Terms of Use)

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:

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):

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.

Note You need to log in before you can comment on or make changes to this bug.