|
Thanks Victor.
I need to look at X509_VERIFY_PARAM_set_flags()
a little closer, but I think I understand what I need to do.
I
also can't concatenate all my trusted certificates into a single file, there are dozens of certificates in the trusted store. Our users can also manipulate the trusted store, so the trusted certificates will always be in PEM files in /etc/ssl/certs/.
It
sounds like that's not going to hold me back from accomplishing what I need to do though, but I'll pursue this and let the list know if I run into any other issues.
Thanks
again,
Jason
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> on behalf of Viktor Dukhovni <openssl-users@xxxxxxxxxxxx>
Sent: Monday, March 30, 2020 9:19 PM To: openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx> Subject: Re: Peer certificate verification in verify_callback 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. |
