[openssl-dev] [openssl.org #3937] OpenSSL and s_client behavior when default CA certificates are available

[Viktor Dukhovni]

On Sat, Jul 11, 2015 at 02:08:34AM +0000, noloader at gmail.com via RT wrote:

>      # Intuitively, this should fail, but it does not.
>      openssl s_client -connect www.microsoft.com:443 -tls1 -servername www.microsoft.com -CAfile Google-CA.pem

Your timing is impeccable, the fact that "-CAfile" does not suppress
the default store locations, but merely adds to them is under discussion
on the OpenSSL team internal mailing list.

> I like the default behavior of "use a list of CAs in the absence of
> -CAfile and -CApath".

Good so far.

> But I'm not sure the strategy taken is the best one. In fact, the
> strategy kind on nullifies s_client's usefulness as a debug tool.

But you want to be able specify a set of CAs that preempts the
default locations.  And yet it is also useful to be able to augment
them.

The verify(1) command, has a recently (1.0.2d) documented "-trusted"
option, whose new documentation is wrong (hence the discussion on
the team list).  That option suppresses the default CAs.

It clearly useful to provide both the "augment" and "replace"
features.  The key question is with what combination of flags.

Perhaps:

    * A new "-nodefCAs" (or similar) boolean option to optionally
      suppress the default locations.

    * An extended -CAfile option that can be specified more
      than once to use multiple files

    * An extended -CApath option that can be specified more
      than once to use multiple directories

    * Remove the "-trusted" option which combines -CAfile
      with the "no defaults" boolean.

An alternative is to go with what we've got and add "-trusted"
to all the CLI apps, not just verify(1).

I don't thin that after all these years "-CAfile" should be changed
incompatibly in s_client(1) and verify(1) to suppress the default
CAs.  However, the story is messy, because it does do that in
smime(1), cms(1) and ocsp(1).

So we need to fix this is master first, and I'm not sure what to
do in existing releases.  Likely just leave them as-is is best.

-- 
	Viktor.