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