[openssl-users] Problem with x509_verify_certificate

[Viktor Dukhovni]

> On Nov 20, 2018, at 1:31 AM, Ken <OpenSSL at k-h.us> wrote:
> 
> Are you saying to test with "openssl s_client -connect ..."?

Test both with s_client and with your application if possible.
In both cases configure the CApath empty and the CAfile to hold
just the appropriate trust anchor.  If your application does not
provide a way to specify the CAfile and CApath, OpenSSL defaults
can be overridden via environment variables:

	SSL_CERT_DIR
	SSL_CERT_FILE

> I don't think I know how to interpret all of the output from that,
> but it looked to me like it was saying everything was okay when I
> tried it earlier (with no changes).

Try "s_client -quiet".  For example, a failure:

  $ openssl s_client -quiet -starttls smtp -connect localhost:25
  depth=0 CN = [...]
  verify error:num=20:unable to get local issuer certificate
  verify return:1
  depth=0 CN = [...]
  verify error:num=21:unable to verify the first certificate
  verify return:1

and a success:

  $ openssl s_client -quiet -starttls smtp -connect localhost:25 -CAfile rsacert.pem -partial_chain
  depth=0 CN = [...]
  verify return:1

> I just tried it again with -CApath pointing to an empty directory, and -CAfile
> pointing to a new copy of the root CA certificate, which I just downloaded from
> the provider - I do not see any difference in the output.

You really do need to be much more precise. Is it failing?  Succeeding?
What version of OpenSSL is this particular s_client associated with?
At this point likely post the peer certificate chain (as reported by:

	sleep 2 | openssl s_client -showcerts -connect someaddr:someport 2>/dev/null
                | openssl crl2pkcs7 -nocert -certfile /dev/stdin
                | openssl pkcs7 -print_certs

> Then, I tried again, pointing to an incorrect CA - then I see some errors:
> "verify error:num=20:unable to get local issuer certificate"

Which suggests that it worked the first time.

> So, it seems to me like, without any changes, s_client -connect says
> the certificate is fine, but the application using x509_verify_certificate
> thinks something is wrong....

Well, which trust store is the application using?  And what is this
x509_verify_certificate() you speak of?  I only know about
X509_verify_cert(3).  Which requires an appopriately initialized
X509_STORE_CTX, with suitable trust store settings.

-- 
	Viktor.