309053 - Addons.mozilla.org returns bad TLSv1 certificates

Status: RESOLVED WORKSFORME

(mozilla.org Graveyard :: Server Operations, task)

Description

[S Egbert]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050726 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050726 Firefox/1.0.6

Addons.mozilla.org returned bad TLSv1  SSL certificates.


Reproducible: Always

Steps to Reproduce:
1. Turn on OCSP (either two options)
2. Tools->Extensions (new Extension window box)
3. Mouse click on the "Get More Extensions" hyperlink
4. New Browswer window appears
5. New popup dialog box reporting "Error establishing encrypted connection to
addons.mozilla.org -8075"


Actual Results:  
The new popup dialog box reporting the OCSP error is correct.
The new browswer windows is blank (correct behavior for bad certificate)

This is an issue with either my new firewall (unlikely) or the
HTTPS://addons.mozilla.org/ OCSP responder.


Expected Results:  
Provide a better error message in the popup dialog box, other than -8073.

I've enclosed the PCAP files.

Comment 1

[S Egbert]

Attachment: PCAP (Packet Capture) file for use with Ethereal application

Shows a failed TLSv1 SSL connection attempts with https://addons.mozilla.org/
with OCSP verfication option turned on in the
Firefox->Preferences->Advanced->OCSP

Comment 2

[Josh Birnbaum]

Error number -8075 means "The location for the certificate status server has
invalid format."  Needing better message is a PSM issue, bug 107491.

Does OCSP work for you at all?

Comment 3

[S Egbert]

At this point, the focus was limited to https://addons.mozilla.org/ that OCSP
does not work.

For OCSP validation by internal Token (3rd option), the following websites does
not work (same as this bug report)

   https://www.western.org/
   https://mail.yahoo.com/

Same for OCSP validation by certificate's responder URL.

Don't forget to change back the OCSP preference to not-validated when working
with this bugzilla.


I'm beginning to think that my NAT-firewall is the culprit.  Does OCSP uses
client's internal NAT'd IP address?

Comment 4

[S Egbert]

WHOA!   GLobalsign CRL responder's certificate has expired....

http://www.openvalidation.org/en/service/calist.html?intnumber=56&serial=-1

Mozilla.Org (or XRamp Security Services) would need to get another certificate
in order for Mozilla.org to continue in a secured fashion.

This impacts not only 

   https://addons.mozilla.org

but

   https://bugzilla.mozilla.org

and presumably all other third level domain names as well within MS.

Comment 5

[S Egbert]

> and presumably all other third level domain names as well within MS.
> 

MZ.... MZ... MZ.... (freudian slip here...)... MZ... (not MS).

Comment 6

[Dave Miller [:justdave]]

Any ideas, Scott?

Comment 7

[Dave Miller [:justdave]]

From XRamp:

-----

All the CRLs in our chain are working properly and are valid.

See:
http://crl.xrampsecurity.com/XRampGSCA.crl  <-- CRL for your cert	
http://crl.globalsign.net/RootSignPartners.crl  <-- CRL for GSCA root
above
http://crl.globalsign.net/Root.crl  <-- CRL for the RSPartners root
above

I'm not really sure which roots the OpenValidation website is testing -
it looks like they do not have an updated list.

As far as OCSP goes, we do not currently have it implemented as right
now at the implementation is currently very problematic.  I actually had
a conversation with one of the top scientist guys at VeriSign(Phillip
Hallam-Baker) last week where we discussed current problems with OCSP.
We both agree that the in the future OCSP will become important, but as
it stands right now, it is so clunky that it causes more problems than
it fixes. 

I don't think the CRL thing is an issue, as I just double checked all
the CRLs and they seem to be working just fine...  And as to the way to
fix the OCSP problem - simply turn it off until we (the CA industry
"we") get it working better.  

Something else - since almost none of the CAs put the OCSP OID in their
certs (I think VeriSign is the only one who does right now), when you
turn on OCSP, it should only try to use OCSP with certificates that have
the OID in them for it.  Our certs do not currently have the OID
necessary for OCSP - it should not check OCSP, but since we DO use CRLs,
it should check the CRL instead.  If a certificate doesn't have the OID
for OCSP it shouldn't fail, it should just let the user know that there
is not an OCSP server to validate it.  

------

Comment 8

[Scott Harris]

Hehe - Thanks for saving me this step, and posting in my email, Dave!

I was just adding to this when I saw your email come in.

Please let me know if there are any other questions.