GNU bug report logs -
#45358
bootstrap fails due to a certificate mismatch
Previous Next
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.
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):
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):
[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):
[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):
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):
[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):
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):
[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):
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):
[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):
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):
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):
[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.