Skip Menu |
 
Ticket metadata
The Basics
Id: 2936
Status: resolved
Priority: 0/
Queue: OpenSSL-Bugs

Custom Fields
Milestone: (no value)
Subsystem: (no value)
Severity: (no value)
Broken in: (no value)

People
Owner: Nobody in particular
Requestors: Christoph Garst
Ludwig Nussel
Martin von Gagern
Paul.Tedaldi@id.unizh.ch
Reuben Thomas
Tomas Mraz
Cc:
AdminCc:

More about the requestors

Christoph Garst

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Unprivileged
  • Everyone

Ludwig Nussel

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Unprivileged
  • Everyone

Martin von Gagern

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Unprivileged
  • Everyone

Paul.Tedaldi@id.unizh.ch

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Unprivileged
  • Everyone

Reuben Thomas

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Unprivileged
  • Everyone

Tomas Mraz

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Unprivileged
  • Everyone

New reminder:
Subject:
Owner:
Due:

Dates
Created: Sun Dec 09 19:48:28 2012
Starts: Not set
Started: Fri Aug 15 18:29:25 2014
Last Contact: Fri Aug 15 18:29:25 2014
Due: Not set
Closed: Fri Aug 15 18:29:25 2014
Updated: Fri Aug 15 20:57:18 2014 by Rich Salz



Date: Mon, 22 Nov 2004 11:37:18 +0100 (MET)
From: Paul.Tedaldi@id.unizh.ch
To: openssl-bugs@openssl.org
Subject: openssl s_client not follow default CApath
Download (untitled) / with headers
text/plain 1.3k
Our server presents a certificate signed by a self-signed CA certificate.
The self-signed CA certificate is stored in /usr/local/ssl/certs
together with verisign etc. and c_rehash done.

openssl s_client -connect host:port
does not even try to find the CA certificate in the default CApath
(usually /usr/local/ssl/certs).

You can verify this (on a Linux system) by

truss openssl s_client -connect host:port

The truss trace shows you that s_client doesnt try to find a file cert.pem
nor the hash link to the CA certificate.

truss openssl s_client -connect host:port -CApath /dev/null
shows you that now s_client does try to find cert.pem and the hash link,
first without success in /dev/null and than in the default path
(/usr/local/ssl/certs). You may replace /dev/null by any empty directory.

I feel that calling s_client without specifying -CApath should
automatically search the default path.

Kind regards
Paul

========================================================================
Paul Tedaldi |
Informatikdienste | Email: Paul.Tedaldi@id.unizh.ch
Universitaet Zuerich |
Winterthurerstr. 190 | Tel: +41 (0)44 635 4523
CH-8057 Zuerich | Fax: +41 (0)44 635 4505
Switzerland |
========================================================================
Subject: Bug report: default CA certs file path ignored
Date: Wed, 12 Dec 2007 15:25:43 +0100
To: rt@openssl.org
From: Tomas Mraz <tmraz@redhat.com>
Download (untitled) / with headers
text/plain 1.1k
The default CA certs file path is ignored in commands like s_client
because if you don't specify -CApath or -CAfile on s_client command line
the SSL_CTX_load_verify_locations() will return 0 and the code:

if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
(!SSL_CTX_set_default_verify_paths(ctx)))
will skip the SSL_CTX_set_default_verify_paths() call.

There are two possible ways how to fix this problem - either do not call
SSL_CTX_load_verify_locations() when CAfile and CApath are both NULL. Or
fix the code of X509_STORE_load_locations() to not to return 0 when both
path and file are NULL.

The X509_STORE_load_locations() implementation is debatable in more ways
because it will return with 0 immediately when the file lookup load
fails and so it will not attempt to add the dir lookup at all in this
case. In my opinion it should at least try both (of course returning
failure if any load fails).

See also https://bugzilla.redhat.com/show_bug.cgi?id=421011

--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
Subject: Re: [openssl.org #1623] Bug report: default CA certs file path ignored
Date: Wed, 12 Dec 2007 22:45:00 +0100
To: rt@openssl.org
From: Tomas Mraz <tmraz@redhat.com>
Download (untitled) / with headers
text/plain 411b
On Wed, 2007-12-12 at 20:11 +0100, Tomas Mraz via RT wrote:
Show quoted text
> The default CA certs file path is ignored in commands like s_client
...
Show quoted text
> See also https://bugzilla.redhat.com/show_bug.cgi?id=421011

Oops, should have been
https://bugzilla.redhat.com/show_bug.cgi?id=418771
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
Subject: RFE: disable default verify paths in s_client
Date: Wed, 12 Aug 2009 11:56:48 +0200
To: rt@openssl.org
From: Martin von Gagern <Martin.vGagern@gmx.net>
Download (untitled) / with headers
text/plain 2.5k
Type of request: enhancement request
Operating system: tested on Linux, probably affects all
Version of OpenSSL: tested on 0.9.8k, seen in current CVS as well

Problem:
openssl s_client is a useful tool to debug many kinds of certificate
issues. When it comes to chain verification, however, the fact that it
unconditionally sets default verify paths can lead to confusion and
wrong conclusions.

Example:
suppose you want to ensure that the https cert of server can be
validated against /etc/ssl/certs/some.ca.pem. You might try to do this:

openssl s_client -verify 5 -CAfile some.ca.pem -connect server:443

Judging from the line "Verify return code: 0 (ok)" you might assume that
the certificate had been verified against some.ca.pem. That is not
necessarily the case, though: it might well be that there was some
/etc/ssl/certs/other.ca.pem used as the root, and that /etc/ssl/certs/
is configured as the default cert dir, either at compile time or through
the SSL_CERT_DIR environment variable.

Workaround:
one can set the environment variables SSL_CERT_FILE and SSL_CERT_DIR to
e.g. /dev/null to avoid this problem. This will disable default paths,
and not cause any errors.
The man pages do not mention those environment variables in any way, so
one has to look at the source or search the web to learn about them.

Request:
I suggest you introduce a command line switch, e.g. called -CAnodefault,
which disables the loading of these default paths. This would give users
an easy way to disable loading these defaults. And the presence of such
a flag would be a good indication that there are defaults. Unless users
make use of this switch, the behaviour of s_client would stay as it
alwasy was.

I would also consider a more radical idea: when either -CApath or
-CAfile is given, don't load the defaults at all. The rationale here is
that the user specified the CA locations because he expects the certs to
verify against those. So it's that expectation that should be verified,
and no other trust roots should interfere.
This approach would avoid adding an option at the cost of changing
behaviour. If that's acceptable, I'd prefer this approach.

The core of the modification would likely center around these lines in
s_client.c:

if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
(!SSL_CTX_set_default_verify_paths(ctx)))

Cross reference:
The missing documentation for the SSL_CERT_FILE and SSL_CERT_DIR
environment variables was already mentioned in 2005 by request #1051:
http://rt.openssl.org/Ticket/Display.html?id=1051&user=guest&pass=guest
Especially the s_client man page should mention those variables, I think.
CC: Ludwig Nussel <ludwig.nussel@suse.de>
Subject: [PATCH] fix fallback to default verify paths
Date: Thu, 25 Mar 2010 16:46:10 +0100
To: rt@openssl.org
From: Ludwig Nussel <ludwig.nussel@suse.de>
Download (untitled) / with headers
text/plain 899b
---
apps/s_client.c | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/apps/s_client.c b/apps/s_client.c
index 484d009..3f57a5d 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -904,12 +904,19 @@ bad:
if (!set_cert_key_stuff(ctx,cert,key))
goto end;

- if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
- (!SSL_CTX_set_default_verify_paths(ctx)))
+ if (CAfile || CApath)
{
- /* BIO_printf(bio_err,"error setting default verify locations\n"); */
- ERR_print_errors(bio_err);
- /* goto end; */
+ if (!SSL_CTX_load_verify_locations(ctx,CAfile,CApath))
+ {
+ BIO_printf(bio_err,"error setting verify locations\n");
+ ERR_print_errors(bio_err);
+ goto end;
+ }
+ }
+ else
+ {
+ BIO_printf(bio_c_out,"using default CA certificates\n");
+ SSL_CTX_set_default_verify_paths(ctx);
}

#ifndef OPENSSL_NO_TLSEXT
--
1.6.4.2
Subject: [PATCH] wrong handling of CAfile/CApath in s_client
Date: Fri, 3 Dec 2010 01:44:03 -0800
To: <openssl-bugs@openssl.org>
From: "Christoph Garst" <cgarst@astaro.com>
Download s_client.diff
application/octet-stream 528b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 785b
Calling s_client with -CAfile or -CApath additionally loads CA certificates from default location.

Otherwise if calling s_client without those parameters, no CA certificates are loaded at all (should then load default certificates instead).



--

Christoph Garst | cgarst@astaro.com | Software Engineer

Astaro GmbH & Co. KG | www.astaro.com | Phone +49-721-25516-0 | Fax -200

An der RaumFabrik 33a | 76227 Karlsruhe | Germany



Astaro GmbH & Co. KG

Commercial Register: Mannheim HRA 702710

Headquarter Location: Karlsruhe



Represented by the General Partner Astaro Verwaltungs GmbH

Commercial Register: Mannheim HRB 708248

An der RaumFabrik 33a | 76227 Karlsruhe | Germany

Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen


Subject: [openssl.org #977] openssl s_client not follow default CApath
Date: Wed, 28 Dec 2011 16:11:25 -0500
To: rt@openssl.org
From: Helmut Tessarek <helmut@evermeet.cx>
Download (untitled) / with headers
text/plain 353b
Hello,

The problem described in ticket 977 still exists:
http://rt.openssl.org/Ticket/Display.html?id=977&user=guest&pass=guest

'openssl s_client' also does not seem to read the entries in the openssl.cnf
to find the ssl ca file or path.

'openssl s_client' only looks for the hardcoded file /usr/local/ssl/cert.pem,
no matter what.

Regards,
Helmut
Subject: Properly set default trusted CA paths if -CAfile and -CApath not used
Date: Fri, 07 Dec 2012 16:17:52 +0100
To: rt@openssl.org
From: Tomas Mraz <tmraz@redhat.com>
Download (untitled) / with headers
text/plain 505b
The current behavior of s_client, s_server and s_time commands in
regards to the default trusted CA store path is incorrect. The default
paths are loaded only in case SSL_CTX_load_verify_locations() does not
fail. This means that you have to use -CApath or -CAfile
The attached patch properly sets the default paths only if neither
-CApath nor -CAfile is specified.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb

Message body is not shown because sender requested not to inline it.

Subject: [PATCH] Fix failure to read default CA file & CA path in s_{client,server,time} (bug #977)
Date: Sun, 5 Jan 2014 22:55:30 -0000
To: rt@openssl.org
From: Reuben Thomas <rrt@sc3d.org>
Download (untitled) / with headers
text/plain 6.7k
This is a patch for bug #977. Since this is the first time I've
attempted to contribute to OpenSSL, I lay out the problem, underlying
bug and fix in some detail below. Apologies if I labor the obvious.


The symptoms:

s_client and some other apps can fail to verify certificates when they
should have no problem, e.g.:

$ openssl s_client -connect www.google.com:443|grep "Verify return"
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
Verify return code: 20 (unable to get local issuer certificate)

This is surprising, as I'm using the stock openssl (1.0.1e) that comes
with my Ubuntu 13.10 system.

If I download the certificate and run openssl verify, I get the
expected result:

$ openssl verify google.pem
google.pem: OK

If I explicitly point openssl at the system’s certificate store, I
also get the expected result:

$ openssl s_client -CApath /etc/ssl/certs -connect www.google.com:443|grep "Verify return"
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
verify return:1
Verify return code: 0 (ok)

But that's the default path, so why didn't it work before? Also, I can
get the same result by supplying a bogus path:

$ openssl s_client -CApath /no/such/path -connect www.google.com:443|grep "Verify return"
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
verify return:1
Verify return code: 0 (ok)

Oops.


The bug:

s_client.c, s_server.c and s_time.c contain the following stanza,
which starts in s_client.c at line 1397 (current git as of this
writing):

if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
(!SSL_CTX_set_default_verify_paths(ctx)))
{
/* BIO_printf(bio_err,"error setting default verify locations\n"); */
ERR_print_errors(bio_err);
/* goto end; */
}

The intended logic of the if is that first, we try to load any
certificate locations given on the command line, and then, if that
fails, we load the defaults.

SSL_CTX_load_verify_locations returns 0 for failure and 1 for success.
When both CAfile and CApath are NULL, it fails (returns 0). This
causes the shortcut || operator to succeed, and
SSL_CTX_set_default_verify_paths is not run.

When a correct path or bogus path is supplied,
SSL_CTX_load_verify_locations returns 1 for success (it doesn't mind
in the latter case that the directory does not exist, it merely
retrieves no data from it). Therefore, the right-hand side of the ||
is evaluated, and the default certificate path is set.


The fix

The fix is to change || in the above code to &&. Then, the
command-line parameters are used to set the certificate path, and if
that fails, the defaults are used instead. This then gives the
expected result (for brevity, I won't repeat the terminal logs here):
supplying no argument or the default directory explicitly causes
verification to succeed, whereas supplying a bogus path causes it to
fail.


The patch

There follows a patch which makes this fix in each of s_client.c,
s_server.c and s_time.c. The patch is against git at the time of
writing. It also makes a similar fix to two other files, mttest.c and
ssltest.c, which suffer from a similar problem.

Show quoted text
>From e5015769d02202dbd1ef0e32386ceba844def059 Mon Sep 17 00:00:00 2001
From: Reuben Thomas <rrt@sc3d.org>
Date: Sun, 5 Jan 2014 22:54:44 +0000
Subject: [PATCH] Fix bug #977 (accidentally reversed logic)

---
apps/s_client.c | 2 +-
apps/s_server.c | 2 +-
apps/s_time.c | 2 +-
crypto/threads/mttest.c | 8 ++++----
ssl/ssltest.c | 8 ++++----
5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/apps/s_client.c b/apps/s_client.c
index 1e3bc39..383cce0 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -1394,7 +1394,7 @@ bad:

SSL_CTX_set_verify(ctx,verify,verify_callback);

- if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
+ if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) &&
(!SSL_CTX_set_default_verify_paths(ctx)))
{
/* BIO_printf(bio_err,"error setting default verify locations\n"); */
diff --git a/apps/s_server.c b/apps/s_server.c
index 1bac3b4..ecc0249 100644
--- a/apps/s_server.c
+++ b/apps/s_server.c
@@ -1828,7 +1828,7 @@ bad:
}
#endif

- if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
+ if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) &&
(!SSL_CTX_set_default_verify_paths(ctx)))
{
/* BIO_printf(bio_err,"X509_load_verify_locations\n"); */
diff --git a/apps/s_time.c b/apps/s_time.c
index b823c33..fc38c15 100644
--- a/apps/s_time.c
+++ b/apps/s_time.c
@@ -373,7 +373,7 @@ int MAIN(int argc, char **argv)

SSL_load_error_strings();

- if ((!SSL_CTX_load_verify_locations(tm_ctx,CAfile,CApath)) ||
+ if ((!SSL_CTX_load_verify_locations(tm_ctx,CAfile,CApath)) &&
(!SSL_CTX_set_default_verify_paths(tm_ctx)))
{
/* BIO_printf(bio_err,"error setting default verify locations\n"); */
diff --git a/crypto/threads/mttest.c b/crypto/threads/mttest.c
index eba7aa8..3c23bf8 100644
--- a/crypto/threads/mttest.c
+++ b/crypto/threads/mttest.c
@@ -306,10 +306,10 @@ bad:
SSL_FILETYPE_PEM);
}

- if ( (!SSL_CTX_load_verify_locations(s_ctx,CAfile,CApath)) ||
- (!SSL_CTX_set_default_verify_paths(s_ctx)) ||
- (!SSL_CTX_load_verify_locations(c_ctx,CAfile,CApath)) ||
- (!SSL_CTX_set_default_verify_paths(c_ctx)))
+ if ( ((!SSL_CTX_load_verify_locations(s_ctx,CAfile,CApath)) &&
+ (!SSL_CTX_set_default_verify_paths(s_ctx))) ||
+ ((!SSL_CTX_load_verify_locations(c_ctx,CAfile,CApath)) &&
+ (!SSL_CTX_set_default_verify_paths(c_ctx))))
{
fprintf(stderr,"SSL_load_verify_locations\n");
ERR_print_errors(bio_err);
diff --git a/ssl/ssltest.c b/ssl/ssltest.c
index 5e2fed8..6f5eedc 100644
--- a/ssl/ssltest.c
+++ b/ssl/ssltest.c
@@ -1604,10 +1604,10 @@ bad:
SSL_FILETYPE_PEM);
}

- if ( (!SSL_CTX_load_verify_locations(s_ctx,CAfile,CApath)) ||
- (!SSL_CTX_set_default_verify_paths(s_ctx)) ||
- (!SSL_CTX_load_verify_locations(c_ctx,CAfile,CApath)) ||
- (!SSL_CTX_set_default_verify_paths(c_ctx)))
+ if ( ((!SSL_CTX_load_verify_locations(s_ctx,CAfile,CApath)) &&
+ (!SSL_CTX_set_default_verify_paths(s_ctx))) ||
+ ((!SSL_CTX_load_verify_locations(c_ctx,CAfile,CApath)) &&
+ (!SSL_CTX_set_default_verify_paths(c_ctx))))
{
/* fprintf(stderr,"SSL_load_verify_locations\n"); */
ERR_print_errors(bio_err);
--
1.8.3.2

--
http://rrt.sc3d.org/
CC: openssl-dev@openssl.org
Subject: Re: [openssl.org #3213] [PATCH] Fix failure to read default CA file & CA path in s_{client,server,time} (bug #977)
Date: Fri, 10 Jan 2014 06:55:36 +0100
To: Reuben Thomas via RT <rt@openssl.org>
From: Florian Zumbiehl <florz@florz.de>
Download (untitled) / with headers
text/plain 754b
Hi,

Show quoted text
> The fix is to change || in the above code to &&. Then, the
> command-line parameters are used to set the certificate path, and if
> that fails, the defaults are used instead. This then gives the

while the behaviour with your patch is a lot saner than without it, I would
argue that it's still broken, as it exhibits fail-open behaviour:
SSL_CTX_load_verify_locations() probably can fail for reasons other than
!(CAfile||CApath), and it's unlikely that the user meant "this CA, or any
other if loading this one fails for whatever reason".

(Arguably, SSL_CTX_load_verify_locations() is actually broken in that it
returns failure for an empty set of CAs, as it's logically perfectly
consistent to authenticate against a deny-all policy.)

Florian
CC: openssl-dev@openssl.org
Subject: Re: [openssl.org #3213] [PATCH] Fix failure to read default CA file & CA path in s_{client,server,time} (bug #977)
Date: Fri, 10 Jan 2014 14:07:44 +0000
To: rt@openssl.org
From: Reuben Thomas <rrt@sc3d.org>
On 10 January 2014 06:41, Florian Zumbiehl via RT <rt@openssl.org> wrote:

Show quoted text
> Hi,
>
> > The fix is to change || in the above code to &&. Then, the
> > command-line parameters are used to set the certificate path, and if
> > that fails, the defaults are used instead. This then gives the
>
> while the behaviour with your patch is a lot saner than without it, I would
> argue that it's still broken, as it exhibits fail-open behaviour:
> SSL_CTX_load_verify_locations() probably can fail for reasons other than
> !(CAfile||CApath), and it's unlikely that the user meant "this CA, or any
> other if loading this one fails for whatever reason".
>

So in that case it should try only the user's option if the user gave a
-CApath or -CAfile, and otherwise the default option?


Show quoted text
> (Arguably, SSL_CTX_load_verify_locations() is actually broken in that it
> returns failure for an empty set of CAs,


To cope with that, we could have a new function (to be used in place of the
current

if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
(!SSL_CTX_set_default_verify_paths(ctx)))

), which goes something like:

int SSL_CTX_load_verify_locations_or_default(SSL_CTX *ctx, const char
*CAfile, const char *CApath)
{
if (CAfile || CApath)
return SSL_CTX_load_verify_locations(ctx, CAfile, CApath);
return SSL_CTX_set_default_verify_paths(ctx);
}

and the above code can then be replaced by:

if (!SSL_CTX_load_verify_locations_or_default(ctx, CAfile, CApath))


Show quoted text
> as it's logically perfectly
> consistent to authenticate against a deny-all policy.)


Indeed.

The suggestion above has the advantage that it does not require
SSL_CTX_load_verify_locations to be changed (as its behavior of failing
when CApath and CAfile are both NULL is documented). However, if it were
changed, then the code above would still work.

The correct behavior is, as I hope I've made clear, outside my competence
to decide, but I'm quite happy to work up an acceptable patch if guided as
to what exactly it should implement.

--
http://rrt.sc3d.org
CC: rt@openssl.org
Subject: Re: [openssl.org #3213] [PATCH] Fix failure to read default CA file & CA path in s_{client,server,time} (bug #977)
Date: Sat, 11 Jan 2014 13:17:27 +0100
To: openssl-dev@openssl.org
From: Florian Zumbiehl <florz@florz.de>
Hi,

Show quoted text
> So in that case it should try only the user's option if the user gave a
> -CApath or -CAfile, and otherwise the default option?

well, I am not an OpenSSL dev, but that's the behaviour I would consider
correct, yeah.

Show quoted text
> The suggestion above has the advantage that it does not require
> SSL_CTX_load_verify_locations to be changed (as its behavior of failing
> when CApath and CAfile are both NULL is documented). However, if it were
> changed, then the code above would still work.

Yeah, I didn't mean to imply that SSL_CTX_load_verify_locations() should be
changed, for the reason you mention, just pointing out that the behaviour
doesn't really make sense ...

Show quoted text
> The correct behavior is, as I hope I've made clear, outside my competence
> to decide, but I'm quite happy to work up an acceptable patch if guided as
> to what exactly it should implement.

Thanks for the work, that bug did have me scratch my head a while ago (I
used socat instead then, they manage to get it right), it wouldn't hurt to
get that fixed ...

Florian
CC: openssl-dev@openssl.org
Subject: Re: [openssl.org #3213] [PATCH] Fix failure to read default CA file & CA path in s_{client,server,time} (bug #977)
Date: Sat, 11 Jan 2014 12:32:51 +0000
To: rt@openssl.org
From: Reuben Thomas <rrt@sc3d.org>
Download (untitled) / with headers
text/plain 1.2k
On 11 January 2014 12:17, Florian Zumbiehl via RT <rt@openssl.org> wrote:

Show quoted text
> Hi,
>
> > So in that case it should try only the user's option if the user gave a
> > -CApath or -CAfile, and otherwise the default option?
>
> well, I am not an OpenSSL dev, but that's the behaviour I would consider
> correct, yeah.
>
> > The suggestion above has the advantage that it does not require
> > SSL_CTX_load_verify_locations to be changed (as its behavior of failing
> > when CApath and CAfile are both NULL is documented). However, if it were
> > changed, then the code above would still work.
>
> Yeah, I didn't mean to imply that SSL_CTX_load_verify_locations() should be
> changed, for the reason you mention, just pointing out that the behaviour
> doesn't really make sense ...
>
> > The correct behavior is, as I hope I've made clear, outside my competence
> > to decide, but I'm quite happy to work up an acceptable patch if guided
> as
> > to what exactly it should implement.
>
> Thanks for the work, that bug did have me scratch my head a while ago (I
> used socat instead then, they manage to get it right), it wouldn't hurt to
> get that fixed ...
>

Jolly good!

Could we please have an opinion from a developer willing to define and push
an acceptable patch?

--
http://rrt.sc3d.org
Fixed in branch, to be released post-1.0.2

commit 3938694b2a770efad980c947b68981b110e784d6
Author: Rich Salz <rsalz@akamai.com>
Date:   Fri Aug 15 14:27:04 2014 -0400

    PR 2936, etc: Consistently use default cert dir
   
    All apps that have -CApath and -CAfile now are consistent and
    call common code to use the specified parameters, or use
    the default file/dir if none are specified.


--  
Rich Salz, OpenSSL dev team; rsalz@openssl.org