On 2013-01-28 at 19:25 +0000, Jeremy Harris wrote:
> I've pushed my work-in-progress branch to tahini, "test_ocsp_staple".
+setup_ocsp_verify(BIO *bp, char *CAfile, char *CApath)
+{
+ X509_STORE *store;
+ X509_LOOKUP *lookup;
+ if(!(store = X509_STORE_new())) goto end;
[...]
+ return store;
+ end:
+ X509_STORE_free(store);
+ return NULL;
+}
The X509_STORE_free() will be called on the non-allocated store. The
third line of the function body needs to just `return NULL;`. I see
that this is copy&paste from openssl's apps/apps.c -- we'll need to
update the file header to acknowledge the code source as it's
non-trivial and the OpenSSL project has copyright in it.
I'm trying to find docs on `X509_LOOKUP_load_file()` and failing;
tracing the code, it boils down to OpenSSL crypto/x509/by_file.c
by_file_ctrl() in the X509_L_FILE_LOAD case of cmd.
I think this code is flawed: if the administrator has configured a
CApath but not a CAfile, that does not mean to _also_ load the default
CAfile, and vice versa. This is adding in unwarranted trust anchors and
is a security flaw, surely? If only one of CAfile and CApath is
non-null, then the defaults for the other should *not* be loaded!
So as things stand, $SSL_CERT_DIR can be set in the environment, and if
not set, then for OCSP purposes, all certs in OPENSSLDIR/certs will be
trusted, even if I've explicitly configured a CAfile. Have I
misunderstood? That seems insanely dangerous: if I'm verifying an OCSP
staple, I want to pin the trust anchor for that to be _only_ the CA
which is expected to be doing the OCSP stapling: no other CA gets to
verify the staple!
Can you please check on openssl-users about the API usage here before
taking the code into the master branch of Exim?
Thanks,
-Phil
