On Wed, 18 May 2005, Thomas NOEL wrote:
> Hello,
>
> Le 18.05.2005 13:42, James Yonan a ?crit :
> >>I'm not very happy with this patch : all CA and CRL are checked, but if
> >>I update a CRL, openssl doesn't see any changes and continue to accept
> >>my revoked certificate.
> >>I don't know if there is a "cache" system integrated in openssl... I
> >>don't know if I correctly use X509_STORE_add_lookup() and
> >>X509_LOOKUP_add_dir() ... I'm not a openssl guru, not at all ;-)
> > I think the "cache" you are seeing is the SSL_CTX object -- did you make
> > any progress in figuring out how to have OpenSSL re-read the CRL info from
> > the CAPath dir?
>
> The cache is in the X509_STORE objet. Looking at openssl sources
> (0.9.7), there is a "cache" flag in this struct, but this flag is unused:
>
> From x509_vfy.h :
>
> struct x509_store_st
> {
> /* The following is a cache of trusted certs */
> int cache; /* if true, stash any hits */
> STACK_OF(X509_OBJECT) *objs; /* Cache of all objects */
> /* These are external lookup methods */
> STACK_OF(X509_LOOKUP) *get_cert_methods;
> (...)
> }
>
>
> When OpenSSL have to check a CRL in the STACK_OF(X509_OBJECT), a simple
> cache algorithm is used : if a CRL is found in the stack, use it ; if
> not, search it with the registred lookups methods and store it in the stack.
>
> I do not see any system for refresh the cache (no timeout, no function).
> I have sent a mail on openssl-user list without any anwser.
>
> Looking in apache-ssl, racoon (other openssl projects) : it seems that
> there all need a restart or reload after update the CRL.
>
> I think a nice solution would be to rebuild the X509_STORE of the
> SSL_CTX when a SIGHUP ou SIGUSR1 arrived. But I do not understand yet
> enough the code of OpenVPN :
> - where can I add an action when a SIGUSR1 or SIGHUP is handled ?
> - how can I get the (list of ?) SSL_CTX object ?
>
> Do you think that it is a good idea, and do you think that it is feasible ?
Because of OpenVPN's security architecture, it is very common for a
privilege downgrade or chroot to occur after initialization. This means
that it may not be possible to re-read a file after initialization.
This is a major reason why OpenVPN handles CRLs the way it does now: so
that (a) the OpenVPN daemon need not be restarted after a CRL update, and
(b) the CRL file itself can be located in the chroot jail without
requiring that the private key or any other files reside there as well.
Having said all that, I think --capath + X509_V_FLAG_CRL_CHECK is a good
idea, as a more full-featured alternative to --crl-verify, when people
don't mind needing to restart the daemon to re-read the CRL files.
James
