cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: Default ca cert bundle

From: Doug Kaufman <dkaufman_at_rahul.net>
Date: Sun, 6 Jul 2003 11:36:42 -0700 (PDT)

On Sun, 6 Jul 2003, Daniel Stenberg wrote:

> > I am not sure I understand the history or design considerations in having a
> > ca cert bundle default that is separate from that specified in OpenSSL.
>
> AFAIK, there is none in the OpenSSL package and thus this wasn't a tricky
> decision. There simply is no "standard" ca cert bundle path so we made our
> own.

It is true that a ca cert bundle isn't distributed with OpenSSL.
This is by design, since the OpenSSL team felt that the certs should
be obtained from a trusted source. No one there wanted to take the
responsibility of distributing ca certs for general use.
  
> You can also tell the configure script to use a different one, if the curl one
> isn't good for you.

That is a good feature of curl.

> > OpenSSL calls its default ca cert bundle "cert.pem" and puts it in the
> > OpenSSL directory (but configurable when you create libcrypto).
>
> I don't have such a file and I have 0.9.7a installed. I guess I would need
> some additional configure paramaters or something when I built OpenSSL.

OpenSSL doesn't install the file, or even have it as part of its
distribution. It just has a default location for it. It is up to
whoever installs OpenSSL on the system to obtain and install their
own trusted ca cert bundle. I extracted mine as a pkcs7 file from
Microsoft's Internet Explorer, then generated a certificate file with
openssl pkcs7.

> > It provides the environment variable "SSL_CERT_FILE" to override this at run
> > time. Similar measures exist for a hashed cert directory (SSL_CERT_DIR).
> > There are functions such as "X509_get_default_cert_file" and
> > "X509_get_default_cert_file_env", with the module usually handling this in
> > crypto/x509/by_file.c. Similar functions for the hashed cert directory are
> > in by_dir.c Curl seems to ignore these and uses a default ca cert bundle
> > called "curl-ca-bundle.crt" put in /usr/share/curl and overrides this at run
> > time with "CURL_CA_BUNDLE".
>
> Yes, because all of this OpenSSL magic you explain here is news to me. You are
> the first person who brings this up.

Unfortunately, the information about this is not in the current
OpenSSL documentation. You have to read the source code or
see discussion about it in the openssl-dev mailing list.
There is a reference to the X509_get_default_cert_file and
X509_get_default_cert_file_env in the obsolete ssleay.txt file in
the OpenSSL document directory, but that is about it. The only
references that I know to the SSL_CERT_FILE and SSL_CERT_DIR
environment variables (other than in the source code itself) are
in the old "SSLeay and SSLapps FAQ" which is not distributed with
OpenSSL (available at http://www2.psy.uq.edu.au/~ftp/Crypto/").
See some correspondence about these defaults in the openssl-dev
mailing list in a thread started by me in December 2002
(with a fix for the code by Richard Levitte and Rich Salz):
"http://marc.theaimsgroup.com/?l=openssl-dev&m=103899056011520"

The default name for the ca cert bundle is defined in
crypto/cryptlib.h, as are the environment variables SSL_CERT_FILE and
SSL_CERT_DIR.
  
> > Using the defaults could lead unintentionally to two different ca cert
> > bundles on the system, which might not be updated together (unless one was
> > just a link to the other).
>
> Yes, but how many people do actually have a ca cert bundle in the OpenSSL dir?

Apparently many didn't. The lynx browser had been using https
without actually checking certificates against a file of trusted
ca certificates. When the lynx code was fixed to actually do the
checking, complaints started coming in about all the error messages
that were generated. We had to explain that the fix was to install
a ca cert bundle in the OpenSSL default location. See the OpenSSL
function "SSL_CTX_set_default_verify_paths" from ssl/ssl_lib.c.
If you want to see what lynx did, look in recent lynx source at
www/Library/Implementation/HTTP.c.

> > I was curious as to why curl chose this route.
>
> Because it has been unknown to me and the others who helped me make curl
> behave like this.

Thanks for the clarification.It certainly would be nice if OpenSSL
documentation were better.

                             Doug

-- 
Doug Kaufman
Internet: dkaufman_at_rahul.net
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Received on 2003-07-06