bug#45358: bootstrap fails due to a certificate mismatch
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
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
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
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
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
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
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
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
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
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