[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: curl server certificate verification failed for a few sites
From: |
Giovanni Biscuolo |
Subject: |
Re: curl server certificate verification failed for a few sites |
Date: |
Sat, 06 Jun 2020 11:16:47 +0200 |
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
signature.asc
Description: PGP signature