Bug 873369 - Include distrust information in /etc/pki/tls/certs/ca-bundle.trust.crt
Summary: Include distrust information in /etc/pki/tls/certs/ca-bundle.trust.crt
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: ca-certificates
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kai Engert (:kaie) (inactive account)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 466626
TreeView+ depends on / blocked
 
Reported: 2012-11-05 16:36 UTC by Kai Engert (:kaie) (inactive account)
Modified: 2016-04-26 18:13 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-27 13:00:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
patch v1 (4.20 KB, patch)
2012-11-05 16:39 UTC, Kai Engert (:kaie) (inactive account)
no flags Details | Diff

Description Kai Engert (:kaie) (inactive account) 2012-11-05 16:36:55 UTC
File /etc/pki/tls/certs/ca-bundle.trust.crt
contains the Mozilla CA bundle, together with trust flags.

However, as of today, only the set of whitelisted CAs are included.

I believe it would be good to include the blacklisted certs together with distrust flags (as can be produced using openssl x509 "-addreject").

Comment 1 Kai Engert (:kaie) (inactive account) 2012-11-05 16:37:34 UTC
taking, offering to help with this change

Comment 2 Kai Engert (:kaie) (inactive account) 2012-11-05 16:39:40 UTC
Created attachment 638741 [details]
patch v1

Paul, what do you think?

Comment 3 Joe Orton 2012-11-05 21:10:12 UTC
Does openssl actually honour the distrust bit in the cert verification process, have you checked?

Comment 4 Kai Engert (:kaie) (inactive account) 2012-11-05 22:02:13 UTC
(In reply to comment #3)
> Does openssl actually honour the distrust bit in the cert verification
> process, have you checked?

I had not checked before.

I just tried to test with openssl 1.0.0j.
In the hope I did everything correctly:

Bad luck. "openssl verify -CAfile" doesn't honour the distrust flags in the CA file.

Comment 5 Kai Engert (:kaie) (inactive account) 2012-11-06 18:16:33 UTC
I spent today with analyzing openssl's behavior in greater detail.
The story is much more complicated.

First, Joe, a question: Do you know why file ca-bundle.trust.crt (trust flags) got added to ca-certificates in the first place? Do you know what applications using these file expect? Do you have reason to believe that any application would be confused if we suddently started to include entries with distrust, only?

Next, regarding openssl.

When I said in comment 4, that openssl doesn't appear to make use of the distrust flags at all (contained in certificates using the BEGIN TRUSTED CERTIFICATE format), then my statement was based on the behaviour of "openssl verify".

Yes, "openssl verify" doesn't appear to make use of the flags. Today I tested with openssl 1.0.1c. I traced the code, and couldn't find any code that would ever access the X509_CERT_AUX attributes (which contains the "trust" and "reject" attributes).

But I incorrectly concluded that to be an universal behavior of openssl.

Today I found that openssl supports the different (newer?) API to specify the trusted CA data, SSL_CTX_load_verify_locations.

The openssl s_client is an example of a command that uses it, and when feeding a CA file with distrust flags for the root CA to s_client, then s_client indeed reports the server certificate as "rejected".

In other words, the same -CAfile argument behaves differently, depending on the specific tool that you use!

It's unfortunate that openssl applications are inconsistent in this way.

But the good news is: Yes, there are some applications that are indeed able to make use of the new file format.

Unless you can show that it would hurt anyone if ca-bundle.trust.crt contained distrusted certificates, I think we should add them.

IMHO any application that wants to read ca-bundle.trust.crt (instead of the older format) should be able to deal with both trust and reject flags.


Finally, another (unrelated) finding. Reading the source of the "openssl verify" command, I found that it has undocumented command line options "-trusted" and "-untrusted". Instead of feeding one -CAfile, it's possible to specify separate -trusted and -untrusted files, and "openssl verify" will work as expected (rejecting certs issued by a CA that is listed in the "untrusted" file, but not listed in the "trusted" file).

Comment 6 Joe Orton 2012-11-06 20:38:53 UTC
1) Because I wanted to be able to preserve the complete trust information from the Mozilla certdata.txt and expose it to OpenSSL.

2) It works?  Awesome!  That's really great.

3) Your patch looks perfect, I'll commit it.

4) Did you try passing a -purpose argument to "openssl verify"? 

5) I'm not sure it is totally surprising that "openssl verify" alone works differently to "openssl s_client" - possibly the X.509 purpose checking needs to be enabled?  Did you try passing -purpose to "verify"?

Comment 7 Kai Engert (:kaie) (inactive account) 2013-03-05 15:54:02 UTC
The patch was not yet committed.

We had not made a final decision yet, if we agree to include the distrusted certificates in ca-bundle.trust.crt.

I would like to declare the following:
- the file format includes trust statements, 
  and by definition this means that a consuming application MUST
  be able to correctly with such trust flags

- any application that already consumes the existing ca-bundle.trust.crt
  but fails to distrust the distrusted certs, is a buggy application,
  and must be fixed

I therefore propose to ahead with this bug and complete it in fedora rawhide immediately.

I need this new patch to land within next 1-2 days in order to support the shared-system-certificates features.

I'm willing to handle this work, because we need to get other changes to the ca-certificates package done, too, e.g. like converting files to symlinks that point to a dynamically generated location.

Objections?

Comment 8 Stef Walter 2013-03-06 20:13:47 UTC
Adding as a blocker for the shared system certificates feature tracker bug #466626

Comment 9 Fedora End Of Life 2013-04-03 15:35:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 10 Stef Walter 2013-05-14 12:02:15 UTC
Kai, is this something we need to do for Fedora 19?

Comment 11 Kai Engert (:kaie) (inactive account) 2013-05-27 13:00:16 UTC
(In reply to Stef Walter from comment #10)
> Kai, is this something we need to do for Fedora 19?

This has already been addressed by our work for Fedora 19.


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