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-boun...@openssl.org> on behalf of Viktor
Dukhovni <openssl-us...@dukhovni.org>
Sent: Monday, March 30, 2020 6:17 PM
To: openssl-users@openssl.org <openssl-users@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.
