On Wed, Jan 22, 2014 at 04:26:34PM -0500, Ben Johnson wrote:
> > No -CAfile or -CApath options in this command-line.
>
> I see. I had actually tried adding a -CApath, but I didn't think it was
> working correctly because no matter what path I supplied, the
> certificate always ended with (what I understand to be) a "success"
> response:
>
>
> Verify return code: 0 (ok)
The return code from the verify callback is not the certificate
verification status. It just means the client is willing to keep
going.
> Is there a rational explanation for this behavior? I would expect the
> openssl executable to complain that the supplied CApath is invalid
> (doesn't exist), and for the TLS session to end with something other
> than "Verify return code: 0 (ok)".
You have not told s_client to abort the connection when the peer
certificate is invalid. Since s_client() is a testing tool, it is
most useful when the certificate is invalid. So far nothing unexpected.
> $ openssl s_client -connect example.com:25 -starttls smtp -CAfile /fake/file
>
> I see the type of output that I would expect in the former scenario with
> -CApath:
Setting CApath causes OpenSSL to search for certificates with
filenames that are constructed by appending subject DN hashes to
the CApath prefix. It is OK for these to not exist, so no error
reports when the CApath directory is bogus. Since CAfile is a
fixed location you do get error reports for opening that.
Don't set bogus values of CApath.
> In other words, -CApath doesn't really seem to work. At all. Unless I am
> misunderstanding something fundamental.
It does, but you need to know about c_rehash(1).
> > There is no problem.
>
> That's a relief! Looks like I am in good shape here, but I am curious
> about the -CApath issue described above, nonetheless.
There is still no problem. You're a little-bit poorer after paying
for a certificate, but everything is working correctly.
--
Viktor.
