At Joe's request I've posted the last comment here. It is in reference to bug #43822 which is OCSP Stapling support for mod_ssl:
> The trunk mod_ssl now has: > > 1) session caching code factored out, and > 2) generic-ish OCSP request implementation. > > which should simplify this patch quite a lot. Any chance the patch could be > redone for trunk? > > I don't much like adding another mutex object type on top of APR global > mutexes, it seems redundant; I'd think that extending ssl_mutex_*() to take a > apr_global_mutex_t * or something similar would be sufficient, so that those > functions are simple helpers around the APR global mutex. (or *possibly* > extending util_mutex.c to do that might make sense). > I've finally been able to look at this again. The two attachments are an initial (incomplete) port to the trunk, it works for testing purposes but lacks some features. The rest can be done when I've clarified what people think is the best way to go about things... The mutex code has been removed and some dummy functions to replace them for now. I can change ssl_mutex_*() to apr_global_mutex_t and some additional parameters for ssl_mutex_init() and ssl_mutex_reinit() and removal of the special case code (AP_SOCACHE_FLAG_TOTMPSAFE etc) since the mutex for stapling will always be used. The timeout option doesn't currently work. There is support for timeout in the generic-ish OCSP but it is hard coded. I could change that to take a parameter. The uri and certificate parsing code does duplicate some used in some static functions in the OCSP code (but with hard coded parameters). Again that could be removed by some generalisation. I haven't at this stage altered the session caching code. It still makes use of the SSL session cache to store OCSP responses. Would a separate cache be in order, which works in a manner similar to the SSL session cache? The requirements for the OCSP stapling cache differ from the session cache: only a small number (one per certificate) of entries of relatively small size (under 1K) will be needed but they are likely to persist for longer (several minutes). Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
