CODEWITHSUNDEEP
curlchroot
Rich Remer
Rich Remer

Reputation: 2603

running curl in chroot

I'm trying to build some minimal container images (based on portablectl from systemd-container, which essentially uses chroot for containerization). I'm running into a problem with some programs not being able to make HTTPS requests. The simplest example to demonstrate is curl, and I imagine fixing curl will fix the other apps. The disconnect appears to be related to curl finding the root certs or CA bundle.

The following command:

sudo chroot /etc/portables/network /usr/bin/curl -Huser-agent:example/1.0 https://www.google.com/search?q=foo

...results in:

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

The curl binary was "installed" to the chroot using Ubuntu's package tools, and I've copied the Ubuntu root certificates from /etc/ssl/certs/ca-certificates.crt in my host environment to the chroot.

This is essentially what I run to install curl and a few other network related tools (and lib dependencies) to the chroot:

apt-get -y install --reinstall \
    bind9-host ca-certificates curl dnsutils \
    iputils-ping \
    libasn1-8-heimdal \
    libbind9-161 libbsd0 libc6 libcap2 libcom-err2 libdns1104 libffi6 \
    libgcc1 \
    libgcrypt20 libgmp10 libgnutls30 libgpg-error0 \
    libgssapi-krb5-2 libgssapi3-heimdal \
    libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal \
    libhogweed4 libhx509-5-heimdal \
    libicu63 libidn2-0 \
    libirs161 \
    libisc1100 libisccfg163 \
    libjson-c4 libkeyutils1 libk5crypto3 libkrb5-3 libkrb5-26-heimdal \
    libkrb5support0 \
    libldap-2.4-2 libldap-common liblwres161 liblzma5 libnettle6 \
    libnghttp2-14 libp11-kit0 \
    libpsl5 libroken18-heimdal librtmp1 \
    libsasl2-2 libsqlite3-0 libssh-4 libssl1.1 \
    libstdc++6 \
    libtasn1-6 libunistring2 libwind0-heimdal libxml2 \
    netcat-openbsd zlib1g
echo nameserver 127.0.0.53 >> /etc/resolv.conf
echo options edns0 >> /etc/resolv.conf

Using the curl -k option works as expected; it ignores the cert mis-configuration and successfully makes the HTTPS request.

In addition, if I explicitly set --cafile /etc/ssl/certs/ca-certificates.crt, it works fine.

But if I run curl -v, I see the following:

*   Trying 2607:f8b0:4007:80c::2004:443...
* TCP_NODELAY set
* Connected to www.google.com (2607:f8b0:4007:80c::2004) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate

So you can see it's got CApath /etc/ssl/certs, but an empty CAfile.

Upvotes: 1

Views: 1050

Answers (1)

Rich Remer
Rich Remer

Reputation: 2603

The issue appears to be that "if curl is built against OpenSSL, the directory must have been processed using the c_rehash utility supplied with OpenSSL" (curl manpage)

Essentially, with this curl build, the ca-certificates.crt bundle isn't used unless it's explicitly requested with --cafile (or cafile= in .curlrc). Instead, it's looking for a specific directory layout with hashed symlinks pointing at the target files.

So, the fix is to split up the ca-certificates.crt bundle into multiple files, then run:

ca_rehash /etc/ssl/certs

Upvotes: 0

Related Questions