GNU bug report logs - #45358
bootstrap fails due to a certificate mismatch

Previous Next

Package: coreutils;

Reported by: "j-james" <jj <at> j-james.me>

Date: Tue, 22 Dec 2020 02:02:01 UTC

Severity: normal

Done: Bob Proulx <bob <at> proulx.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45358 in the body.
You can then email your comments to 45358 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Tue, 22 Dec 2020 02:02:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to "j-james" <jj <at> j-james.me>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Tue, 22 Dec 2020 02:02:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "j-james" <jj <at> j-james.me>
To: <bug-coreutils <at> gnu.org>
Subject: bootstrap fails due to a certificate mismatch
Date: Mon, 21 Dec 2020 17:29:35 -0800
When running ./bootstrap in a freshly-cloned repository, it seems to either 
not find some files it wants to or doesn't trust https://translationproject.org.

Connecting to https://translationproject.org in a (non-wget) web browser works fine.

The following is the output of ./bootstrap.
```
./bootstrap: Bootstrapping from checked-out coreutils sources...
./bootstrap: consider installing git-merge-changelog from gnulib
./bootstrap: getting gnulib files...
Submodule 'gnulib' (git://git.sv.gnu.org/gnulib.git) registered for path 'gnulib'
Cloning into '/home/teal/Projects/coreutils/gnulib'...
Submodule path 'gnulib': checked out '8183682cc4436bee18007d61bc79938eaf78619a'
./bootstrap: getting translations into po/.reference for coreutils...
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
ERROR: The certificate of 'translationproject.org' is not trusted.
ERROR: The certificate of 'translationproject.org' doesn't have a known issuer.
```

Do let me know if you need more information, or if this is a duplicate report.

-- j-james




Information forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Sat, 13 Feb 2021 12:57:02 GMT) Full text and rfc822 format available.

Message #8 received at 45358 <at> debbugs.gnu.org (full text, mbox):

From: Grigoriy Sokolik <g.sokol99 <at> g-sokol.info>
To: 45358 <at> debbugs.gnu.org
Subject: RE: bug#45358: bootstrap fails due to a certificate mismatch
Date: Sat, 13 Feb 2021 14:43:10 +0200
[Message part 1 (text/plain, inline)]
I have the same issue.

Some investigations:

   1. I decided to find out the particular command that fails and added
   more debug print:

   diff --git a/bootstrap b/bootstrap
   index 7523f65b4..44c21db23 100755
   --- a/bootstrap
   +++ b/bootstrap
   @@ -749,6 +749,7 @@ download_po_files() {
      domain=$2
      echo "$me: getting translations into $subdir for $domain..."
      cmd=$(printf "$po_download_command_format" "$subdir" "$domain")
   +  echo "$me: going to exec \"$cmd\"..."
      eval "$cmd"
   }

   2. Tried to run:

   $ ./bootstrap
   ./bootstrap: Bootstrapping from checked-out coreutils sources...
   ./bootstrap: consider installing git-merge-changelog from gnulib
   ./bootstrap: getting gnulib files...
   ./bootstrap: getting translations into po/.reference for coreutils...
   ./bootstrap: going to exec "wget --mirror --level=1 -nd -nv -A.po -P
   'po/.reference' https://translationproject.org/latest/coreutils/"...
   ERROR: The certificate of 'translationproject.org' is not trusted.
   ERROR: The certificate of 'translationproject.org' doesn't have a known
   issuer.

   3. Tried to run the command directly, but without `-nv` flag:

   $ wget --mirror --level=1 -nd -v -A.po -P 'po/.reference'
   https://translationproject.org/latest/coreutils/
   --2021-02-13 14:23:35--  https://translationproject.org/latest/coreutils/
   Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
   Resolving translationproject.org (translationproject.org)...
   80.69.83.146, 2a01:7c8:c037:6::20
   Connecting to translationproject.org
(translationproject.org)|80.69.83.146|:443...
   connected.
   ERROR: The certificate of ‘translationproject.org’ is not trusted.
   ERROR: The certificate of ‘translationproject.org’ doesn't have a known
   issuer.

   4. Tried the same with curl:

   $ curl -v https://translationproject.org/latest/coreutils/ -o /dev/null
     % Total    % Received % Xferd  Average Speed   Time    Time     Time
    Current
                                    Dload  Upload   Total   Spent    Left
    Speed
     0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--
       0*   Trying 80.69.83.146:443...
   * Connected to translationproject.org (80.69.83.146) port 443 (#0)
   * ALPN, offering h2
   * ALPN, offering http/1.1
   * successfully set certificate verify locations:
   *  CAfile: /etc/ssl/certs/ca-certificates.crt
   *  CApath: none
   } [5 bytes data]
   * TLSv1.3 (OUT), TLS handshake, Client hello (1):
   } [512 bytes data]
   * TLSv1.3 (IN), TLS handshake, Server hello (2):
   { [93 bytes data]
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   { [6723 bytes data]
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   { [589 bytes data]
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   { [4 bytes data]
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   } [70 bytes data]
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   } [1 bytes data]
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   } [16 bytes data]
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   { [16 bytes data]
   * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
   * ALPN, server did not agree to a protocol
   * Server certificate:
   *  subject: CN=stats.vrijschrift.org
   *  start date: Dec 31 10:34:41 2020 GMT
   *  expire date: Mar 31 10:34:41 2021 GMT
   *  subjectAltName: host "translationproject.org" matched cert's
   "translationproject.org"
   *  issuer: C=US; O=Let's Encrypt; CN=R3
   *  SSL certificate verify ok.
   } [5 bytes data]
   > GET /latest/coreutils/ HTTP/1.1
   > Host: translationproject.org
   > User-Agent: curl/7.75.0
   > Accept: */*
   >
   { [5 bytes data]
   * Mark bundle as not supporting multiuse
   < HTTP/1.1 200 OK
   < Date: Sat, 13 Feb 2021 12:26:00 GMT
   < Server: Apache/2.4.10 (Debian)
   < Vary: Accept-Encoding
   < Transfer-Encoding: chunked
   < Content-Type: text/html;charset=UTF-8
   <
   { [5 bytes data]
   100  8881    0  8881    0     0  16980      0 --:--:-- --:--:-- --:--:--
   16980
   * Connection #0 to host translationproject.org left intact

   5. Trying to export and verify the cert with certtools:

   $ certtool --verbose --verify-profile=high --verify --infile=/tmp/
   stats.vrijschrift.org
   Loaded system trust (139 CAs available)
           Subject: CN=R3,O=Let's Encrypt,C=US
           Issuer: CN=DST Root CA X3,O=Digital Signature Trust Co.
           Signature algorithm: RSA-SHA256
           Output: Not verified. The certificate is NOT trusted. The
   certificate issuer is unknown.

           Subject: CN=R3,O=Let's Encrypt,C=US
           Issuer: CN=DST Root CA X3,O=Digital Signature Trust Co.
           Signature algorithm: RSA-SHA256
           Output: Not verified. The certificate is NOT trusted. The
   certificate issuer is unknown.

           Subject: CN=R3,O=Let's Encrypt,C=US
           Issuer: CN=DST Root CA X3,O=Digital Signature Trust Co.
           Checked against: CN=DST Root CA X3,O=Digital Signature Trust Co.
           Signature algorithm: RSA-SHA256
           Output: Verified. The certificate is trusted.

           Subject: CN=stats.vrijschrift.org
           Issuer: CN=R3,O=Let's Encrypt,C=US
           Checked against: CN=R3,O=Let's Encrypt,C=US
           Signature algorithm: RSA-SHA256
           Output: Verified. The certificate is trusted.

   Chain verification output: Verified. The certificate is trusted.

   Maybe that "Output: Not verified. The certificate is NOT trusted. The
   certificate issuer is unknown." Is the issue?


Thanks!
Best regards,
Grigorii
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Mon, 15 Feb 2021 15:07:02 GMT) Full text and rfc822 format available.

Message #11 received at 45358 <at> debbugs.gnu.org (full text, mbox):

From: Grigoriy Sokolik <g.sokol99 <at> g-sokol.info>
To: 45358 <at> debbugs.gnu.org
Subject: RE: bug#45358: bootstrap fails due to a certificate mismatch
Date: Mon, 15 Feb 2021 13:07:49 +0200
[Message part 1 (text/plain, inline)]
The temporary workaround could be, at least to skip the certificate
validation:

```
$ git --no-pager diff
diff --git a/bootstrap b/bootstrap
index 7523f65b4..dcb8aa388 100755
--- a/bootstrap
+++ b/bootstrap
@@ -180,7 +180,7 @@ bootstrap_epilogue() { :; }
 # specified directory.  Fill in the first %s with the destination
 # directory and the second with the domain name.
 po_download_command_format=\
-"wget --mirror --level=1 -nd -nv -A.po -P '%s' \
+"wget --mirror --level=1 -nd --no-check-certificate -nv -A.po -P '%s' \
  https://translationproject.org/latest/%s/"

 # Prefer a non-empty tarname (4th argument of AC_INIT if given), else
```

But be careful, this is really bad advice: fetching anything without
consistency ad authority validation is really insecure!

Thanks!
Best regards,
Grigorii
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Tue, 16 Feb 2021 17:29:02 GMT) Full text and rfc822 format available.

Message #14 received at 45358 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Grigoriy Sokolik <g.sokol99 <at> g-sokol.info>, 45358 <at> debbugs.gnu.org
Subject: Re: bug#45358: bootstrap fails due to a certificate mismatch
Date: Tue, 16 Feb 2021 09:28:51 -0800
On 2/15/21 3:07 AM, Grigoriy Sokolik wrote:

> But be careful, this is really bad advice: fetching anything without
> consistency ad authority validation is really insecure!

Yes, we should instead fix the underlying problem whatever it is (not 
sure what it is since that wasn't reported).




Information forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Wed, 17 Feb 2021 09:39:01 GMT) Full text and rfc822 format available.

Message #17 received at 45358 <at> debbugs.gnu.org (full text, mbox):

From: Grigoriy Sokolik <g.sokol99 <at> g-sokol.info>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 45358 <at> debbugs.gnu.org
Subject: Re: bug#45358: bootstrap fails due to a certificate mismatch
Date: Wed, 17 Feb 2021 11:38:12 +0200
[Message part 1 (text/plain, inline)]
The thing is that translationproject returns the wrong certificate.

Thanks!
Best regards,
Grigorii


On Tue, 16 Feb 2021 at 19:28, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 2/15/21 3:07 AM, Grigoriy Sokolik wrote:
>
> > But be careful, this is really bad advice: fetching anything without
> > consistency ad authority validation is really insecure!
>
> Yes, we should instead fix the underlying problem whatever it is (not
> sure what it is since that wasn't reported).
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Fri, 19 Feb 2021 19:06:02 GMT) Full text and rfc822 format available.

Message #20 received at 45358 <at> debbugs.gnu.org (full text, mbox):

From: Benno Schulenberg <coordinator <at> translationproject.org>
To: Nekolyanich <gmail <at> nekolyanich.com>
Cc: 45358 <at> debbugs.gnu.org
Subject: Re: Wrong CA certificate on translationproject.org
Date: Fri, 19 Feb 2021 20:05:29 +0100
Op 17-02-2021 om 10:28 schreef Nekolyanich:
> I find this https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45358 recently.

Cannot reproduce.  Downloading any project's PO files with wget works
fine here -- no complaints about certificates.

Why does your wget complain when curl and Firefox have no problem?

> Your site(translationproject.org) provides
> 
> Subject: C=US,O=Let's Encrypt,CN=R3
> Issuer: O=Digital Signature Trust Co.,CN=DST Root CA X3
> Serial: 85078157426496920958827089468591623647
> 
> as CA certificate.
> But your EndEntity certificate signed with
> 
> Subject: C=US,O=Let's Encrypt,CN=R3
> Issuer: C=US,O=Internet Security Research Group,CN=ISRG Root X1
> Serial: 192961496339968674994309121183282847578
> 
> You can find this certificate on LetsEncrypt site.

I have no idea what to do about this.  Any guidance?

Benno





Information forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Fri, 19 Feb 2021 20:02:01 GMT) Full text and rfc822 format available.

Message #23 received at 45358 <at> debbugs.gnu.org (full text, mbox):

From: Grigoriy Sokolik <g.sokol99 <at> g-sokol.info>
To: Benno Schulenberg <coordinator <at> translationproject.org>
Cc: 45358 <at> debbugs.gnu.org, Nekolyanich <gmail <at> nekolyanich.com>
Subject: Re: bug#45358: Wrong CA certificate on translationproject.org
Date: Fri, 19 Feb 2021 22:00:43 +0200
[Message part 1 (text/plain, inline)]
Because wget uses gnutls for verification, curl -- openssl and browsers --
their own implementations.

Thanks!
Best regards,
Grigorii


On Fri, 19 Feb 2021 at 21:06, Benno Schulenberg <
coordinator <at> translationproject.org> wrote:

>
> Op 17-02-2021 om 10:28 schreef Nekolyanich:
> > I find this https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45358
> recently.
>
> Cannot reproduce.  Downloading any project's PO files with wget works
> fine here -- no complaints about certificates.
>
> Why does your wget complain when curl and Firefox have no problem?
>
> > Your site(translationproject.org) provides
> >
> > Subject: C=US,O=Let's Encrypt,CN=R3
> > Issuer: O=Digital Signature Trust Co.,CN=DST Root CA X3
> > Serial: 85078157426496920958827089468591623647
> >
> > as CA certificate.
> > But your EndEntity certificate signed with
> >
> > Subject: C=US,O=Let's Encrypt,CN=R3
> > Issuer: C=US,O=Internet Security Research Group,CN=ISRG Root X1
> > Serial: 192961496339968674994309121183282847578
> >
> > You can find this certificate on LetsEncrypt site.
>
> I have no idea what to do about this.  Any guidance?
>
> Benno
>
>
>
>
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Tue, 09 Mar 2021 05:56:02 GMT) Full text and rfc822 format available.

Message #26 received at 45358 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Grigoriy Sokolik <g.sokol99 <at> g-sokol.info>
Cc: 45358 <at> debbugs.gnu.org, 45358-submitter <at> debbugs.gnu.org
Subject: Re: bug#45358: bootstrap fails due to a certificate mismatch
Date: Mon, 8 Mar 2021 22:54:59 -0700
Is this problem still a problem?  Perhaps it has been fixed in the
time this has been under discussion?  Because it looks okay to me.

Grigoriy Sokolik wrote:
>    $ curl -v https://translationproject.org/latest/coreutils/ -o /dev/null
...
>    * Connected to translationproject.org (80.69.83.146) port 443 (#0)
...
>    * successfully set certificate verify locations:
>    *  CAfile: /etc/ssl/certs/ca-certificates.crt
>    *  CApath: none

I suspect this last line to be the root cause of the problem.  There
is no CApath and therefore no root anchoring certificates trusted.
Without that I don't see how any certificates can be trusted.

I do the same test here and see this.

    $ curl -v https://translationproject.org/latest/coreutils/ -o /dev/null
    ...
    * Connected to translationproject.org (80.69.83.146) port 443 (#0)
    ...
    * successfully set certificate verify locations:
    *  CAfile: /etc/ssl/certs/ca-certificates.crt
    *  CApath: /etc/ssl/certs

Note the inclusion of the trusted root path.

    * Server certificate:
    *  subject: CN=stats.vrijschrift.org
    *  start date: Mar  1 10:34:36 2021 GMT
    *  expire date: May 30 10:34:36 2021 GMT
    *  subjectAltName: host "translationproject.org" matched cert's
    *  "translationproject.org"
    *  issuer: C=US; O=Let's Encrypt; CN=R3
    *  SSL certificate verify ok.

Note that the certificate validates as okay.

Also if I simply ask openssl to validate:

    $ openssl s_client -connect translationproject.org:443 -CApath /etc/ssl/certs -showcerts </dev/null 2>/dev/null
    ...
        Verify return code: 0 (ok)

If I download all of the certificates and validate using certtool,
since you mentioned certtool I will use your example:

    $ openssl s_client -connect translationproject.org:443 -CApath /etc/ssl/certs -showcerts </dev/null 2>/dev/null  | sed -n '/^-----BEGIN CERTIFICATE-----/,/^-----END CERTIFICATE-----/p' > /tmp/translationproject.org.certs
    $ certtool --verbose --verify-profile=high --verify --infile=/tmp/translationproject.org.certs
    Loaded system trust (127 CAs available)
    	Subject: CN=R3,O=Let's Encrypt,C=US
    	Issuer: CN=DST Root CA X3,O=Digital Signature Trust Co.
    	Checked against: CN=DST Root CA X3,O=Digital Signature Trust Co.
    	Signature algorithm: RSA-SHA256
    	Output: Verified. The certificate is trusted. 

    	Subject: CN=stats.vrijschrift.org
    	Issuer: CN=R3,O=Let's Encrypt,C=US
    	Checked against: CN=R3,O=Let's Encrypt,C=US
    	Signature algorithm: RSA-SHA256
    	Output: Verified. The certificate is trusted. 

    Chain verification output: Verified. The certificate is trusted. 

Then it again validates okay.

I note that the certificate is current as of now and just recently
renewed.  It's fresh.

    $ openssl s_client -connect translationproject.org:443 -CApath /etc/ssl/certs -showcerts </dev/null 2>/dev/null | sed -n '/^-----BEGIN CERTIFICATE-----/,/^-----END CERTIFICATE-----/p;/^-----END CERTIFICATE-----/q' | openssl x509 -noout -dates
    notBefore=Mar  1 10:34:36 2021 GMT
    notAfter=May 30 10:34:36 2021 GMT

Therefore I think everything is okay as far as I can tell from the
above.  Perhaps something about the site has changed to resolve a
problem since then?  Perhaps an intermediate certificate was added?

Bob




Message sent on to "j-james" <jj <at> j-james.me>:
bug#45358. (Tue, 09 Mar 2021 05:56:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Tue, 09 Mar 2021 09:29:02 GMT) Full text and rfc822 format available.

Message #32 received at 45358 <at> debbugs.gnu.org (full text, mbox):

From: Grigoriy Sokolik <g.sokol99 <at> g-sokol.info>
To: Bob Proulx <bob <at> proulx.com>
Cc: 45358 <at> debbugs.gnu.org, 45358-submitter <at> debbugs.gnu.org
Subject: Re: bug#45358: bootstrap fails due to a certificate mismatch
Date: Tue, 9 Mar 2021 11:28:18 +0200
[Message part 1 (text/plain, inline)]
I've rechecked:

```
    $ gnutls-cli translationproject.org

    Processed 139 CA certificate(s).
    Resolving 'translationproject.org:443'...
    Connecting to '80.69.83.146:443'...
    - Certificate type: X.509
    - Got a certificate list of 3 certificates.
    - Certificate[0] info:
    - subject `CN=stats.vrijschrift.org', issuer `CN=R3,O=Let's
Encrypt,C=US', serial 0x043ecc3aacb8c85e4b142ad6a502a8e749c7, RSA key 4096
bits, signed using RSA-SHA256, activated `2021-03-01 10:34:36 UTC', expires
`2021-05-30 10:34:36 UTC',
pin-sha256="rsabKAqi6gmbwfkm2Kj69kMk9vceM1pOrIsSWJ29axA="
    Public Key ID:
    sha1:351b768332605268f158f75cc602b700c8950d71
    sha256:aec69b280aa2ea099bc1f926d8a8faf64324f6f71e335a4eac8b12589dbd6b10
    Public Key PIN:
    pin-sha256:rsabKAqi6gmbwfkm2Kj69kMk9vceM1pOrIsSWJ29axA=

    - Certificate[1] info:
    - subject `CN=stats.vrijschrift.org', issuer `CN=R3,O=Let's
Encrypt,C=US', serial 0x043ecc3aacb8c85e4b142ad6a502a8e749c7, RSA key 4096
bits, signed using RSA-SHA256, activated `2021-03-01 10:34:36 UTC', expires
`2021-05-30 10:34:36 UTC',
pin-sha256="rsabKAqi6gmbwfkm2Kj69kMk9vceM1pOrIsSWJ29axA="
    - Certificate[2] info:
    - subject `CN=R3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA
X3,O=Digital Signature Trust Co.', serial
0x400175048314a4c8218c84a90c16cddf, RSA key 2048 bits, signed using
RSA-SHA256, activated `2020-10-07 19:21:40 UTC', expires `2021-09-29
19:21:40 UTC', pin-sha256="jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0="
    - Status: The certificate is NOT trusted. The certificate issuer is
unknown.
    *** PKI verification of server certificate failed...
    *** Fatal error: Error in the certificate.
```

```
    $ openssl s_client -connect translationproject.org:443 -CApath
/etc/ssl/certs -showcerts </dev/null 2>/dev/null  | sed -n '/^-----BEGIN
CERTIFICATE-----/,/^-----END CERTIFICATE-----/p' >
/tmp/translationproject.org.certs
    $ certtool --verbose --verify-profile=high --verify
--infile=/tmp/translationproject.org.certs
    Loaded system trust (139 CAs available)
    Subject: CN=stats.vrijschrift.org
    Issuer: CN=R3,O=Let's Encrypt,C=US
    Signature algorithm: RSA-SHA256
    Output: Not verified. The certificate is NOT trusted. The certificate
issuer is unknown.

    Subject: CN=stats.vrijschrift.org
    Issuer: CN=R3,O=Let's Encrypt,C=US
    Signature algorithm: RSA-SHA256
    Output: Not verified. The certificate is NOT trusted. The certificate
issuer is unknown.

    Subject: CN=stats.vrijschrift.org
    Issuer: CN=R3,O=Let's Encrypt,C=US
    Signature algorithm: RSA-SHA256
    Output: Not verified. The certificate is NOT trusted. The certificate
issuer is unknown.

    Chain verification output: Not verified. The certificate is NOT
trusted. The certificate issuer is unknown.

```

Thanks!
Best regards,
Grigorii


On Tue, 9 Mar 2021 at 07:55, Bob Proulx <bob <at> proulx.com> wrote:

> Is this problem still a problem?  Perhaps it has been fixed in the
> time this has been under discussion?  Because it looks okay to me.
>
> Grigoriy Sokolik wrote:
> >    $ curl -v https://translationproject.org/latest/coreutils/ -o
> /dev/null
> ...
> >    * Connected to translationproject.org (80.69.83.146) port 443 (#0)
> ...
> >    * successfully set certificate verify locations:
> >    *  CAfile: /etc/ssl/certs/ca-certificates.crt
> >    *  CApath: none
>
> I suspect this last line to be the root cause of the problem.  There
> is no CApath and therefore no root anchoring certificates trusted.
> Without that I don't see how any certificates can be trusted.
>
> I do the same test here and see this.
>
>     $ curl -v https://translationproject.org/latest/coreutils/ -o
> /dev/null
>     ...
>     * Connected to translationproject.org (80.69.83.146) port 443 (#0)
>     ...
>     * successfully set certificate verify locations:
>     *  CAfile: /etc/ssl/certs/ca-certificates.crt
>     *  CApath: /etc/ssl/certs
>
> Note the inclusion of the trusted root path.
>
>     * Server certificate:
>     *  subject: CN=stats.vrijschrift.org
>     *  start date: Mar  1 10:34:36 2021 GMT
>     *  expire date: May 30 10:34:36 2021 GMT
>     *  subjectAltName: host "translationproject.org" matched cert's
>     *  "translationproject.org"
>     *  issuer: C=US; O=Let's Encrypt; CN=R3
>     *  SSL certificate verify ok.
>
> Note that the certificate validates as okay.
>
> Also if I simply ask openssl to validate:
>
>     $ openssl s_client -connect translationproject.org:443 -CApath
> /etc/ssl/certs -showcerts </dev/null 2>/dev/null
>     ...
>         Verify return code: 0 (ok)
>
> If I download all of the certificates and validate using certtool,
> since you mentioned certtool I will use your example:
>
>     $ openssl s_client -connect translationproject.org:443 -CApath
> /etc/ssl/certs -showcerts </dev/null 2>/dev/null  | sed -n '/^-----BEGIN
> CERTIFICATE-----/,/^-----END CERTIFICATE-----/p' > /tmp/
> translationproject.org.certs
>     $ certtool --verbose --verify-profile=high --verify
> --infile=/tmp/translationproject.org.certs
>     Loaded system trust (127 CAs available)
>         Subject: CN=R3,O=Let's Encrypt,C=US
>         Issuer: CN=DST Root CA X3,O=Digital Signature Trust Co.
>         Checked against: CN=DST Root CA X3,O=Digital Signature Trust Co.
>         Signature algorithm: RSA-SHA256
>         Output: Verified. The certificate is trusted.
>
>         Subject: CN=stats.vrijschrift.org
>         Issuer: CN=R3,O=Let's Encrypt,C=US
>         Checked against: CN=R3,O=Let's Encrypt,C=US
>         Signature algorithm: RSA-SHA256
>         Output: Verified. The certificate is trusted.
>
>     Chain verification output: Verified. The certificate is trusted.
>
> Then it again validates okay.
>
> I note that the certificate is current as of now and just recently
> renewed.  It's fresh.
>
>     $ openssl s_client -connect translationproject.org:443 -CApath
> /etc/ssl/certs -showcerts </dev/null 2>/dev/null | sed -n '/^-----BEGIN
> CERTIFICATE-----/,/^-----END CERTIFICATE-----/p;/^-----END
> CERTIFICATE-----/q' | openssl x509 -noout -dates
>     notBefore=Mar  1 10:34:36 2021 GMT
>     notAfter=May 30 10:34:36 2021 GMT
>
> Therefore I think everything is okay as far as I can tell from the
> above.  Perhaps something about the site has changed to resolve a
> problem since then?  Perhaps an intermediate certificate was added?
>
> Bob
>
[Message part 2 (text/html, inline)]

Message sent on to "j-james" <jj <at> j-james.me>:
bug#45358. (Tue, 09 Mar 2021 09:29:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Tue, 09 Mar 2021 10:37:01 GMT) Full text and rfc822 format available.

Message #38 received at 45358 <at> debbugs.gnu.org (full text, mbox):

From: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
To: Grigoriy Sokolik <g.sokol99 <at> g-sokol.info>
Cc: 45358 <at> debbugs.gnu.org, 45358-submitter <at> debbugs.gnu.org,
 Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#45358: bootstrap fails due to a certificate mismatch
Date: Tue, 9 Mar 2021 11:35:58 +0100
Hi,

On Tue, Mar 09, 2021 at 11:28:18AM +0200, Grigoriy Sokolik wrote:
> I've rechecked:

I cannot reproduce the problem, the certificate is trusted by my system:

    # via IPv4
    $ gnutls-cli --verbose translationproject.org </dev/null  | grep -E 'Connecting|Status'
    Connecting to '80.69.83.146:443'...
    - Status: The certificate is trusted. 
    # via IPv6
    $ gnutls-cli --verbose translationproject.org </dev/null  | grep -E 'Connecting|Status'
    Connecting to '2a01:7c8:c037:6::20:443'...
    - Status: The certificate is trusted.

It seems to me as if your system does not trust the used root CA.

>     [...]issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.'[...]

On my Ubuntu 18.04 system, I find it via symlink from /etc/ssl/certs:

    $ ls /etc/ssl/certs/DST_Root_CA_X3.pem -l
    lrwxrwxrwx 1 root root 53 Mai 28  2018 /etc/ssl/certs/DST_Root_CA_X3.pem -> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
    $ certtool --certificate-info < /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt | grep Subject:
    	Subject: CN=DST Root CA X3,O=Digital Signature Trust Co.

HTH,
Erik
-- 
[A]pplied cryptography mostly sucks.
                        -- Green's law of applied cryptography




Message sent on to "j-james" <jj <at> j-james.me>:
bug#45358. (Tue, 09 Mar 2021 10:37:01 GMT) Full text and rfc822 format available.

Reply sent to Bob Proulx <bob <at> proulx.com>:
You have taken responsibility. (Tue, 09 Mar 2021 18:31:02 GMT) Full text and rfc822 format available.

Notification sent to "j-james" <jj <at> j-james.me>:
bug acknowledged by developer. (Tue, 09 Mar 2021 18:31:02 GMT) Full text and rfc822 format available.

Message #46 received at 45358-done <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
Cc: 45358-done <at> debbugs.gnu.org, 45358-submitter <at> debbugs.gnu.org,
 Grigoriy Sokolik <g.sokol99 <at> g-sokol.info>
Subject: Re: bug#45358: bootstrap fails due to a certificate mismatch
Date: Tue, 9 Mar 2021 11:30:02 -0700
Erik Auerswald wrote:
> Grigoriy Sokolik wrote:
> > I've rechecked:
> 
> I cannot reproduce the problem, the certificate is trusted by my system:
> 
>     # via IPv4
>     $ gnutls-cli --verbose translationproject.org </dev/null  | grep -E 'Connecting|Status'
>     Connecting to '80.69.83.146:443'...
>     - Status: The certificate is trusted. 
>     # via IPv6
>     $ gnutls-cli --verbose translationproject.org </dev/null  | grep -E 'Connecting|Status'
>     Connecting to '2a01:7c8:c037:6::20:443'...
>     - Status: The certificate is trusted.

I have the same results here.  Everything looks okay in the inspection
of it.

> It seems to me as if your system does not trust the used root CA.
> 
> >     [...]issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.'[...]
> 
> On my Ubuntu 18.04 system, I find it via symlink from /etc/ssl/certs:
> 
>     $ ls /etc/ssl/certs/DST_Root_CA_X3.pem -l
>     lrwxrwxrwx 1 root root 53 Mai 28  2018 /etc/ssl/certs/DST_Root_CA_X3.pem -> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
>     $ certtool --certificate-info < /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt | grep Subject:
>     	Subject: CN=DST Root CA X3,O=Digital Signature Trust Co.

Again same here on my Debian system.  The root certificate store for
the trust anchor is in the ca-certificates package.

Looking at my oldest system I see this is distributed as package
version 20200601~deb9u1 and includes the above file.

    $ apt-cache policy ca-certificates
    ca-certificates:
      Installed: 20200601~deb9u1
      Candidate: 20200601~deb9u1
      Version table:
     *** 20200601~deb9u1 500
            500 http://ftp.us.debian.org/debian stretch/main amd64 Packages
            500 http://ftp.us.debian.org/debian stretch-updates/main amd64 Packages
            100 /var/lib/dpkg/status

Verifying that the equivalent of ca-certificates is installed on your
system should provide for it.

As this seems not to be a bug in Coreutils I am marking the bug as
closed with this mail.  However more discussion is always welcome.

Bob




Message sent on to "j-james" <jj <at> j-james.me>:
bug#45358. (Tue, 09 Mar 2021 18:31:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#45358; Package coreutils. (Wed, 10 Mar 2021 14:11:02 GMT) Full text and rfc822 format available.

Message #52 received at 45358-done <at> debbugs.gnu.org (full text, mbox):

From: Grigoriy Sokolik <g.sokol99 <at> g-sokol.info>
To: Bob Proulx <bob <at> proulx.com>
Cc: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>, 45358-done <at> debbugs.gnu.org,
 45358-submitter <at> debbugs.gnu.org
Subject: Re: bug#45358: bootstrap fails due to a certificate mismatch
Date: Wed, 10 Mar 2021 16:10:33 +0200
[Message part 1 (text/plain, inline)]
That's fixed for me now with the new version of GnuTLS 3.7.1

Thanks!
Best regards,
Grigorii


On Tue, 9 Mar 2021 at 20:30, Bob Proulx <bob <at> proulx.com> wrote:

> Erik Auerswald wrote:
> > Grigoriy Sokolik wrote:
> > > I've rechecked:
> >
> > I cannot reproduce the problem, the certificate is trusted by my system:
> >
> >     # via IPv4
> >     $ gnutls-cli --verbose translationproject.org </dev/null  | grep -E
> 'Connecting|Status'
> >     Connecting to '80.69.83.146:443'...
> >     - Status: The certificate is trusted.
> >     # via IPv6
> >     $ gnutls-cli --verbose translationproject.org </dev/null  | grep -E
> 'Connecting|Status'
> >     Connecting to '2a01:7c8:c037:6::20:443'...
> >     - Status: The certificate is trusted.
>
> I have the same results here.  Everything looks okay in the inspection
> of it.
>
> > It seems to me as if your system does not trust the used root CA.
> >
> > >     [...]issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.'[...]
> >
> > On my Ubuntu 18.04 system, I find it via symlink from /etc/ssl/certs:
> >
> >     $ ls /etc/ssl/certs/DST_Root_CA_X3.pem -l
> >     lrwxrwxrwx 1 root root 53 Mai 28  2018
> /etc/ssl/certs/DST_Root_CA_X3.pem ->
> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
> >     $ certtool --certificate-info <
> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt | grep Subject:
> >       Subject: CN=DST Root CA X3,O=Digital Signature Trust Co.
>
> Again same here on my Debian system.  The root certificate store for
> the trust anchor is in the ca-certificates package.
>
> Looking at my oldest system I see this is distributed as package
> version 20200601~deb9u1 and includes the above file.
>
>     $ apt-cache policy ca-certificates
>     ca-certificates:
>       Installed: 20200601~deb9u1
>       Candidate: 20200601~deb9u1
>       Version table:
>      *** 20200601~deb9u1 500
>             500 http://ftp.us.debian.org/debian stretch/main amd64
> Packages
>             500 http://ftp.us.debian.org/debian stretch-updates/main
> amd64 Packages
>             100 /var/lib/dpkg/status
>
> Verifying that the equivalent of ca-certificates is installed on your
> system should provide for it.
>
> As this seems not to be a bug in Coreutils I am marking the bug as
> closed with this mail.  However more discussion is always welcome.
>
> Bob
>
[Message part 2 (text/html, inline)]

Message sent on to "j-james" <jj <at> j-james.me>:
bug#45358. (Wed, 10 Mar 2021 14:11:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 08 Apr 2021 11:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 355 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.