Bug 1035355
| Summary: | Rebase ca-certificates in RHEL 6.6 to NSS 3.16.1 version (will remove expired Firmaprofesional cert, etc.) | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Robert Scheck <redhat-bugzilla> | |
| Component: | ca-certificates | Assignee: | Kai Engert (:kaie) (inactive account) <kengert> | |
| Status: | CLOSED ERRATA | QA Contact: | Aleš Mareček <amarecek> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | high | |||
| Version: | 6.5 | CC: | amarecek, atolani, eparis, huzaifas, jsvarova, kengert, ksrot, robert.scheck, salmy, sforsber, thatsafunnyname | |
| Target Milestone: | rc | Keywords: | Rebase, ZStream | |
| Target Release: | 6.6 | |||
| Hardware: | All | |||
| OS: | All | |||
| Whiteboard: | ||||
| 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.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1111247 (view as bug list) | Environment: | ||
| Last Closed: | 2014-10-14 07:07:16 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1099619, 1111247 | |||
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. 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. Can we please get RHEL 6.6 approval flags for this one? 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 still hoping for approval flags *** Bug 1079057 has been marked as a duplicate of this bug. *** Instead of 3.16/1.97, let's go straight to the version included with 3.16.1, which is ca-certificates 1.98 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. 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). 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! 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 |
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.