Closed Bug 527029 Opened 15 years ago Closed 15 years ago

GlobalSign SSL Certs Treated as Invalid

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Version:
3.5 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: ron, Unassigned)

References

(
URL
)

Details

Attachments

(2 files)

Globalsign Store after Deleting the Root Authorities (again)
22.88 KB, image/png
Details
Documented ways to get cPanel to fail on initial SSL connection to port 2096
953.81 KB, application/pdf
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4

Any site with a valid SSL certificate from GlobalSign is treated as invalid by Firefox 3.5. This is a regression; I can confirm it working correctly in 3.0 versions.

To replicate, go to https://globalsign.com and observe the warning. I have tried manually importing the GlobalSign certs, but even after removing the built-in object tokens from the authorities list, I get warnings that GlobalSign already exists. Upon restart of Firefox, the authorities appear correctly.

This happens on new installs. It is worth noting that this happens in the Windows version too.

I am marking this a sec vulnerability, as not being certain on the validity of GlobalSign certified sites opens a potential MITM risk.

This is almost certainly related to Bug 474606. This same bug is filed downstream against Ubuntu's Firefox 3.5 package at https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/476683.

Following is the Launchpad debug information:
ProblemType: Bug
Architecture: amd64
Date: Fri Nov 6 12:00:46 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
NonfreeKernelModules: nvidia
Package: firefox-3.5 3.5.4+nobinonly-0ubuntu0.9.10.1
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: firefox-3.5
Uname: Linux 2.6.31-14-generic x86_64

Reproducible: Always

Steps to Reproduce:
1. Go to any GlobalSign certified site (e.g. https://globalsign.com)
2. Observe the warning, and that the certificate information is correct
Version: unspecified → 3.5 Branch
Are you using Ubuntu-produced builds or Mozilla-produced builds? If you're using Ubuntu builds then the ubuntu bug covers it and they'll talk to us if they need to.

I don't see any problems myself at globalsign's site, but I'm running Mozilla-produced x86 builds. Could be a "system NSS" problem, or a 64-bit thing.

https://globalsign.com uses an EV cert. Do you have the problem on sites with non-EV globalsign certs?

What error are you getting (in the "technical details" section of the error page)?
I didn't see a problem on windows, either. I didn't install again, but I did create a new profile which should have done the equivalent (e.g. I'll get fresh copies of the crypto database files).
I don't see why this would be related to Bug 474606 -- in that one the cert was perfectly valid and there were no errors. We just didn't give it the full "EV Green" treatment due to failure to get revocation information.
Ubuntu-produced, but I could replicate this on Windows using Mozilla-produced builds... but, now I can't! I don't know what changed, except perhaps a FF auto-update. Regardless, perhaps this is a build-specific issue. I will see if downstream can repro it. If not, then I've done something or other to my whatchacallit...
Sorry, meant to include:

globalsign.com uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is not trusted.

(Error code: sec_error_untrusted_issuer)

Also, globalsign nv-sa exhibits the same behavior, such as when visiting https://cosmos.constellationmedia.com
I can reproduce this with 64-bit Mozilla builds of Firefox on Windows 7 and Vista. Can anyone repro it? Could this be an NSS issue?
WFM. Copying Steve, from Globalsign, so see if he can lend insight.
I talked with the engineering team in Japan this morning and they are going to build a test environment to simulate the issue.    I want to have a 2nd test bed local to me so I've purchased an Intel x64 machine for testing in EMEA.  I would suspect we can get some preliminary results by the end of the week and I can try to simulate over the weekend and into early next week.   

A shot in the dark is that GlobalSign has two roots with the same key material.  One that expires in 2014 which was originally embedded in Fox.  The second which was created more recently and is in current builds is embedded into the latest fox.    In general the roots are seen as the same thing so no problem.

Ron, can you test these sites and give me the results?

https://2014.globalsign.com   Legacy version in early Fox
https://2028.globalsign.com   Current version in latest Fox
https://2021.globalsign.com   Different root (Sanity check) only in latest

Of the failing websites in the post.  https://cosmos.constellationmedia.com delivers the 2028 root and www.globalsign.com delivers the 2014 root in the response, so this could be a dead end test.

Thanks everyone.
I'm going to test from a variety of environments available to me to see if we can track this down, including testing with another browser (Chrome for Linux and Windows) just to isolate the problem as much as possible. To begin, I have tested this with a 32-bit XP box using FF and Chrome; all sites checked fine.

All 3 failed to validate in both FF and Chrome in 64-bit Linux (Ubuntu). However, they worked just fine in both browser in 64-bit Win 7 on the same machine at the same location. Clearly, this is not a FF bug, but if Steve or anyone else can lend some insight into the matter, I'd be most interested.

I haven't done anything out of the ordinary on either machine that would affect SSL validation (at least, nothing comes to mind). I'd be happy to assist in this issue however possible, especially if this needs to be pointed at a different project/bug tracker/support area/etc.

I will notify the downstream tracker, where I have filed a bug against Ubuntu's 64-bit FF build. When I have a little more time, I'll try a Moz build on the same OS and see what happens. In the meantime, I'm eager for insight into this perplexing problem.
Incidentally, only the 2014 page got a green bar indicator in Win 7; is that expected behavior, or is that what Bug 474606 is actually about?
Hi Ron, Yes 2014 does not have the EV OID in the cert so this will not bring out the additional features of EV on that site.  474606 was to do with OCSP which is in place hence why 2021 correctly turns on the green bar.

We'll also look more deeply at 64 bit Linux now.  thanks.
Steve: take a look at https://cosmos.constellationmedia.com, which uses globalsign nv-sa. It shows as invalid for me.
I get this when visiting https://apac.globalsign.com/repository/:
Technical Details
apac.globalsign.com uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is not trusted.
(Error code: sec_error_untrusted_issuer)

Something odd is happening here. I expect this is the fault of Ubuntu's 64-bit build of firefox (or NSS?), but I need triaging from someone else with 64-bit Ubuntu.
Ron,

There's something odd with your set-up and we've not been able to replicate thus far.   Once we can get a second confirmation that would help, but at the moment all our tests show that it's OK.

The ONLY 'other' thing that I can assume is that you may have accepted a cert into the root store via a mail or something else and 'poisoned' your store not to allow SSL to work.   Please can you send us a screen shot of your root store and cert usage for our roots?  (It still doesn't answer why the 2021 fails)   I'll get my 64bit machine up and running only at the end of the week as I'm travelling for 3 days.

Thanks.
Steve: it appears you nailed it. I looked in my store and noted that now the only Globalsign Authorities were "Software Security Device" entries. I deleted them, restarted FF, and went to https://globalsign.com, which now showed as valid. My store now looks like the .png attachment, and all sites seem to work fine.

I'm curious as to what caused this, but it does appear to be a user-specific issue. For now, though, this bug could probably be marked "invalid", unless Steve turns up something of general interest or application in his tests later in the week.
I had done this before I thought, but I noticed the only Globalsign objects in my root authorities list were SSDs. I deleted them and upon restart FF added the root authorities seemingly correctly.
Ron,

This bug would have solved your issue....but it's a small priority 'feature' request at the moment.

https://bugzilla.mozilla.org/show_bug.cgi?id=437608

If you can close that would be great.
Steve: sure enough, that would be handy :). I've added myself to the watch list on that bug and will close this one. Thanks for your help.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Re-Opening this bug. I can replicate it again on a Win32 Mozilla Build 3.5.5. GlobalSign NV-SA is in the cert store as a token, expiry 2028. If you need a shot of that, let me know.

I replicate this on https://cosmos.constellationmedia.com:2096. This cert ought to cover this, unless I'm missing something. Any ideas Steve? Port 80 works fine, as does https://2028.globalsign.com/

Is this a misunderstanding on my part of the SSL Cert coverage? It seems sometimes the cert will cover all ports, sometimes not. Does it require a wildcard?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
As an additional note, I get "unknown issuer" not "invalid hostname" as the error message.
Ron,  This would appear to be a cPanel issue so I'll raise a bug on them.   The basic issue is the delivery of the intermediate issuing CA from the cPanel web server on port 2096.   It doesn't send it, so on first load you have an incomplete chain.  If you happen to go the port 443 your browser will use AIA to grab the issuing CA or it will be correctly delivered by cPanel and you'll have fixed your issue.  I've detailed my findings in the attached PDF.   2028.globalsign.com is from a different issuing CA so that will not clear the issue for you.  I hope that's clear.   In part it explains why it was hard to replicate when the original bug was created.
Ron,  Can you do me a favour (I assume you own the cPanel licence?)  Can you raise a bug for me.  cPanel don't accept bugs from non cPanel users.  (not that I can see).   My attachment shoudl be fine.  Let me know the bug number and I should be able, I hope, to contribute.
(In reply to comment #21)
> Ron,  This would appear to be a cPanel issue so I'll raise a bug on them.   The
> basic issue is the delivery of the intermediate issuing CA from the cPanel web
> server on port 2096.   It doesn't send it, so on first load you have an
> incomplete chain.  If you happen to go the port 443 your browser will use AIA
> to grab the issuing CA or it will be correctly delivered by cPanel and you'll
> have fixed your issue.  I've detailed my findings in the attached PDF.  
> 2028.globalsign.com is from a different issuing CA so that will not clear the
> issue for you.  I hope that's clear.   In part it explains why it was hard to
> replicate when the original bug was created.

Steve, Ron - if this is a globalsign/cpanel issue, would you agree that we can close the Firefox bug?
I'm happy to close from my end, with one final comment.  From my initial tests it seems that IE does not suffer the same fate as it does use the AIA to grab the issuing CA details, where as opera and firefox doesn't seem to want to do that.  maybe it should be a feature in a future release of Firefox noting that the MS implimentaion is not strictly RFC compliant. - just a thought.
(In reply to comment #25)
> I'm happy to close from my end, with one final comment.  From my initial tests
> it seems that IE does not suffer the same fate as it does use the AIA to grab
> the issuing CA details, where as opera and firefox doesn't seem to want to do
> that.  maybe it should be a feature in a future release of Firefox noting that
> the MS implimentaion is not strictly RFC compliant. - just a thought.

Sounds like you want to copy yourself on bug 399324!  :)  RESO->INVALID because it's not a Firefox bug.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → INVALID
Steve:
I confirm your findings. Thanks for tracking this down so well! I am attempting to file a bug in CPanel, but I'm not the originator of my license, my data center is. We'll see how far I can get.

Sorry for the invalid bug; this is a tricky one. I'll pursue this against CPanel. Thanks all.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: