bug#45358: bootstrap fails due to a certificate mismatch

[Grigoriy Sokolik]

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