Re: curl server certificate verification failed for a few sites

[Giovanni Biscuolo <g@xelera.eu>]

[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]

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 <me@tobias.gr> writes:

> Giovanni Biscuolo 写道：
>> Jack Hill <jackhill@jackhill.us> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]