Andrew Stephen Reporter
	Description • 20 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.8

Thawte have replaced their SCG CA certificate as of 16/07/2004.  The new
certificate is not pre-installed in Firefox 0.9.2.  This problem probably exists
for all platforms but I have tested only the Windows version at this stage.

New Thawte CA certs can be downloaded from http://www.thawte.com/roots/

Reproducible: Always
Steps to Reproduce:
1. Go to any HTTPS server using Thawte SGC CA.

	Bob
	Comment 1 • 20 years ago

Yes, also encountered with
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1

	Andrew Meaden
	Comment 2 • 20 years ago

This still appears to be the case in Mozilla Firefox 0.10.1

Is this fixed, or planned to be fixed ?

-- Andrew
andrew@pirionsystems.com.au

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040707 Firefox/0.8
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040707 Firefox/0.8
> 
> Thawte have replaced their SCG CA certificate as of 16/07/2004.  The new
> certificate is not pre-installed in Firefox 0.9.2.  This problem probably exists
> for all platforms but I have tested only the Windows version at this stage.
> 
> New Thawte CA certs can be downloaded from http://www.thawte.com/roots/
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. Go to any HTTPS server using Thawte SGC CA.

	Josh Birnbaum
	Comment 3 • 20 years ago

->mozilla.org

	Frank Hecker Assignee
	Comment 4 • 20 years ago

Note that the actual division of labor regarding CA certificates is as follows:
I approve CAs to have their certs included in Mozilla/FF/et.al., the NSS
developers (traditionally Nelson Bolyard) add the certs to the cert library
bundled with NSS, and then the Mozilla/FF/et.al. developers have to incorporate
a new version of NSS into Mozilla/FF/etc. So as soon as I figure out what's
going on here I'm going to reassign this to Nelson.

Second, I've just looked at the certificate store for my copy of Firefox 1.0 (on
OS X, though that doesn't matter), and I see the following pre-loaded Thawte
certificates (i.e., certificates for which the security device is listed as
"builtin object token"): Thawte Timestamping CA (listed under "Thawte"), Thawte
Personal Premium CA, Thawte Personal Freemail CA, and Thawte Personal Basic CA
(listed under "Thawte Consulting"), and Thawte Premium Server CA and Thawte
Server CA (listed under "Thawte Consulting cc"). The cert for Thawte SGC CA is
not present as fas as I can tell.

So, to clarify: the "bug" here is presumably *not* that Firefox 1.0 (and
Mozilla, etc.) contain an expired certificate for Thawte SGC CA, the "bug" is
rather that FF etc. don't contain a certificate for Thawte SGC CA at all, and
you think it should be added. Is this correct?

If, let's proceed to the merits of this request: It appears that the Thawte SGC
CA is not an actual root CA; rather it is an intermediate CA whose certificate
was issued by the Verisign Class 3 Public Primary CA. According to prior
discussions with Nelson and others, it should not normally be necessary to
pre-load certs for intermediate CAs, as long as the root CA certificate has been
pre-loaded for the root CA above the intermediate CA in the hierarchy. That's
the case here AFAICT, since the cert for the Verisign Class 3 Public Primary CA
is pre-loaded.

Has anyone reported any actual problems with having the Thawte SGC CA not
pre-loaded? (For example, failure to connect to certain sites?) Please provide
any evidence for why this CA's certificate needs to be pre-loaded. I'm copying
Nelson on this bug to get his opinion, and then I'm going to either assign this
bug to Nelson or resolve it as "WONTFIX"; right now I'm leaning towards the
latter. (I'm also leaving the bug as "UNCONFIRMED" because it's not clear that
there really is any problem warranting action.)

	Frank Hecker Assignee
	Comment 5 • 20 years ago

One more question for the original bug reporter: The original bug report lists
among steps to reproduce "Go to any HTTPS server using Thawte SGC CA." Can you
provide a URL for such a site? Also, have you by any chance previously imported
the Thawte SGC CA cert into your certificate store? (In other words, in your
"authorities" list of certs is it listed under "Builtin Object Token" or
"Software Security Device"? The former indicates pre-loading, the latter importing.)

	Bob
	Comment 6 • 20 years ago

(I'm not the original reporter, but I'll try to help.)
An example site is playboystore.com - you won't have to actually buy anything
swank, just add something to the cart and begin to check out.
You'll get a browser popup beginning "Unable to verify the identity of
store.playboy.com as a trusted site."
So it's not as bad as being unable to connect, it's a question of doubtful trust
(which I satisfied by googling and finding that Thawte is indeed in the CA
business.)

	Nelson Bolyard (seldom reads bugmail)
	Comment 7 • 20 years ago

Here is a URL that proves that mozilla (and FF, I believe) *CAN* connect
to a *PROPERLY CONFIGURED* https server with a thawte SGC cert.

https://www.thawte.com/core/process?retail-enrollment.enrollment-type=new-sgc2

The difference between that server, and the servers behind the URLs
https://secure3.nzpost.co.nz/  and
https://www.playboystore.com/checkout/login/checkoutmain.jsp?co=1

is that the thawte.com server is properly configured to send out its 
certificate chain; that is, to send out its own server cert *AND* to 
send out the thawte SGC intermediate CA cert, as is required by the 
SSL3 and TLS standards.  The other two do not send out the intermediate
CA certs, which directly causes the problem.  

If you visit the thawte URL above and look at the details of the certs
sent by the server, you will see that there is a "chain" of 3 certs,
including: the server's cert, the intermediate "SGC" CA cert, and the 
root CA cert, which is already in your browser.  If you visit either of
the other two URLs above and look at the cert chain details, you will
see that there is only one cert in the chain, the server's own cert.
This indicates that the server is not sending out the intermediate CA
cert, as required by the standards.  

When these servers are reconfigured to send out the required certs, 
they will find that they work with mozilla/FF, without any changes to 
mozilla/FF.

I am marking this bug as a duplicate of another bug about the same issue,
misconfigured servers, but which cited certs from a different CA.

*** This bug has been marked as a duplicate of 245609 ***

	Nelson Bolyard (seldom reads bugmail)
	Comment 8 • 20 years ago

Hmm.  Perhaps this should have been marked as a duplicate of bug 100426

I think there is also another bug that discusses the phenomenon wherein
an attempt to visit a misconfigured server fails, but then after visiting
a properly configured server whose cert comes from the same intermediate
CA, an attempt to visit the name misconfigured server succeeds, presumably
because the browser has somehow remembered (leaked?) the intermediate CA
cert in memory.  I have not been able to find that bug recently, or I
would dupe this bug against that one.