On 01/12/2018 05:54 PM, [email protected] wrote:
Hi,
I do have a TLS certificate issue in BLFS, maybe someone can enlighten
me what's happening here:
<snip>
Adding the actual root certificate of dev-static.rust-lang.org to
/etc/ssl/certs (i.e. the one without additional Trusted Uses) makes curl
and therefore rustc happy.
Please undo this and see below.
What am I missing? Who added that trust? Why is the one without trust
needed instead? What would be in charge of ignoring the trust? Is
anybody else seeing this?
In order...
Your curl was built against Gnutls for the TLS provider but wasn't
configured to use it (pass --with-ca-bundle=/etc/ssl/ca-bundle.crt to
configure).
Mozilla selected the trust bits. Take a look over the ca-certificates
page to understand how and why. I did put some effort into making that
page understandable. If I've failed in that endeavor, I'd like to know
how to make it better.
See the answer to the first question.
Nope! :-) Gnutls's OpenSSL compatibility is incomplete and cannot use
the OpenSSL trusted certificates in /etc/ssl/certs, though it can
_probably_ use PCKS#11 via P11-kit to support out of band trust (but I
have no idea host to configure it).
Most prefer OpenSSL for the TLS provider for curl. However, if there is
some aversion to OpenSSL (licensing, security, other), there is NSS or
Libre-SSL (or any of like 9 providers, and possibly using Gnutls with
P11-kit). Alternately, very few people ever use curl as an alternate
client, or really for anything more than downloading files, so you might
get away without a rebuild by adding "cacert=/etc/ssl/ca-bundle.crt" to
your ~/.curlrc.
HTH
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
