Control: affects -1 + lynx libwww-perl wget links links2 apt aptitude w3m curl
openssl dillo mpv epiphany vlc luakit surf aptitude-robot
Hi,
Rémi Denis-Courmont wrote:
> The AddTrust_External_Root.crt certificate has expired, and its
> continued inclusion in the ca-certificates set is causing GnuTLS-based
> client applications (and OpenSSL 1.0.x) to barf on a lot of sites.
Not only OpenSSL 1.0.x, also OpenSSL in unstable is affected:
------------------------------------------------------------------------
→ openssl version
OpenSSL 1.1.1g 21 Apr 2020
→ openssl s_client -connect mirror.sinavps.ch:443
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN =
AddTrust External CA Root
verify error:num=10:certificate has expired
notAfter=May 30 10:48:38 2020 GMT
verify return:1
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN =
AddTrust External CA Root
notAfter=May 30 10:48:38 2020 GMT
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN
= USERTrust RSA Certification Authority
verify error:num=10:certificate has expired
notAfter=May 30 10:48:38 2020 GMT
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN
= USERTrust RSA Certification Authority
notAfter=May 30 10:48:38 2020 GMT
verify return:1
depth=1 C = US, ST = DE, L = Wilmington, O = "Globe Hosting, Inc.", CN =
GlobeSSL DV Certification Authority 2
notAfter=Sep 9 23:59:59 2024 GMT
verify return:1
depth=0 OU = Domain Control Validated, OU = Globe Standard SSL, CN =
mirror.sinavps.ch
notAfter=Jul 16 23:59:59 2021 GMT
verify return:1
---
Certificate chain
0 s:OU = Domain Control Validated, OU = Globe Standard SSL, CN =
mirror.sinavps.ch
i:C = US, ST = DE, L = Wilmington, O = "Globe Hosting, Inc.", CN = GlobeSSL
DV Certification Authority 2
1 s:C = US, ST = DE, L = Wilmington, O = "Globe Hosting, Inc.", CN = GlobeSSL
DV Certification Authority 2
i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN =
USERTrust RSA Certification Authority
2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN =
USERTrust RSA Certification Authority
i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust
External CA Root
---
[...]
------------------------------------------------------------------------
> It could probably be argued that this is a bug in GnuTLS rather than
> ca-certificates,
The longer I think about the more I think it is a bug in both OpenSSL
and GnuTLS, because the certificate above is totally valid because the
second last CA is actually no more an Intermediate CA but in
ca-certificates, too.
But for some reason, even though the third certificate in the chain is
trusted, both, OpenSSL and GnuTLS seem to see the fourth certificate
and only seem to check if that one is trusted and not any inbetween.
Because "USERTrust RSA Certification Authority" is actually not
expired, just a certificate, which signed it (obviously as shown
above):
(on a buster system)
------------------------------------------------------------------------
$ openssl x509 -in /etc/ssl/certs/USERTrust_RSA_Certification_Authority.pem
-noout -text | egrep 'Not After|Subject:'
Not After : Jan 18 23:59:59 2038 GMT
Subject: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST
Network, CN = USERTrust RSA Certification Authority
$ openssl x509 -in /etc/ssl/certs/AddTrust_External_Root.pem -noout -text |
egrep 'Not After|Subject:'
Not After : May 30 10:48:38 2020 GMT
Subject: C = SE, O = AddTrust AB, OU = AddTrust External TTP Network,
CN = AddTrust External CA Root
------------------------------------------------------------------------
> but I don't see the point in keeping an expired certificate here.
Ack.
> The problem is confirmed to affect Epiphany and VLC.
Tons more: I ran into it with aptitude-robot (via aptitude and apt)
first and was able to confirm it in nearly all browsers and streaming
videoplayer I could think of. The only exceptions were firefox-esr,
chromium, and — to my surprise — qutebrowser.
Martin Bagge / brother wrote:
> severity: critical
> Thanks
>
> You will need to workaround this. As such this motivates critical me think.
I think "grave" is severe enough, as it "only" breaks HTTPS including
apt with HTTPS-based mirrors (as the one mentioned above) and hence
only "unrelated software/packages", not the whole system (like the
kernel or the bootloader would do if the system won't boot anymore
after an upgrade).
> just doing a straight up curl will hang until timeout. With the expired
> cert disabled this is bypassaed (without curl -k).
Nope. curl exits immediately for me, at least in unstable (7.68.0-1):
------------------------------------------------------------------------
→ time curl https://mirror.sinavps.ch
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
curl https://mirror.sinavps.ch 0.02s user 0.00s system 22% cpu 0.073 total
------------------------------------------------------------------------
Funnily curl on buster (7.64.0-4+deb10u1) seems to be not affected:
------------------------------------------------------------------------
$ curl https://mirror.sinavps.ch
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
<html xmlns="http://www.w3.org/1999/xhtml";>
[...]
------------------------------------------------------------------------
> 1. Edit /etc/ca-certificates.conf and put a bang/exclamation mark (!)
> before mozilla/AddTrust_External_Root.crt
> 2. Run update-ca-certificates
Good point. I though prefer "dpkg-reconfigure -plow ca-certificates". :-)
Martin Bagge / brother wrote:
> found 961907 20161130+nmu1+deb9u1
Ack, stretch is affected, too, at least with lynx and — funnily again
— curl (7.52.1-5+deb9u10).
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
