> From: owner-openssl-us...@openssl.org On Behalf Of David Balnaves
> Sent: Monday, 02 August, 2010 02:20
> This is my first post to this list, so I apologise in advance
> if I have overlooked list etiquette. <snip>
> I've tried to read the source in eclipse/cdk but found myself quickly
> beyond my depth once verify went into the depths of
> X509_LOOKUP_load_file.
>
The X509 verify stuff is I think the twistiest part of OpenSSL.
> I'm trying to understand the behaviour of openssl verify in
> relation to using the crl check in: OpenSSL 0.9.8k 25 Mar 2009
>
I don't think this has changed, but you're wise to say.
> My understanding is that Openssl should be using the combination of
> options from the command line and those specified
> in /usr/lib/ssl/openssl.cnf.
>
in general OPENSSLDIR/openssl.cnf or (sometimes?) $OPENSSL_CONF;
on your system that apparently is /usr/lib/ssl. But only for some
utilities, IIRC not including verify. Plus compiled defaults (always).
> When I try to verify a certificate without the crl check all appears
> fine:
> da...@eurocorp:/home/ca/C=AU/O=test/OU=test$ openssl verify -CAfile
> cacert.pem newcerts/00.pem
> newcerts/00.pem: OK
>
(Aside: you put all that in your directory path? Yuck.)
> However, when I try the CRL check I receive the following error: <snip>
> error 3 at 0 depth lookup:unable to get certificate CRL
>
> So, when I investigate a with strace I see that it is trying
> to stat ... "/usr/lib/ssl/certs/07c527d9.r0" ...
> If I were to create a symlink at this location to my crl, I see the
> desired output: <snip>
> My questions are:
> - Why is openssl trying to find the crl
> at /usr/lib/ssl/certs/07c527d9.r0?
The search for *certs* is CAfile (commandline option or else default)
then CApath=directory (ditto), and I believe CRLs should be the same
(but as I say this part is twisty). You specified a -CAfile;
is the CRL in that? If so, not finding it may be a bug. If not,
you didn't specify -CApath so it defaults to OPENSSLDIR/certs
(where OPENSSLDIR in your case is /usr/lib/ssl).
> - Why does it choose to use the crl named 07c527d9.r0? Is this some
> hash as the filename?
Yes. It is a hash of the issuer=CA name, plus .r0 (or .r1 etc);
for a cert it is the hash of the subject name plus .0 .1 etc.
That's how the (hopefully) right file is found (hopefully) fast.
man s1 {verify,x509} mention this for certs, and man s3
SSL_CTX_load_verify_locations gives some more detail.
You have to extrapolate that CRLs are handled the same way.
tools/c_rehash, which may or may not have been installed to
somewhere/bin, is a (Unix) perl script to create the links,
and shows exactly what they need to be.
> - How can I override these options so that the correct file
> location is
> used?
>
I believe either putting the CRL in file -CAfile, or putting it
in a file in dir -CApath which is c_rehash'ed, should work.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
