Arch Linux

I can confirm this issue with the Website https://ssltest.makeplans.no/

Definitely a nss issue; downgrading to nss-3.13.1-2 makes that site work again.

Reassigning to the nss package maintainers.

This is not a bug in nss, as it works fine in firefox. The only differences between nss 3.12.2 and nss 3.12.3 is that the last version now has the possibility to add explicit distrusted certificates to the certification store. In 3.12.3, they have added 2 distrust certificates for Trustwave.

As for the missing EssentialSSL CA: This is not a CA, but an intermediate certificate. Browsers shouldn't include that, but instead, servers should provide it when sending the certificates.

Thanks for the information Jan.

It baffles me that Chromium works with nss 3.13.1 though. :\

I guess Firefox doesn't heavily rely on NSS as they use their own version of certificate manager.
Perhaps there's something up with the upstream of NSS but anyhow I've contacted Comodo and let's see what do they have to say!

And I can confirm too that downgrading nss fixes the issue -- no more untrusted certificate warnings there.

Conversation between me and Comodo:

> As you can see in the Arch package details, the libnss is directly being
> compiled from the upstreams of Mozilla.
>
> Arch didn't mark it as a bug.
>
>
> As soon as you'll upgrade to nss 3.13, you're doomed.
>

We're unable to replicate this on Ubuntu 12.04 beta 1 (libnss 3.13.1); fresh install. It seems you have a local issue of which we're not able to provide support for.

>
> Your response is kind of unresponsive!!
>
>
> (At least you should investigate why the latest nss marks EssentialSSL as
> untrusted)!
Unfortunately that's outside the scope of this service.

well, you failed to report the correct nss version. 3.13 != 3.13.1 != 3.13.3

we have 3.13.3

Ionut, I did them in an earlier reply. The above conversation included the last correspondence ! :P

After further pushing it, they finally got it.

"We were able to get ArchLinux in a VM and we're able to reproduce this using NSS 3.13.3-1 as reported in the Arch ticket [ https://bugs.archlinux.org/task/28860 ], we were also able to reproduce using Fedora 16, which recently (Saturday)[ http://lists.fedoraproject.org/pipermail/package-announce/2012-March/075636.html ] upgraded to 3.13.3-1 and it too exhibited the same problem.
As a result of this testing, we escalated to our Senior R & D team for further investigation. As a result of their investigation, we will be filing bug with Mozilla in the coming days. It seems there is a bug upstream that will need to be patched by Mozilla as the problem exists in multiple distros and even affects Windows & Linux using 'NSS_ENABLE_PKIX_VERIFY=1' set inside the environment, starting with Firefox 11, which is using NSS 3.13.3 as well. This is not something that is on by default, but will be within the next 3-6 months --Comodo Support"

Ok guys.
This seems to have been fixed in 3.13.4
(https://bugzilla.mozilla.org/show_bug.cgi?id=737802)

Thank you for the thorough investigation bassu. And kudos to Comodo for looking into it as well.

Let's see if we can fix our nss package.

I tried both patches to nss from that bug report but neither fixed the issue. :\

With nss 3.13.4 (released on April 6th), I can open [1] with Chromium.

Shall we consider this bug solved once nss 3.13.4 gets into [extra]?

[1] https://www.dominos.co.uk/customer/addDetails.aspx

The likelihood is yes. I'll test as soon as its released.
Thanks.