Peer certificate verification in verify_callback

Jason Schultz jetson23 at hotmail.com
Mon Mar 30 21:02:47 UTC 2020


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 at openssl.org> on behalf of Viktor Dukhovni <openssl-users at dukhovni.org>
Sent: Monday, March 30, 2020 6:17 PM
To: openssl-users at openssl.org <openssl-users at openssl.org>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200330/8e9479d0/attachment.html>


More information about the openssl-users mailing list