RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1035355 - Rebase ca-certificates in RHEL 6.6 to NSS 3.16.1 version (will remove expired Firmaprofesional cert, etc.)
Summary: Rebase ca-certificates in RHEL 6.6 to NSS 3.16.1 version (will remove expired...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ca-certificates
Version: 6.5
Hardware: All
OS: All
high
medium
Target Milestone: rc
: 6.6
Assignee: Kai Engert (:kaie) (inactive account)
QA Contact: Aleš Mareček
URL:
Whiteboard:
: 1079057 (view as bug list)
Depends On:
Blocks: 1099619 1111247
TreeView+ depends on / blocked
 
Reported: 2013-11-27 15:46 UTC by Robert Scheck
Modified: 2018-12-06 15:30 UTC (History)
11 users (show)

Fixed In Version: ca-certificates-2014.1.98-65.1.el6
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
The ca-certificate package has been upgraded to version 2014.1.98, released with Network Security Services (NSS) version 3.16.1, which provides a number of enhancements over the previous version.
Clone Of:
: 1111247 (view as bug list)
Environment:
Last Closed: 2014-10-14 07:07:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 919480 0 None None None Never
Red Hat Bugzilla 1035370 0 unspecified CLOSED x509watch should exclude further CA bundles from RHEL 6.5 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHEA-2014:1500 0 normal SHIPPED_LIVE ca-certificates enhancement update 2014-10-14 01:28:12 UTC

Internal Links: 1035370

Description Robert Scheck 2013-11-27 15:46:23 UTC 
Description of problem:
Since RHEL 6.5, the package ca-certificates-2013.1.94-65.0.el6.noarch ships
with /etc/pki/ca-trust/extracted/pem/{email,tls}-ca-bundle.pem already expired
root certificates:

$ yum install x509watch -y
[...]
$

$ ntpdate -q ptbtime1.ptb.de; x509watch; ntpdate -q ptbtime1.ptb.de
server 192.53.103.108, stratum 1, offset 0.000020, delay 0.03596
27 Nov 16:28:32 ntpdate[453]: adjust time server 192.53.103.108 offset 0.000020 sec
/etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem (Autoridad de Certificacion Firmaprofesional CIF A62634068) is not valid since 2013-10-24
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (Autoridad de Certificacion Firmaprofesional CIF A62634068) is not valid since 2013-10-24
server 192.53.103.108, stratum 1, offset 0.000289, delay 0.03603
27 Nov 16:28:39 ntpdate[855]: adjust time server 192.53.103.108 offset 0.000289 sec
$ 

Unfortunately the file is a bundle thus I extracted the affected certificate
here (I would say it is the same certificate in both files):

-----BEGIN CERTIFICATE-----
MIIEVzCCAz+gAwIBAgIBATANBgkqhkiG9w0BAQUFADCBnTELMAkGA1UEBhMCRVMx
IjAgBgNVBAcTGUMvIE11bnRhbmVyIDI0NCBCYXJjZWxvbmExQjBABgNVBAMTOUF1
dG9yaWRhZCBkZSBDZXJ0aWZpY2FjaW9uIEZpcm1hcHJvZmVzaW9uYWwgQ0lGIEE2
MjYzNDA2ODEmMCQGCSqGSIb3DQEJARYXY2FAZmlybWFwcm9mZXNpb25hbC5jb20w
HhcNMDExMDI0MjIwMDAwWhcNMTMxMDI0MjIwMDAwWjCBnTELMAkGA1UEBhMCRVMx
IjAgBgNVBAcTGUMvIE11bnRhbmVyIDI0NCBCYXJjZWxvbmExQjBABgNVBAMTOUF1
dG9yaWRhZCBkZSBDZXJ0aWZpY2FjaW9uIEZpcm1hcHJvZmVzaW9uYWwgQ0lGIEE2
MjYzNDA2ODEmMCQGCSqGSIb3DQEJARYXY2FAZmlybWFwcm9mZXNpb25hbC5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDnIwNvbyOlXnjOlSztlB5u
Cp4Bx+ow0Syd3Tfom5h5VtP8c9/Qit5Vj1H5WuretXDE7aTt/6MNbg9kUDGvASdY
rv5sp0ovFy3Tc9UTHI9ZpTQsHVQERc1ouKDAA6XPhUJHlShbz++AbOCQl4oBPB3z
hxAwJkh91/zpnZFx/0GaqUC1N5wpIE8fUuOgfRNtVLcK3ulqTgesrBlf3H5idPay
BQC6haD9HThuy1q7hryUZzM1gywfI834yJFxzJeL764P3CkDG8A563DtwW4O2GcL
iam8NeTvtjS0pbbELaW+0MOUJEjb35bTALVmGotmBQ/dPz/LP6pemkr4tErvlTcb
AgMBAAGjgZ8wgZwwKgYDVR0RBCMwIYYfaHR0cDovL3d3dy5maXJtYXByb2Zlc2lv
bmFsLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEBMCsGA1UdEAQkMCKADzIwMDExMDI0
MjIwMDAwWoEPMjAxMzEwMjQyMjAwMDBaMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E
FgQUMwugZtHq2s7eYpMEKFK1FH84aLcwDQYJKoZIhvcNAQEFBQADggEBAEdz/o0n
VPD11HecJ3lXV7cVVuzH2Fi3AQL0M+2TUIiefEaxvT8Ub/GzR0iLjJcG1+p+o1wq
u00vR+L4OQbJnC4xGgN49Lw4xiKLMzHwFgQEffl25EvXwOaD7FnMP97/T2u3Z36m
hoEyIwOdyPdfwUpgpZKpsaSgYMN4h7Mi8yrrW6ntBas3D7Hi05V2Y1Z0jFhyGzfl
ZKG+TQyTmAyX9odtsz/ny4Cm7YjHX1BiAuiZdBbQ5rQ58SfLyEDW44YQqSMSkuBp
QWOnryULwMWSyx6Yo1q6xTMPoJcB3X/ge9YGVM+h4k0460tQtcsm9MracEpqoeJ5
quGnM/b9Sh/22WA=
-----END CERTIFICATE-----

Actually it is strange that the fresh released RHEL 6.5 ships an expired
root certificate. Why is this case? Why did QA not notice this? It does not 
cause harm other than e.g. x509watch(1) and likely certwatch(1) (as part of 
crypto-utils) will daily send an e-mail about that fact, but that is still
bothering for lots of systems.

Version-Release number of selected component (if applicable):
ca-certificates-2013.1.94-65.0.el6.noarch

How reproducible:
Everytime, see above and below.

Actual results:
Files /etc/pki/ca-trust/extracted/pem/{email,tls}-ca-bundle.pem contain
expired root certificates.

Expected results:
Files /etc/pki/ca-trust/extracted/pem/{email,tls}-ca-bundle.pem do not
contain expired root certificates.
Comment 1 Kai Engert (:kaie) (inactive account) 2013-11-27 16:19:38 UTC 
Hello Robert,

we ship the set of root CA certificates as maintained by the Mozilla CA policy.

It's probably a good idea to get this expired certificate removed, there's an upstream bug tracking the removal.
Comment 3 RHEL Program Management 2013-12-01 09:06:20 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 6 Kai Engert (:kaie) (inactive account) 2014-01-07 21:54:24 UTC 
Can we please get RHEL 6.6 approval flags for this one?
Comment 8 Kai Engert (:kaie) (inactive account) 2014-02-17 20:58:04 UTC 
This change will be part of NSS 3.16, which still isn't released.

I'm morphing this one into a general "rebase ca-certificates for RHEL 6.6" bug.

This bug should be cloned for RHEL 6.5.z at a later time, as soon as Firefox picks up NSS 3.16
Comment 9 Kai Engert (:kaie) (inactive account) 2014-02-17 20:58:46 UTC 
still hoping for approval flags
Comment 10 Kai Engert (:kaie) (inactive account) 2014-03-21 11:26:15 UTC 
*** Bug 1079057 has been marked as a duplicate of this bug. ***
Comment 11 Kai Engert (:kaie) (inactive account) 2014-05-20 18:27:36 UTC 
Instead of 3.16/1.97, let's go straight to the version included with 3.16.1, which is ca-certificates 1.98
Comment 15 Kai Engert (:kaie) (inactive account) 2014-07-04 09:48:36 UTC 
Robert, I think you are the developer of the x509watch script, is that correct?

I would like to suggest to NOT warn about expiring root CA certificates (self signed, same issuer and same subject).

I understand the intention of the script is to warn administrators about the requirement to refresh their system configuration, get renewed server certificate, or mabye replace expiring intermediate CA certs.

However, expiring root CA certificates aren't a problem.

Well, they are a problem in only one scenario: If the CA has decided to replace the root CA certificate using a identically looking certificate (same name), but with a longer validity (expiration date more in the future).

This happens, but it's rare. Most of the time, the CA stops issueing certificates using the expiring old root CA cert, get a new cert added to software stores (using a different subject), and start issueing certificates signed with the newer CA cert.

If the CA really wants to go the replacement path, they must be aware of the delays it takes to get such a replacement cert approved, added to software, and deployed to all relevant consumer systems.

Thus, a CA must start such a process well in advance. Because managing their certificates is the primary job of a CA, and the primary factor for guaranteeing the operation of their business, we should assume that a CA will take care of doing it early.

There's only one scenario, where an expiring root CA certificate can cause a problem:
- the CA issues a REPLACEMENT root CA certificate (rare)
- the system doesn't receive the replacement root CA certificate
  with package updates.

We had an issue in the past, where an old RHEL version didn't get updates to the root CA bundle. I hope this won't happen again.

So, usually, if a CA wants to do a replacement, and the CA starts that process sufficiently early, the replacement will get approved in time (e.g. by the Mozilla CA Policy), it will get added to software in time, and software vendors/distributors can ship updates in time, which replace it.

If the CA fails to do that, a warning about the expired root CA cert happens won't help an administrator anyway.

There's only one scenario, where a warning about an expiring root CA cert MIGHT help: If the operating system, or if a particular computer doesn't get regular updates to the upstream root CA list. Since RHEL does get such updates, I propose that you disable the check for expired root CA certs (self signed) on RHEL system.
Comment 16 Robert Scheck 2014-07-04 09:59:26 UTC 
Kai, I additionally excluded the root CA bundles "email-ca-bundle.pem",
"objsign-ca-bundle.pem", and "tls-ca-bundle.pem" with x509watch 0.6.0.
My initial concern was that the (at that time) new RHEL 6.5 update was
shipping an already expired root CA. I will not exclude self-signed CA
certs by default because nobody would then notice the expiration of a
root CA cert that is not shipped by ca-certificates (like CAcert etc).
Comment 17 Kai Engert (:kaie) (inactive account) 2014-07-04 10:08:55 UTC 
Robert, fair enough, if you exlude the root CA bundles shipped as part of the OS, that should be sufficient to silence unnecessary warnings which the admin cannot fix anyway. Thanks!
Comment 21 errata-xmlrpc 2014-10-14 07:07:16 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2014-1500.html
Note You need to log in before you can comment on or make changes to this bug.