Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 18 May 2022 13:57:19 -0700
On Wed, May 18, 2022 at 08:05:41PM +0200, TheAssassin via curl-library wrote:
> The issue I am facing with this is that apparently, libcurl just hardcodes
> the path to the CA certificate bundle (e.g., the system-provided bundle).
> This behavior is problematic. An AppImage built on CentOS 7 using libcurl
> may expect the bundle to be in /etc/pki/tls/certs/ca-bundle.crt, however on
> Ubuntu we would have to look into /etc/ssl/certs/ca-certificates.crt.
> libcurl cannot load the bundle, and therefore the certificate validation
> fails.
curl searches for an appropriate CA bundle at compile time and hard-codes the
one it finds. This usually works fine, as curl shipped on CentOS 7 will have
the right value for that OS, while curl shipped on OS X will have the right
value for that. But, as you point out, this doesn't work well for a portable
binary. In that case, the application can search for an appropriate bundle
itself using whatever means it feels necessary and set it at run-time using
CURLOPT_CAPATH, CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB.
> To use the system bundle, I would like to propose the introduction of a CA
> certificate bundle "search path", which is just a set of potential paths
> libcurl can check one after another. libcurl could then just use the first
> path in the list which exists as a file on the system.
This sounds like it would become a source of problems, since the same
application running on exactly the same OS would have different behaviour
depending on whether a user-specified file is available in a magic location or
not. There are security implications in setting up such a path.
> I'm sure this is not the first
> time someone wants to use libcurl in portable, relocatable application
> bundles, but have not find a solution upstream yet.
I don't remember hearing this as a feature request before, and curl is getting
pretty old. I guess this is because other cross-platform environments (e.g.,
Flatpak, Snap, Docker, or using the system libcurl) solve the problem
differently. AppImage is probably in the minority here in wanting this. It
should be solvable without patching libcurl, though, using the method above.
> As a reference, this is the current search path in the patched libcurl
> (carefully curated, collected for years, still most likely incomplete):
>
> /etc/ssl/ca-bundle.pem
> /etc/ssl/certs/ca-certificates.crt
> /etc/ssl/cert.pem
> /etc/pki/tls/certs/ca-bundle.crt
> /etc/pki/tls/cert.pem
> /etc/pki/tls/cacert.pem
> /usr/local/share/certs/ca-root-nss.crt
The CURL_CHECK_CA_BUNDLE macro takes care of this in curl, It includes a few
locations not in your list, like /etc/ssl/certs/ (CA path on SUSE),
/usr/local/share/certs/ca-root-nss.crt (FreeBSD, MidnightBSD, so probably not
relevant to AppImage), /usr/share/ssl/certs/ca-bundle.crt (old Redhat) and
/usr/share/curl/curl-ca-bundle.crt (obsolete curl-specific bundle).
Dan
Date: Wed, 18 May 2022 13:57:19 -0700
On Wed, May 18, 2022 at 08:05:41PM +0200, TheAssassin via curl-library wrote:
> The issue I am facing with this is that apparently, libcurl just hardcodes
> the path to the CA certificate bundle (e.g., the system-provided bundle).
> This behavior is problematic. An AppImage built on CentOS 7 using libcurl
> may expect the bundle to be in /etc/pki/tls/certs/ca-bundle.crt, however on
> Ubuntu we would have to look into /etc/ssl/certs/ca-certificates.crt.
> libcurl cannot load the bundle, and therefore the certificate validation
> fails.
curl searches for an appropriate CA bundle at compile time and hard-codes the
one it finds. This usually works fine, as curl shipped on CentOS 7 will have
the right value for that OS, while curl shipped on OS X will have the right
value for that. But, as you point out, this doesn't work well for a portable
binary. In that case, the application can search for an appropriate bundle
itself using whatever means it feels necessary and set it at run-time using
CURLOPT_CAPATH, CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB.
> To use the system bundle, I would like to propose the introduction of a CA
> certificate bundle "search path", which is just a set of potential paths
> libcurl can check one after another. libcurl could then just use the first
> path in the list which exists as a file on the system.
This sounds like it would become a source of problems, since the same
application running on exactly the same OS would have different behaviour
depending on whether a user-specified file is available in a magic location or
not. There are security implications in setting up such a path.
> I'm sure this is not the first
> time someone wants to use libcurl in portable, relocatable application
> bundles, but have not find a solution upstream yet.
I don't remember hearing this as a feature request before, and curl is getting
pretty old. I guess this is because other cross-platform environments (e.g.,
Flatpak, Snap, Docker, or using the system libcurl) solve the problem
differently. AppImage is probably in the minority here in wanting this. It
should be solvable without patching libcurl, though, using the method above.
> As a reference, this is the current search path in the patched libcurl
> (carefully curated, collected for years, still most likely incomplete):
>
> /etc/ssl/ca-bundle.pem
> /etc/ssl/certs/ca-certificates.crt
> /etc/ssl/cert.pem
> /etc/pki/tls/certs/ca-bundle.crt
> /etc/pki/tls/cert.pem
> /etc/pki/tls/cacert.pem
> /usr/local/share/certs/ca-root-nss.crt
The CURL_CHECK_CA_BUNDLE macro takes care of this in curl, It includes a few
locations not in your list, like /etc/ssl/certs/ (CA path on SUSE),
/usr/local/share/certs/ca-root-nss.crt (FreeBSD, MidnightBSD, so probably not
relevant to AppImage), /usr/share/ssl/certs/ca-bundle.crt (old Redhat) and
/usr/share/curl/curl-ca-bundle.crt (obsolete curl-specific bundle).
Dan
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-05-18