Bug 733032 - Missing VeriSign Certificate
Summary: Missing VeriSign Certificate
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: ca-certificates
Version: 15
Hardware: noarch
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-24 14:30 UTC by Philip Rose
Modified: 2012-08-07 19:53 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-07 19:53:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
The missing certificate (2.51 KB, application/octet-stream)
2011-11-04 23:26 UTC, Brad
no flags Details
For your review, I'd propose this patch to fix this. (1.35 KB, patch)
2011-11-15 18:35 UTC, Brad
no flags Details | Diff
For your review, I'd propose this patch to fix this. (1.51 KB, patch)
2011-11-15 18:43 UTC, Brad
no flags Details | Diff

Description Philip Rose 2011-08-24 14:30:42 UTC
Description of problem:
This certificate is missing.  "/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA"


Version-Release number of selected component (if applicable):
ca-certificates-2011.70-2.fc15.noarch


How reproducible:
Always


Steps to Reproduce:
1.  wget https://secure.vonage.com/

  
Actual results:
wget returns error because of missing certificate.



Expected results:



Additional info:

Comment 1 Brad 2011-11-04 23:20:31 UTC
I believe The actual problem is *not* the lack of the intermediate certificate "CN=VeriSign Class 3 Extended Validation SSL SGC CA", it is in fact that a root certificate 

Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Serial: 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf

was present in ca-certificates 2010.63-3, but missing in the recently released ca-certificates-2011.78-1.fc14.noarch.  The missing CA certificate is still valid according to VeriSign and Mozilla.

This is a bit confusing, although the root certificate is valid, VeriSign stopped using it for signing in 5/2009, replacing it with another certificate with the same subject and keyid, but a different serial number (3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be), as part of their move away from MD2 signatures.

My workaround:  Add the dropped certificate manually back into /etc/pki/tls/certs/ca-bundle.crt

I notice that big sites such as vonage, paypal, optionsxpress still deliver certificates whose trust is ultimately established by the now missing root certificate.

Comment 2 Brad 2011-11-04 23:26:04 UTC
Created attachment 531861 [details]
The missing certificate

Appending this root certificate to /etc/pki/tls/certs/ca-bundle.crt restores validation of the sites mentioned herein.  But it's never a good idea to trust root CA's from strangers.  So consider this as posted just for reference. :)

Comment 3 Joe Orton 2011-11-07 13:49:13 UTC
The list of trusted CAs is inherited from upstream (Mozilla) and we are not going to change it ourselves within Fedora - sorry.

Comment 4 Brad 2011-11-07 17:40:35 UTC
(In reply to comment #3)
> The list of trusted CAs is inherited from upstream (Mozilla) and we are not
> going to change it ourselves within Fedora - sorry.

Just a few more notes.

Both the SH1 and MD2 certificates *do* appear to be included in Mozilla's certdata.txt r1.78 (at lines 1010 and 17805), yet the MD2 certficate is not in ca-bundle.crt in package ca-certificates.

I believe the bug is in certdata2pem.py, which does not handle the case where two certificates have the same CKA_LABEL (as is the case in certdata.txt r1.78), since it tries to output both certificates to the same file (one overwrites the other).  

I'll add for the google that the Class 3 certificate is not the only one that gets dropped from ca-bundle.pem by the certdata2pem.py script.  "Verisign Class 1 Public Primary Certification Authority" also appears as the label of two different certs (same underlying key, signed in two different ways).

Regards,
Brad

Comment 5 Joe Orton 2011-11-09 22:39:36 UTC
Ah, good catch Brad, thanks for checking!

Comment 6 Brad 2011-11-15 18:35:36 UTC
Created attachment 533817 [details]
For your review, I'd propose this patch to fix this.

Comment 7 Brad 2011-11-15 18:43:09 UTC
Created attachment 533818 [details]
For your review, I'd propose this patch to fix this.

Oops, RHBZ didn't like my patch format.  Try this.

Comment 10 Fedora End Of Life 2012-08-07 19:53:09 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


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