Bug 1158197 - Allow disabling of legacy root CA certificates as a system configuration
Summary: Allow disabling of legacy root CA certificates as a system configuration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ca-certificates
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kai Engert (:kaie) (inactive account)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1144808 1158343
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-28 19:52 UTC by Kai Engert (:kaie) (inactive account)
Modified: 2014-12-13 09:40 UTC (History)
14 users (show)

Fixed In Version: ca-certificates-2014.2.1-1.5.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-18 12:23:23 UTC


Attachments (Terms of Use)
Difference between upstream certdata.txt and the edited version with legacy flags (59.76 KB, patch)
2014-10-28 22:35 UTC, Kai Engert (:kaie) (inactive account)
no flags Details | Diff

Description Kai Engert (:kaie) (inactive account) 2014-10-28 19:52:30 UTC
This is follow-up work for bug 1144808.
See that other bug for the reasons that drive this work.

The purpose of this new bug is to:
- keep legacy roots enabled by default
- allow the system administrator to disable legacy roots
- remember the admin's action, making it the new default for future updates

In other words, if the admin never acts, future updates will continue to keep legacy roots enabled - as long as we think it's necessary for compatibility reasons with all software packages.

If the admin acts once, the system will completely follow the upstream decisions of the Mozilla CA maintainers. If additional roots get disabled/removed, they will get disabled on the system, too.

This is an initial implemention, which attempts to be very simple.

It would be more difficult to implement a solution that allowed the admin to configure legacy roots independently. (Should such a solution be asked for, it can be implemented using additional follow-up work.)

In detail:

I've implemented a new utility,
  ca-legacy
which offers the following commands:
 - enable
 - disable
 - check
 - install

The enable command configures the enabled state, which is equivalent to the "no configuration present" state.

The disable command configures the disabled state.

The configured state is stored in config file
  /etc/pki/ca-trust/ca-legacy.conf

The install command is used to perform the necessary system changes (using a symbolic link), that will either enable or disable legacy certs, based on the configuration file. It is executed at package install time, and when using the enable/disable commands.

The check command prints a human readable summary of the current configuration.

Legacy certs might be "partially" removed by upstream, that is, a root might have it's trust removed for e.g. TLS, but might still be marked for email security.

This is why we must use two alternative lists of roots (and cannot simply enable a file in addition).

The input file certdata.txt, as provided by upstream, will be edited by the package maintainer to add new legacy flags, as required for Fedora/OpenSSL/GnuTLS.

Each root that contains a legacy flag, will be placed into the separate lists of legacy alternatives.

Comment 1 Kai Engert (:kaie) (inactive account) 2014-10-28 20:09:41 UTC
Packages with this feature are ready for testing:

Rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7965554

Fedora 21 testing:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7965585

Comment 2 Kai Engert (:kaie) (inactive account) 2014-10-28 20:28:26 UTC
scratch build for testing with Fedora 20:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7965788

Comment 3 Kai Engert (:kaie) (inactive account) 2014-10-28 22:35:31 UTC
Created attachment 951580 [details]
Difference between upstream certdata.txt and the edited version with legacy flags

Comment 5 Kai Engert (:kaie) (inactive account) 2014-10-29 12:04:00 UTC
Updated builds that fix a missing Requires:coreutils

rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7974865

f21:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7975013

f20 scratch:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7975053

Comment 6 Fedora Update System 2014-10-29 13:13:26 UTC
ca-certificates-2014.2.1-1.3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.3.fc21

Comment 7 Fedora Update System 2014-10-31 01:24:52 UTC
Package ca-certificates-2014.2.1-1.3.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ca-certificates-2014.2.1-1.3.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-13900/ca-certificates-2014.2.1-1.3.fc21
then log in and leave karma (feedback).

Comment 8 Vít Ondruch 2014-11-10 12:51:11 UTC
Hmmm, I'd expect that with this update, RubyGems should work, but they don't:


$ rpm -q ca-certificates
ca-certificates-2014.2.1-5.fc22.noarch

$ cat /etc/pki/ca-trust/ca-legacy.conf 
# legacy=enable :
#   Certain legacy certs, that have been removed by upstream Mozilla,
#   are still marked as trusted, if required for backwards compatibility
#   with cryptographic libraries like openssl or gnutls.
#
# legacy=disable :
#   Follow all removal decisions of upstream Mozilla CA maintainers
#
legacy=enable

$ gem install gem2rpm
ERROR:  Could not find a valid gem 'gem2rpm' (>= 0), here is why:
          Unable to download data from https://rubygems.org/ - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz)

Comment 9 Fedora Update System 2014-11-14 16:20:19 UTC
ca-certificates-2014.2.1-1.4.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.4.fc21

Comment 10 Fedora Update System 2014-11-15 09:14:31 UTC
Package ca-certificates-2014.2.1-1.5.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ca-certificates-2014.2.1-1.5.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15103/ca-certificates-2014.2.1-1.5.fc21
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2014-11-18 12:23:23 UTC
ca-certificates-2014.2.1-1.5.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Kai Engert (:kaie) (inactive account) 2014-11-18 16:36:21 UTC
(In reply to Vít Ondruch from comment #8)
> Hmmm, I'd expect that with this update, RubyGems should work, but they don't:
...

> $ gem install gem2rpm
> ERROR:  Could not find a valid gem 'gem2rpm' (>= 0), here is why:
>           Unable to download data from https://rubygems.org/ - SSL_connect
> returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify
> failed
> (https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz)


On Rawhide 22 with ENABLED this command works for me, no errors (works on 21, too).


> $ cat /etc/pki/ca-trust/ca-legacy.conf 
...
> legacy=enable

More interesting to confirm the configuration is the output of the command
  ca-legacy check
which should report
  ENABLED

(The config file is read on package upgrades only.)

I'm confused why it doesn't work for you.

Comment 13 Kai Engert (:kaie) (inactive account) 2014-11-18 16:38:13 UTC
(In reply to Fedora Update System from comment #11)
> ca-certificates-2014.2.1-1.5.fc21 has been pushed to the Fedora 21 stable
> repository.  If problems still persist, please make note of it in this bug
> report.

Peter, the package wasn't intended for stable yet, only for testing :-(

(My previous packaged had been pushed to updates-testing only, with karma disabled.)

Comment 14 Vít Ondruch 2014-11-18 16:56:20 UTC
Hmmm, interesting, it works now:


$ rpm -q ca-certificates
ca-certificates-2014.2.1-7.fc22.noarch

$ cat /etc/pki/ca-trust/ca-legacy.conf
# legacy=enable :
#   Certain legacy certs, that have been removed by upstream Mozilla,
#   are still marked as trusted, if required for backwards compatibility
#   with cryptographic libraries like openssl or gnutls.
#
# legacy=disable :
#   Follow all removal decisions of upstream Mozilla CA maintainers
#
legacy=enable

$ ca-legacy check
Legacy CAs are set to ENABLED in file /etc/pki/ca-trust/ca-legacy.conf (affects install/upgrade)
Status of symbolic link /etc/pki/ca-trust/source/ca-bundle.legacy.crt:
/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.enable.crt

$ gem install gem2rpm
Fetching: gem2rpm-0.10.1.gem (100%)
Successfully installed gem2rpm-0.10.1
Parsing documentation for gem2rpm-0.10.1
Installing ri documentation for gem2rpm-0.10.1
Done installing documentation for gem2rpm after 0 seconds
1 gem installed


So hopefully, everything is all right. SO problem solved (I hope it is not just due to changes RubyGems upstream is doing/did with their certificates ;)).

Comment 15 Kai Engert (:kaie) (inactive account) 2014-11-20 16:49:07 UTC
(In reply to Vít Ondruch from comment #14)
> Hmmm, interesting, it works now:

I'm glad to hear about your success :-)


> So hopefully, everything is all right. SO problem solved (I hope it is not
> just due to changes RubyGems upstream is doing/did with their certificates
> ;)).

Seems unlikely.

If I run
  ca-legacy disable
and then repeat the "gem install gem2rpm" command,
then I see the failure you had reported earlier.

This seems to confirm that RubyGems indeed uses our system certificates.

Then I ran
  ca-legacy enable
and repeated the "gem" command again, and it worked again.

So hopefully, when you saw the error at the earlier time, something hasn't configured correctly, and you fixed it afterwards.

Please let me know if you ever see the failure again while having things "enable"'d, I really hope won't don't have any kind of intermittent failure.

Comment 16 Kai Engert (:kaie) (inactive account) 2014-11-20 16:53:35 UTC
(In reply to Kai Engert (:kaie) from comment #13)
> Peter, the package wasn't intended for stable yet, only for testing :-(

Nevertheless, Peter, thanks for having worked on the Requires(post) fix!

Since the package seems to work as intended, it should be fine to have pushed it out.

For f20/f19, I'd like to push out the same code, however, want start with updates-testing, only. Let's wait for additional feedback and a test period, prior to pushing to stable updates on f20/f19.

Comment 17 Fedora Update System 2014-11-20 17:46:04 UTC
ca-certificates-2014.2.1-1.5.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc19

Comment 18 Fedora Update System 2014-11-20 17:46:16 UTC
ca-certificates-2014.2.1-1.5.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc20

Comment 19 Fedora Update System 2014-12-13 09:34:52 UTC
ca-certificates-2014.2.1-1.5.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Fedora Update System 2014-12-13 09:40:05 UTC
ca-certificates-2014.2.1-1.5.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


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