On Mon, Mar 30, 2020 at 09:02:47PM +0000, Jason Schultz wrote:
> I won't get into the details of my application as it's complex, but it
> can act as a client or a server. The case we are worried about is
> obviously when it's acting as a client. I thought the standard way of
> dealing with these type of errors was with setting a verify_callback()
> function, which is part of the description below.
The verify callback is mostly for logging and error reporting. It is
not intended to supplant the built-in verification logic. While it
can be used to ignore some errors, that's generally quite risky and
difficult to do correctly. You should strive to arrange for the
built-in verification to succeed, rather than attempt to work around
the resulting errors when it does not.
> I set up an X509_STORE object and then cycle through all of the
> certificate files in /etc/ssl/certs/, open them, and call
> PEM_read_X509() to get an X509 (certificate) object and then call
> X509_STORE_add_cert(x509_stor, certificate) to read the certificates
> into my trusted store, X509_store object.
It would be far simpler to concatenate them into a single CAfile, or use
"c_rehash" to create the symlinks need to make the directory into a
workable CApath. You should not have to manually load them into your
own store, although doing the latter potentially gives you the
opportunity to decorate them with auxiliary trust EKUs.
> If the user of this CTX is acting as a client and the server presents
> a certificate chain, and my trusted store has the root, the connection
> will work, as the chain is verified and trusted.
With the partial chain flag it can also work when the EE cert is present
(verbatim) in the store, or an intermediate CA is present in the store.
> If the server presents a self-signed certificate, the
> verify_callback() function is invoked with the error
>
> 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT, but if I search for and find the self-signed cert in my trusted store, I clear the error and let the
> connection proceed.
With 1.0.2 and later, the partial chain flag makes this work-around
unnecessary.
> The scenario is very similar for the case I asked about, the only difference is I'm presented a 2 certs in a chain, and I have the
> intermediate cert in my store. My understanding was the verify_callback() is the correct place to handle these cases.
No, it is not.
> From Victor's response, I don't know what a custom X509_STORE type is
> or how to set one up.
You're already populating a custom store (though not a store type, which
it does not look like you need since your store is just a directory full
of PEM files).
> Likewise, I don't know how to use the "partial chain" flag
See X509_VERIFY_PARAM_set_flags(3).
> and what API I need to load intermediate certificates into my trusted
> store(other than what I describe above). Because of the way
> certificates are distributed, I can't always rely on having the root
> in the trusted store, so I'll need to trust some intermediate certs,
> provided they are valid, actually signed the end-entity cert, etc.
You just need to add them to the store, simplest is a CAfile or
a hashed CApath.
--
Viktor.
