GlobalSign SSL Certificates Treated as Invalid

I want to add that the roots in question are available here:-

Current Root embedded in FF3RC2
http://secure.globalsign.net/cacert/Root.crt

Proposed Root to be embedded (Same key material)
http://secure.globalsign.net/cacert/Root-R1.crt

thanks.

Additional testing and discussion with Nelson Bolyard shows that I need to rename the title of the bug to "inconsitency in certificate root import method."
and down grade severity.

It still needs fixing to improve the user experience.

i.e.

import a root by the front door (Directly) and the GUI presented to the user asked for trust bits to be set.

import a root by the back door and the trust bits are all set to off (even if it's an e-mail cert being imported). Firefox should ask the user to set the trust bits for the new root.

I confirm that this is an enhancement request. :)

I would summarize this RFE as follows:

When importing a "user" cert (a cert for which the private is locally held)
and its associated cert chain, if the chain includes a root CA certificate,
that is not already known to the product, offer to let the user edit the
trust on the imported root. (but that's too long for the bug summary field. :)

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

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.

Created an attachment (id=412608)
Globalsign Store after Deleting the Root Authorities (again)

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.

Yes, this absolutely ought to be implemented. See the now-resolved Bug 527029 for a good use case.

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.

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?

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.

Created an attachment (id=414480)
Documented ways to get cPanel to fail on initial SSL connection to port 2096

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.

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.