Understanding the behvaiour for openssl verify and -crl_check
David Balnaves
This is my first post to this list, so I apologise in advance if I have
overlooked list etiquette. I have tried to read the documentation but
could not find anything that explained this aspect of openssl behaviour.
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.
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
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.
When I try to verify a certificate without the crl check all appears
fine:
david@eurocorp:/home/ca/C=AU/O=test/OU=test$ openssl verify -CAfile
cacert.pem newcerts/00.pem
newcerts/00.pem: OK
However, when I try the CRL check I receive the following error:
david@eurocorp:/home/ca/C=AU/O=test/OU=test$ openssl verify -CAfile
cacert.pem -crl_check newcerts/00.pem
newcerts/00.pem: /C=AU/O=test/OU=test/CN=Certificate
0/emailAddress=sup...@busibox.com.au
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 the
following file:
stat64("/usr/lib/ssl/certs/07c527d9.r0", 0xbf84846c) = -1 ENOENT (No
such file or directory)
If I were to create a symlink at this location to my crl, I see the
desired output:
david@eurocorp:/home/ca/C=AU/O=test/OU=test$ openssl verify -CAfile
cacert.pem -crl_check newcerts/00.pem
newcerts/00.pem: /C=AU/O=test/OU=test/CN=Certificate
0/emailAddress=sup...@busibox.com.au
error 23 at 0 depth lookup:certificate revoked
My questions are:
- Why is openssl trying to find the crl
at /usr/lib/ssl/certs/07c527d9.r0?
- Why does it choose to use the crl named 07c527d9.r0? Is this some
hash as the filename?
- How can I override these options so that the correct file location is
used?
Best Regards,
David Balnaves
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Dave Thompson
> 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:
> david@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.
David Balnaves
Thanks very much for your help! I've now got the verify stuff working
to my satisfaction.
On Mon, 2010-08-02 at 22:25 -0400, Dave Thompson wrote:
> > 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).
Thanks, this all makes sense.
> > - 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.
This was REALLY helpful. I'm not sure how I missed this. Thanks for
pointing this out to me!