Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#28860 - [chromium] missing Comodo's Essential SSL's CA since last update

Attached to Project: Arch Linux
Opened by bassu (bassu) - Sunday, 11 March 2012, 06:48 GMT
Last edited by Jan de Groot (JGC) - Monday, 16 April 2012, 12:09 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Evangelos Foutras (foutrelis)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Chromium missing Comodo's CN "Essential SSL" since update to chromium-17.0.963.79-1-x86_64.

Additional info:
* chromium-17.0.963.79-1-x86_64
* nss 3.13.3-1

Could possibly originate from the nss; but the certutil and Chromium's SSL Manager report the said CA missing

Steps to reproduce:
Go to Chromium > Preferences > Under the hood > Manager certificates > Authorities > "Essential SSL" doesn't exist there; while Firefox has it.
This task depends upon

Closed by  Jan de Groot (JGC)
Monday, 16 April 2012, 12:09 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 3.13.4-1.
Comment by Kai Hendry (hendry) - Sunday, 11 March 2012, 10:44 GMT
I can confirm this issue with the Website
Comment by Evangelos Foutras (foutrelis) - Sunday, 11 March 2012, 11:57 GMT
Definitely a nss issue; downgrading to nss-3.13.1-2 makes that site work again.

Reassigning to the nss package maintainers.
Comment by Jan de Groot (JGC) - Sunday, 11 March 2012, 14:12 GMT
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.
Comment by Evangelos Foutras (foutrelis) - Sunday, 11 March 2012, 14:22 GMT
Thanks for the information Jan.

It baffles me that Chromium works with nss 3.13.1 though. :\
Comment by bassu (bassu) - Monday, 12 March 2012, 01:47 GMT
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!
Comment by bassu (bassu) - Monday, 12 March 2012, 01:54 GMT
And I can confirm too that downgrading nss fixes the issue -- no more untrusted certificate warnings there.
Comment by bassu (bassu) - Friday, 16 March 2012, 07:19 GMT
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.
Comment by Ionut Biru (wonder) - Friday, 16 March 2012, 07:32 GMT
well, you failed to report the correct nss version. 3.13 != 3.13.1 != 3.13.3

we have 3.13.3
Comment by bassu (bassu) - Friday, 16 March 2012, 16:05 GMT
Ionut, I did them in an earlier reply. The above conversation included the last correspondence ! :P
Comment by bassu (bassu) - Wednesday, 21 March 2012, 05:49 GMT
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 [ ], we were also able to reproduce using Fedora 16, which recently (Saturday)[ ] 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"
Comment by bassu (bassu) - Wednesday, 28 March 2012, 15:52 GMT
Ok guys.
This seems to have been fixed in 3.13.4
Comment by Evangelos Foutras (foutrelis) - Wednesday, 28 March 2012, 20:00 GMT
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.
Comment by Evangelos Foutras (foutrelis) - Friday, 06 April 2012, 06:36 GMT
I tried both patches to nss from that bug report but neither fixed the issue. :\
Comment by Evangelos Foutras (foutrelis) - Friday, 13 April 2012, 20:00 GMT
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]?

Comment by bassu (bassu) - Friday, 13 April 2012, 20:05 GMT
The likelihood is yes. I'll test as soon as its released.