bug#45358: bootstrap fails due to a certificate mismatch

2021-03-10 Thread Grigoriy Sokolik
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  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  'Connecting|Status'
> > Connecting to '80.69.83.146:443'...
> > - Status: The certificate is trusted.
> > # via IPv6
> > $ gnutls-cli --verbose translationproject.org  '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
>


bug#45358: bootstrap fails due to a certificate mismatch

2021-03-09 Thread Bob Proulx
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  'Connecting|Status'
> Connecting to '80.69.83.146:443'...
> - Status: The certificate is trusted. 
> # via IPv6
> $ gnutls-cli --verbose translationproject.org  '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





bug#45358: bootstrap fails due to a certificate mismatch

2021-03-09 Thread Erik Auerswald
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  [...]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





bug#45358: bootstrap fails due to a certificate mismatch

2021-03-09 Thread 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  | 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  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
> ...
> 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  | sed -n '/^-BEGIN
> CERTIFICATE-/,/^-END CERTIFICATE-/p' > /tmp/
> translationproject.org.certs
> $ certtool --verbose --verify-profile=high --verify
> --infile=/tmp/translationproject.org.certs
> Lo

bug#45358: bootstrap fails due to a certificate mismatch

2021-03-08 Thread Bob Proulx
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
...
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  | 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 | 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

2021-02-17 Thread Grigoriy Sokolik
The thing is that translationproject returns the wrong certificate.

Thanks!
Best regards,
Grigorii


On Tue, 16 Feb 2021 at 19:28, Paul Eggert  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).
>


bug#45358: bootstrap fails due to a certificate mismatch

2021-02-16 Thread Paul Eggert

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).






bug#45358: bootstrap fails due to a certificate mismatch

2021-02-15 Thread Grigoriy Sokolik
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


bug#45358: bootstrap fails due to a certificate mismatch

2021-02-13 Thread Grigoriy Sokolik
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   TimeTime Time
Current
Dload  Upload   Total   SpentLeft
Speed
 0 00 00 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  88810  88810 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:

bug#45358: bootstrap fails due to a certificate mismatch

2020-12-21 Thread j-james
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