Re: [lmi] debian chroot in redhat

[Vadim Zeitlin]

On Wed, 2 Oct 2019 22:08:53 +0000 Greg Chicares <address@hidden> wrote:

GC> Please help--I'm stuck.
GC> 
GC> What I've done so far is here:
GC>   https://git.savannah.nongnu.org/cgit/lmi.git/tree/install_centos.sh
GC> which gives me a working centos chroot, closely following your
GC> instructions here:
GC>   http://www.tt-solutions.com/en/articles/install_centos_in_debian_chroot
GC> except that I'm using centos-7.7 instead of 7.6 because the handful of
GC> US mirrors I checked don't offer 7.6 .
GC> 
GC> After running that script as root on my debian-10.1 base system, I log in
GC> and install curl and ca-certificates:
GC> 
GC> #schroot --chroot=centos7 --user=root --directory=/tmp
GC> [root@ugolyok]/tmp# yum --assumeyes install ca-certificates curl
GC> ...
GC> Installed:
GC>   ca-certificates.noarch 0:2018.2.22-70.0.el7_5             curl.x86_64 
0:7.29.0-54.el7            
GC> ...
GC> Complete!
GC> 
GC> But now I observe this failure on the command to install EPEL:
GC> 
GC> [root@ugolyok]/tmp# rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
GC> Retrieving 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
GC> curl: (77) Problem with the SSL CA cert (path? access rights?)
GC> error: skipping 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - 
transfer failed

 This is very strange. I've just retried from my CentOS 7.6 chroot and it
worked just fine. With --verbose option I get (among other output) the
following:

        % curl -v 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm 
>|/dev/null
        * About to connect() to dl.fedoraproject.org port 443 (#0)
        *   Trying 209.132.181.23...
        * Connected to dl.fedoraproject.org (209.132.181.23) port 443 (#0)
        * Initializing NSS with certpath: sql:/etc/pki/nssdb
        *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
          CApath: none
        * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        * Server certificate:
        *       subject: CN=*.fedoraproject.org,O=Red Hat 
Inc.,L=Raleigh,ST=North Carolina,C=US
        *       start date: Feb 01 00:00:00 2017 GMT
        *       expire date: May 01 12:00:00 2020 GMT
        *       common name: *.fedoraproject.org
        *       issuer: CN=DigiCert SHA2 High Assurance Server 
CA,OU=www.digicert.com,O=DigiCert Inc,C=US

 And the certificate is indeed present in the system certificate bundle:

        % fgrep -A2 'DigiCert High Assurance' /etc/pki/tls/certs/ca-bundle.crt
        # DigiCert High Assurance EV Root CA
        -----BEGIN CERTIFICATE-----
        MIIDxTCCAq2gAwIBAgIQAqxcJmoLQJuPC3nyrkYldzANBgkqhkiG9w0BAQUFADBs

 Could they really remove it in 7.7? This seems very unlikely, it's the
only explanation I see right now. Could you please check if it's still
there?

 Another possible explanation is that you are using some HTTP proxy doing
something strange (i.e. bad) with the certificate. In this "curl -v" should
tell you something different. And you could always use openssl to show even
more details. Here is what it shows here, if you'd like to compare your
output:

        % echo | openssl s_client -showcerts -connect dl.fedoraproject.org:443
        CONNECTED(00000003)
        depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert 
High Assurance EV Root CA
        verify return:1
        depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert 
SHA2 High Assurance Server CA
        verify return:1
        depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat Inc., CN 
= *.fedoraproject.org
        verify return:1
        ---
        Certificate chain
         0 s:C = US, ST = North Carolina, L = Raleigh, O = Red Hat Inc., CN = 
*.fedoraproject.org
           i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert 
SHA2 High Assurance Server CA
        -----BEGIN CERTIFICATE-----
        MIIGaDCCBVCgAwIBAgIQBgAdcIAphhlAa5cCvBVVJTANBgkqhkiG9w0BAQsFADBw
        ...snip...
        DWfhteUyLpUczjDE
        -----END CERTIFICATE-----
         1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert 
SHA2 High Assurance Server CA
           i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert 
High Assurance EV Root CA
        -----BEGIN CERTIFICATE-----
        MIIEsTCCA5mgAwIBAgIQBOHnpNxc8vNtwCtCuF0VnzANBgkqhkiG9w0BAQsFADBs
        ...snip...
        cPUeybQ=
        -----END CERTIFICATE-----
        ---
        Server certificate
        subject=C = US, ST = North Carolina, L = Raleigh, O = Red Hat Inc., CN 
= *.fedoraproject.org

        issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert 
SHA2 High Assurance Server CA

        ---
        No client certificate CA names sent
        Peer signing digest: SHA512
        Peer signature type: RSA
        Server Temp Key: ECDH, P-256, 256 bits
        ---
        SSL handshake has read 3814 bytes and written 444 bytes
        Verification: OK
        ---
        New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
        Server public key is 4096 bit
        Secure Renegotiation IS supported
        Compression: NONE
        Expansion: NONE
        No ALPN negotiated
        SSL-Session:
            Protocol  : TLSv1.2
            Cipher    : ECDHE-RSA-AES128-GCM-SHA256
            Session-ID: 
2A9616B36885DEF70DB90D675983EADBC811D6F8BAB04A601E79A030BCE75CB4
            Session-ID-ctx:
            Master-Key: 
2AD7E27D0909CDB679BA5AF233AF02008F9921C83AA4906CBEEFB61A38356B73ABBEA5B52CADBB60C1CE68CEEE332F72
            PSK identity: None
            PSK identity hint: None
            SRP username: None
            TLS session ticket lifetime hint: 7200 (seconds)
            TLS session ticket:
            0000 - 06 33 14 9d 9c fd 19 70-a7 60 dd df 31 ef 34 bc   
.3.....p.`..1.4.
            0010 - 24 bc 2a ac 7d 27 5e 38-04 ab 88 58 ea d2 4c e2   
$.*.}'^8...X..L.
            0020 - d6 be 51 3f 9f 79 ea 44-9d 3d 62 01 d1 60 ce 6f   
..Q?.y.D.=b..`.o
            0030 - b2 80 7f 41 b0 60 f7 c7-4a 7c 9f 2f 6d 6e a8 9a   
...A.`..J|./mn..
            0040 - 24 b6 b3 61 3b cd c3 ba-a0 4b 34 3b d3 95 9e 07   
$..a;....K4;....
            0050 - 69 1b 17 18 36 9d 4a 60-48 1f 58 88 6d 7f 95 af   
i...6.J`H.X.m...
            0060 - f6 94 df 18 32 6d 8c 22-c7 e1 64 8d 1e 8d f6 a3   
....2m."..d.....
            0070 - a1 5d f3 d1 8e 1a 07 89-43 7c 93 aa 66 36 14 e6   
.]......C|..f6..
            0080 - 47 35 ae bb 7d c2 52 f0-54 05 36 b0 83 ea fb e0   
G5..}.R.T.6.....
            0090 - 6a 11 4a cb 32 99 d9 f5-25 ee ed fe 20 20 7e 61   
j.J.2...%...  ~a
            00a0 - d8 ec 34 74 ed 31 d1 04-d3 4b 3d cb e4 5f e6 b0   
..4t.1...K=.._..
            00b0 - 6b de 1d ec 41 47 7c d1-66 27 51 75 ed 5b 7d 53   
k...AG|.f'Qu.[}S
            00c0 - 0e ad 1c 68 e5 37 39 e9-14 94 46 d3 13 51 09 59   
...h.79...F..Q.Y

            Start Time: 1570058931
            Timeout   : 7200 (sec)
            Verify return code: 0 (ok)
            Extended master secret: no
        ---
        DONE

GC> I wasn't sure whether I needed to be in an 'scl enable' shell,

 No, this is definitely irrelevant here.

GC> I tried the following suggestions:
GC> 
GC> # 
https://stackoverflow.com/questions/27987091/ssl-ca-cert-path-access-rights
GC> # doesn't help:
GC> rm -f /etc/ssl/certs/ca-bundle.crt && yum reinstall -y ca-certificates

 BTW, /etc/ssl/certs is just a symlink to /etc/pki/tls/certs, which
explains why a different certificate store is shown above.

GC> Any other ideas?

 Well, you could use "curl --insecure" to download the package and then
"rpm -i" to install it (I don't know how to pass extra curl options
directly via rpm, or even if it's possible at all). But this shouldn't be
necessary, of course...

 Sorry but I don't have any other ideas,
VZ

pgp6eMmd0YxEA.pgp
Description: PGP signature