Red Hat Bugzilla – Bug 873369
Include distrust information in /etc/pki/tls/certs/ca-bundle.trust.crt
Last modified: 2016-04-26 14:13:25 EDT
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").
taking, offering to help with this change
Created attachment 638741 [details]
Paul, what do you think?
Does openssl actually honour the distrust bit in the cert verification process, have you checked?
(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.
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).
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"?
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.
Adding as a blocker for the shared system certificates feature tracker bug #466626
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:
Kai, is this something we need to do for Fedora 19?
(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.