all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Giovanni Biscuolo <g@xelera.eu>
To: Tobias Geerinckx-Rice <me@tobias.gr>
Cc: help-guix@gnu.org
Subject: Re: curl server certificate verification failed for a few sites
Date: Sat, 06 Jun 2020 11:16:47 +0200	[thread overview]
Message-ID: <87tuzok0zk.fsf@roquette.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <874krqdboh.fsf@nckx>

[-- 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 --]

  reply	other threads:[~2020-06-06  9:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04 13:13 curl server certificate verification failed for a few sites Giovanni Biscuolo
2020-06-04 14:40 ` Jack Hill
2020-06-04 16:14   ` Giovanni Biscuolo
2020-06-04 16:43     ` Tobias Geerinckx-Rice
2020-06-06  9:16       ` Giovanni Biscuolo [this message]
2020-06-06 13:44         ` Marius Bakke
2020-06-08 17:52           ` Giovanni Biscuolo
2020-06-06 14:29         ` Tobias Geerinckx-Rice

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tuzok0zk.fsf@roquette.i-did-not-set--mail-host-address--so-tickle-me \
    --to=g@xelera.eu \
    --cc=help-guix@gnu.org \
    --cc=me@tobias.gr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.