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

Previous Next

Full log

View this message in rfc822 format

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: 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

Previous Next

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