Jim Jeffery not reading bug-mail 1/2/11 Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre Firefox/3.0

Try to go to URL, and you get a warning page:

Secure Connection Failed

      

      
      
      

      
        
        

          

An error occurred during a connection to www.biglumber.com:443 because it uses an invalid security certificate.
The certificate is not trusted or its issuer certificate is invalid.
 (sec_error_unknown_issuer)

        


        
        


    *   The page you are trying to view can not be shown because the authenticity of the received data could not be verified.

    *   Please contact the web site owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.




      


      
      

Reproducible: Always

Steps to Reproduce:
1. Go to URL 
2. Receive error page.
3.
Actual Results:  
Blocked

Expected Results:  
Page should load. 



Snip from convo on IRC with bz
bz_sleep>	maybe we don't have "Go Daddy" in our CA database?
	<bz_sleep>	and IE does?
	<bz_sleep>	ah
	<ssieb_roam>	and what about all the self-signed certs?
	<bz_sleep>	I see
	<bz_sleep>	ssieb_roam: the claim (true, fwiw) is that they are equivalent to no cert at all
	<bz_sleep>	ssieb_roam: from a security perspective
	<ssieb_roam>	other than the connection is encrypted
	<bz_sleep>	true
	<ssieb_roam>	which is generally the whole point
	<bz_sleep>	people seem to not care or something
	* bz_sleep	sort of gave up on trying to talk sense into the ssl cartel
	<bz>	in any case, last I checeked IE7 dropped those too
	<bz>	Littlemutt_afk: actually, hold
	<Littlemutt_afk>	ok
	=-=	YOU are now known as Littlemutt
	[INFO]	You are no longer marked as away.
	<bz>	Littlemutt_afk: it looks like that CA has been added to NSS...
	<bz>	er..
	<bz>	except that was in 2005
	<ssieb_roam>	wow, that is going to cause a lot of trouble...
	<bz>	so yeah
	<bz>	file, please
	<bz>	that should be working
	<bz>	but isn't
	<bz>	and it's not in my CA store
	<bz>	and should be
	<Littlemutt>	ok
	<bz>	ssieb_roam: yes, yes it will
	<bz>	wait
	<bz>	so....
	<bz>	we do have Go Daddy in our stuff
	<bz>	one sec...
	<bz>	uh
	<bz>	this cert on biglumber.com doesn't seem to have a trust chain?
	* bz	double-checks
	<bz>	yeah
	<bz>	no trust chain
	<bz>	so we don't accept it
	<bz>	Littlemutt: still file the bug
	<Littlemutt>	k
	<bz>	Littlemutt: I'm not sure why it works in IE, but I seem to recall something like this
	<bz>	Littlemutt: either we need to have better compat, or do evang, or something
	<

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre Firefox/3.0 ID:2007100804

	Simon Bünzli
	Comment 1 • 17 years ago

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914

Confirming. Interestingly this is no issue when visiting https://www.godaddy.com/ first - before there's no trust chain, afterwards there is.

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 17 years ago

Over to the right place.

Oh, and it would be nice if the error message here were useful or something.  I have a hard time believing NSS doesn't report the exact failure cause.

	Nelson Bolyard (seldom reads bugmail)
	Comment 3 • 17 years ago

This is a misconfigured server, not compliant with the relevant internet
standards.  This server is sending out an incomplete certificate chain.

This is not a regression.  Mozilla products have always required a complete
cert chain, leading up to (not necessarily including) a trusted root CA cert.

	Jesse Ruderman
	Comment 4 • 17 years ago

It's strange that it works if you've visited https://www.godaddy.com/ first.  I bet that behavior confuses web developers and makes them think their site works when it really doesn't.  Should we make it fail in that case too?

	Kai Engert (:KaiE:)
	Comment 5 • 17 years ago

(In reply to comment #4)
> It's strange that it works if you've visited https://www.godaddy.com/ first.  I
> bet that behavior confuses web developers and makes them think their site works
> when it really doesn't.  Should we make it fail in that case too?

Your proposal seems reasonable.

I think it works, because we are caching the intermediate certificate somewhere.
But I wonder, WHERE are we caching it?

Does NSS keep an in-memory-only cache of intermediate certs it sees?

Or is it more likely the cert is referenced by PSM and therefore still available in the in-memory-only db (temp db)?

	Nelson Bolyard (seldom reads bugmail)
	Comment 6 • 17 years ago

The fact that PSM sometimes remembers CA certs for the lifetime of a FireFox
process is the subject of Bug 298467.  Perhaps that bug should be reopened.

Note that, AFAIK, this no longer occurs in SeaMonkey.  That makes me suspect
a leak that is actually not in PSM, but in the application code somewhere.

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

Actually, bug 298467 is about leaked Server certs, not leaked CA certs.
I made that same mistake before (see bug 298467 comment 3).  Sorry.

So, let's file a NEW bug about the fact that PSM seems to remember CA 
certs for the process lifetime (which may be a reference leak) in FireFox.

One way this can happen (apparently leaked references to in-memory certs)
is explained in bug 298467 comment 2.  

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

I filed Bug 399045 about the apparent cert reference leak that causes 
intermediate CA certs to be remembered for the lifetime of a FireFox process.

	Boris Zbarsky [:bzbarsky]
	Comment 9 • 17 years ago

The fact of the matter is, IE can load this site.  We can't.  We used to give a dialog but then allow the user to proceed, but now the user is just screwed.

If you think the only possible solution here is to fix the server, then this bug needs to be moved to evangelism, and someone responsible for this change who can explain the problem clearly to the site needs to contact them.  Just marking the bug invalid is NOT the way to go here.

	Nelson Bolyard (seldom reads bugmail)
	Comment 10 • 17 years ago

Boris, we've been invalidating bugs for misconfigured servers for years.
It's really the job of their CA to educate its paying customers on how to
properly install their certs.  After all, that's part of the service for
which they're paying their CAs.  Do you really want Mozilla to take over 
customer support for those CAs for free?

	Boris Zbarsky [:bzbarsky]
	Comment 11 • 17 years ago

I guess I care more about not breaking things for our users than I do about assigning blame...

	bugzilla.mozilla.org
	Comment 12 • 17 years ago

The visitor does not care about an invalid server configuration. He wants to see the content of the page. In Firefox 2 I get a warning and can choose to visit the page anyway or not.

but with Firefox 3 I have no chance at all to get to that page - this is not acceptable. 

	Oleg Romashin (:romaxa)
	Comment 13 • 17 years ago

Current implementation of nsNSSBadCertHandler does not allow to ignore certificate errors and see page anyway...

http://mxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsNSSIOLayer.cpp#2463-2500

Just allow to see problems in alert or in error page, but does not allow Ignore it...

I guess it should be possible to setup full ignoring of certificate problem in NotifyCertProblem  - interface and return SECSuccess if NotifyCertProblem handler wants to do it.

	Mike Taylor [:miketaylr]
	Comment 14 • 11 years ago

Site no longer exists. Closing as INVALID.