|
Victor, Jeremy-
Thanks for your responses. It sounds like I should maybe take a step back and describe what I'm doing and how. I'm possibly doing things fundamentally wrong, maybe because the way I'm doing them is based originally on OpenSSL 0.9.8. I'm currently moving from
1.0.2 to 1.1.1, which is why the questions are coming up.
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.
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. Then when I create an SSL CTX, I call SSL_CTX_set_cert_store() to set the X509_store object for the CTX. I also call SSL_set_verify( ,SSL_VERIFY_PEER,verify_callback) with the SSL object created from that CTX to set
the verify_callback() function for each user that will act as a client.
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. 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. 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. From Victor's response, I don't know what a custom X509_STORE type is or how to set one up. Likewise, I don't know how to use the "partial chain" flag 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. Let me know if I am off track, and if so, what APIs I should be looking at, especially if there are been changes in this area. Thanks. From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> on behalf of Viktor Dukhovni <openssl-users@xxxxxxxxxxxx>
Sent: Monday, March 30, 2020 6:17 PM To: openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx> Subject: Re: Peer certificate verification in verify_callback On Thu, Mar 05, 2020 at 02:04:27PM +0000, Jason Schultz wrote:
> I have some questions about my application’s verify_callback() function and how I handle some of the OpenSSL errors. You're going about this the wrong way. Instead of tryign (likely insecurely) to patch up verification errors in a verify callback, if you have a certificate store that is not directly supported by OpenSSL, you need to implement your own custom X509_STORE type, associate that store with the SSL_CTX and have OpenSSL's built-in certificate verification search that store for you. If you also want to directly trust intermediate certificates that are not self-signed roots, you can either set the "partial chain" flag, or load into your store intermediate certificates with auxiliary trust settings (aka "TRUSTED CERTIFICATES"), which will then be trusted without chaining to a root, but simpler to just add the roots to the store. -- Viktor. |
