Hi Tobias, thank you for your clear explanation and patience ...and sorry again to all other Guix users for the "noise": this is not strictly related to Guix but just to the most recent version of curl/wget I still I don't understand the differences between curl (and wget) behaviour and the last Guix available ungoogled-chromium (see below). Tobias Geerinckx-Rice writes: > Giovanni Biscuolo 写道: >> Jack Hill writes: >>> The error wget gives is a little bit better, > > FWIW, I use this (extremely verbose) command to debug/check my own > servers: > > $ openssl s_client -showcerts -servername > voices.transparency.org \ > -connect voices.transparency.org:443 With this output I'm able to understand what's going on with this certificate, thanks! This command clearly shows the depth of this certificate is 3 and that the top level cert is expired: --8<---------------cut here---------------start------------->8--- 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 --8<---------------cut here---------------end--------------->8--- I guess that this information, client side, is the same for all browsers and CLI interfaces (like curl) since long ago: right? [...] > They're also sending intermediate certificates that they shouldn't > be sending in the first place[0] which doesn't help matters. I > agree that this looks like an outdated server (mis)configuration. OK but I really don't understand why with a recent browser from Guix - ungoogled-chromium 81.0.4044.138 - the certificate is detected as valid: the top root certificate shown in it's graphical "Certificate viewer" interface is "USERTrust". It seems that ungoogled-chromium stops the verification at the level=1 certificate: --8<---------------cut here---------------start------------->8--- 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority --8<---------------cut here---------------end--------------->8--- >> Yes. All modern clients and operating systems have the newer, >> modern >> COMODO and USERTrust roots which don’t expire until 2038. > > Right, but ‘modern’ there means ~2015. I don't fully understand what this means, sorry... but it's not important :-) > [0]: > https://www.ssllabs.com/ssltest/analyze.html?d=voices.transparency.org&s=52.4.38.70&hideResults=on I had a look at three random IP addresses from the list of checked ones (all grade B): they give three certification paths and path #3 is expired. Nonetheless, I still do not understand why ungoogled-chromium is behaving diffrerently than the most recent curl/wget A similar thing is happening when trying to fetch content (for elfeed) using curl from: 1. www.skepticalscience.com (server's certificate chain is incomplete) 2. firstmonday.org (uses the expired AddTrust External TTP Network root certificate) Both are detected as valid in ungoogle-chromium. I can ask each of them to update their certificates but I fear it will be difficult to explain why, given that all "modern browsers" have absolutely no problem with them :-S ...and yes, I agree they **have** a problem with their certificate chains :-( Thanks! Giovanni. -- Giovanni Biscuolo Xelera IT Infrastructures