From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id QCr5LSxf217NBgAA0tVLHw (envelope-from ) for ; Sat, 06 Jun 2020 09:17:32 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id oBX9KSxf216RPAAA1q6Kng (envelope-from ) for ; Sat, 06 Jun 2020 09:17:32 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 36CF89404C5 for ; Sat, 6 Jun 2020 09:17:32 +0000 (UTC) Received: from localhost ([::1]:37350 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhUxH-00055K-5u for larch@yhetil.org; Sat, 06 Jun 2020 05:17:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48012) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhUx9-000559-Qf for help-guix@gnu.org; Sat, 06 Jun 2020 05:17:23 -0400 Received: from ns13.heimat.it ([46.4.214.66]:44154) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhUx8-0001b8-Er for help-guix@gnu.org; Sat, 06 Jun 2020 05:17:23 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 407A23021B6; Sat, 6 Jun 2020 09:17:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at ns13.heimat.it Received: from ns13.heimat.it ([127.0.0.1]) by localhost (ns13.heimat.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivj39X1GXNkN; Sat, 6 Jun 2020 09:16:59 +0000 (UTC) Received: from bourrache.mug.xelera.it (unknown [93.56.169.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ns13.heimat.it (Postfix) with ESMTPSA id 3DCBA3021B5; Sat, 6 Jun 2020 09:16:59 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id 767B339E091; Sat, 6 Jun 2020 11:16:57 +0200 (CEST) Received: (nullmailer pid 15327 invoked by uid 1000); Sat, 06 Jun 2020 09:16:52 -0000 From: Giovanni Biscuolo To: Tobias Geerinckx-Rice Subject: Re: curl server certificate verification failed for a few sites In-Reply-To: <874krqdboh.fsf@nckx> Organization: Xelera.eu References: <87sgfbkm7g.fsf@roquette.i-did-not-set--mail-host-address--so-tickle-me> <87o8pylsel.fsf@roquette.i-did-not-set--mail-host-address--so-tickle-me> <874krqdboh.fsf@nckx> Date: Sat, 06 Jun 2020 11:16:47 +0200 Message-ID: <87tuzok0zk.fsf@roquette.i-did-not-set--mail-host-address--so-tickle-me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=46.4.214.66; envelope-from=g@xelera.eu; helo=ns13.heimat.it X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/06 05:17:19 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: help-guix@gnu.org Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: "Help-Guix" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-Spam-Score: -3.11 X-TUID: eID+3MvphL3S --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 =E5=86=99=E9=81=93=EF=BC=9A >> Jack Hill writes: >>> The error wget gives is a little bit better, > > FWIW, I use this (extremely verbose) command to debug/check my own=20 > servers: > > $ openssl s_client -showcerts -servername=20 > 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: =2D-8<---------------cut here---------------start------------->8--- depth=3D3 C =3D SE, O =3D AddTrust AB, OU =3D AddTrust External TTP Network= , CN =3D AddTrust External CA Root verify error:num=3D10:certificate has expired notAfter=3DMay 30 10:48:38 2020 GMT =2D-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=20 > be sending in the first place[0] which doesn't help matters. I=20 > 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=3D1 ce= rtificate: =2D-8<---------------cut here---------------start------------->8--- 1 s:/C=3DGB/ST=3DGreater Manchester/L=3DSalford/O=3DSectigo Limited/CN=3DS= ectigo RSA Domain Validation Secure Server CA i:/C=3DUS/ST=3DNew Jersey/L=3DJersey City/O=3DThe USERTRUST Network/CN= =3DUSERTrust RSA Certification Authority =2D-8<---------------cut here---------------end--------------->8--- >> Yes. All modern clients and operating systems have the newer,=20 >> modern >> COMODO and USERTrust roots which don=E2=80=99t expire until 2038. > > Right, but =E2=80=98modern=E2=80=99 there means ~2015. I don't fully understand what this means, sorry... but it's not important :-) > [0]:=20 > https://www.ssllabs.com/ssltest/analyze.html?d=3Dvoices.transparency.org&= s=3D52.4.38.70&hideResults=3Don 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. =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEERcxjuFJYydVfNLI5030Op87MORIFAl7bXwIACgkQ030Op87M ORLEQQ/9EeXmTEORIfFTIueUj1sodaeN8Jo5XlAez8Q28Qxd+Rvb9XNho2QwFAGC nW7ud5G/7yThqbP2nL9hY/2BB0d1egvpw1m8t2SvKT3lbGPZh8immtCHUKQWykDK QMZRQX6EP/hriZoeHI2Q2TBlm5L52G1DJbKK+9+m7PTp4jU7n5hJI4No5NAtBj5u /RTr+XpyIdJY79L07Kse4O6tJXQnw7pY3fLuvHAX3utaeuCdV6lhSSXQUIXZp1J6 uYIcy5CP+mB6zHkq3cTjgUBj6u9r3m5LxSc/ND7biEjl5sFa7K1QFyDAY6ZcHun4 AkjhTfng3t09ExZ9RemmpTtgLvCRSvjUTRQ9kvTk0RWRKsc52ARD54Wit8ec6LeH 5Mvf9TlCXKOf5W5iRV3idSn8u72Fi/2+32cKic1VfjuAkAhQVZcyfA8cjduQWajX XOL86EP7950/91DEAQeyO9JJ6tltpRZdFvnoohMmA/PD52AH3hdrE4Y0aFwGZoaL hOP6yy7TThLJHgtM3S8IlD14KuapbcjeB3PFKsNjIo8TVcHn1rZk7F6ZaIYP8GWC SRNCStD8YgOuiyj6sLY0GYQ5rGgqdPkM04i5Jufd69HPqqkbph3IXaBMUVt0AOl3 KYPksjvZpLoAiR2csDvuOKsh0Vap7SvEagGnqpNz/D4yoUXkPyM= =TzJp -----END PGP SIGNATURE----- --=-=-=--