Problems with https

dpx · 2021-03-28 10:48:31

Hi, after updating few days ago I have problems connecting to several Portuguese sites trough https, one of the examples being https://webapps.iapmei.pt/
This happens with both firefox and chromium, so I am guessing it has something to do with certificates on OS level.
Firefox says "Did not connect: potential security issue", chromium says "Your connection is not private".

All the sites that report problems with firefox or chromium work well on adroid tablet, on the same network, so their certificates should be valid.

How can I fix this? Thanks.

progandy · 2021-03-28 10:52:25

It might be that multicert is currently untrusted by mozilla: (I have no idea what google / your vendor is using as the trust source for android. Maybe an old version of the mozilla trust that still has that ca?)

That may be a result of the repeated compliance issues:
https://wiki.mozilla.org/CA:Camerfirma_Issues
https://groups.google.com/g/mozilla.dev … UwcFioAQAJ

Alternativeley it may be that there is a bug in nss.

Last edited by progandy (2021-03-28 11:18:15)

dpx · 2021-03-28 11:22:20

Thanks progandy, so it seems we need to wait? Portugal seems to have heavy use of Windows so they don't care about mozilla, android tablet is samsung/google and whatever source of truth they use. Only thing I am not sure about is why is chromium on arch affected by this, does it use mozilla certificates too?

progandy · 2021-03-28 12:01:47

Both firefox and chromium use the system trust store, which is based on the mozilla trust collection on arch and most linux distributions.
The camerfirma certificate is still part of the trust database, I have not found the reason why it is not exported for the ssl trust file. I guess there is a blocklist somewhere I have not found yet.

By the way, with the release of Chrome 90, Google will distrust Camerfirma on all platforms.
https://groups.google.com/g/mozilla.dev … UwcFioAQAJ

dpx · 2021-03-28 12:09:24

progandy wrote:

By the way, with the release of Chrome 90, Google will distrust Camerfirma on all platforms.
https://groups.google.com/g/mozilla.dev … UwcFioAQAJ

That will be fun, half of Portuguese official government/company sites are using this same type of certificate. I even hit same certificate error trying to buy bus ticket this morning on rede-expressos.pt (main site works but checkout uses faulty certificate). Thanks for the info.

archdub · 2021-03-31 22:34:26

I was also bitten by this, accessing Portuguese websites. I could get to a site without errors on Windows, Fedora 33, Xubuntu 20.04 (Firefox 87) but not Arch (Firefox 87 or Chromium). Firefox ESR from AUR works fine too.

If this is a bug, what package are we talking about? Because it affects both Firefox and Chromium it must be in another package.

Last edited by archdub (2021-03-31 23:03:43)

progandy · 2021-03-31 22:59:52

It might be a bug, possible in nss. I do not understand exactly how nss would determine certificate validity. The certificate is still part of the trust store, but for some reason I cannot understand it is not found by nss / firefox / ... during verification. Maybe it doesn't like the purpose "SSL server : No | SSL server CA : Yes | Any Purpose : Yes | Any Purpose CA : Yes", of the "Global Chambersign Root - 2008", but that is just wild guessing. It could also be that it was marked as not to be trusted somewhere, but I have no idea where.

Edit: It is also not part of the output of

trust extract --comment --format=pem-bundle --filter=ca-anchors --purpose=server-auth

Last edited by progandy (2021-03-31 23:11:52)

loqs · 2021-03-31 23:28:47

~~Global Chambersign Root - 2008 was revoked by Mozilla https://bugs.archlinux.org/task/70095~~

Edit:
Not the same issue see post #12

Last edited by loqs (2021-04-01 01:23:42)

archdub · 2021-03-31 23:34:09

Thanks.

I reported the issue.

https://bugs.archlinux.org/task/70251

Stunts · 2021-03-31 23:42:09

I've also been bitten by this. I can confirm that none of my Arch Linux based machines can connect to a lot of Portuguese websites (those signed by MULTICERT), with neither Firefox, nor Chrome, nor Epiphany but Ubuntu will work, as well as firefox on Android.
Are there any known workarounds?

archdub · 2021-03-31 23:52:28

According to comments by loqs in this other issue ...
https://bugs.archlinux.org/task/70095

... there is a workaround (for that problem) by downgrading ca-certificates-mozilla and doing a few other things. I have not tried it for this Firefox issue so no idea if it works.

loqs · 2021-03-31 23:55:01

progandy you were after right reverting:
https://github.com/nss-dev/nss/commit/9 … 64b6bd84d4 Bug 1692094 - Set email distrust after to 21-03-01 for Camerfirma's Chambers of Commerce' and 'Global Chambersign' roots. r=KathleenWilson
https://github.com/nss-dev/nss/commit/c … 742296360e Bug 1692094 - Turn off Websites Trust Bit for 'Chambers of Commerce Root - 2008' and 'Global Chambersign Root - 2008'. r=KathleenWilson

site is allowed again
Edit:
Only second commit needs to be reverted.

Upstream bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1692094

Last edited by loqs (2021-04-01 00:16:10)

eschwartz · 2021-04-01 00:58:08

Certificate Authority blacklisting is not an accident. However, there are additional details here.

Google (chromium) stated their intent to give sites using this CA an extension:

https://groups.google.com/g/mozilla.dev … Zi2p48BwAJ
https://bugs.chromium.org/p/chromium/is … id=1194656

As with any CA removal, we’ve continued to examine ecosystem progress. When appropriate, we've also reached out to specific organizations to understand any challenges that might significantly impact our users. While we actively discourage CAs and site operators from directly contacting us to request exceptions, we do reach out to organizations that may significantly affect a non-trivial number of users. This situation is particularly unique due to the global pandemic, as several Portugese and Spanish government websites related to COVID-19 are affected.
We've received confirmation from these organizations that they are on track to migrate. These organizations have requested 1-2 additional weeks to replace their certificates, beyond the three months since the original announcement. Normally, we would not honor such requests, given the industry standard expectations around certificate replacement being doable in five days or less. However, the global pandemic has brought unique and unprecedented challenges. Given the importance of these websites in helping resolve this global health crisis, we’re inclined to provide that additional migration support under these circumstances.

archdub · 2021-04-01 01:36:41

As a workaround, this AUR package works well for me:

https://aur.archlinux.org/packages/firefox-esr-bin/

dpx · 2021-04-02 09:46:09

I can confirm firefox-esr-bin working as a temporary workaround.

Arch Linux

#1 2021-03-28 10:48:31

Problems with https

#2 2021-03-28 10:52:25

Re: Problems with https

#3 2021-03-28 11:22:20

Re: Problems with https

#4 2021-03-28 12:01:47

Re: Problems with https

#5 2021-03-28 12:09:24

Re: Problems with https

#6 2021-03-31 22:34:26

Re: Problems with https

#7 2021-03-31 22:59:52

Re: Problems with https

#8 2021-03-31 23:28:47

Re: Problems with https

#9 2021-03-31 23:34:09

Re: Problems with https

#10 2021-03-31 23:42:09

Re: Problems with https

#11 2021-03-31 23:52:28

Re: Problems with https

#12 2021-03-31 23:55:01

Re: Problems with https

#13 2021-04-01 00:58:08

Re: Problems with https

#14 2021-04-01 01:36:41

Re: Problems with https

#15 2021-04-02 09:46:09

Re: Problems with https

Board footer