[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45358: bootstrap fails due to a certificate mismatch
From: |
Bob Proulx |
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
- bug#45358: bootstrap fails due to a certificate mismatch,
Bob Proulx <=