On 01/11/13 10:46, Maxim Dounin wrote:
<snip>
I'm afraid it's a much larger patch than I anticipated it would be
when I started working on it!
Maxim, does this patch look commit-able?
Maxim, thanks for your initial comments.
It looks like it needs to be broken down into a patch series to
be at least reviewable.
I thought you might say that. Is it acceptable for there to be
compilation errors if you only apply some of the patches in a patch
series? (I was assuming that would be unacceptable, hence the one large
patch).
I haven't looked into details yet, but I tend to dislike at least
changing the ngx_ssl_certificate() function into a monster which
configures everything. Preserving a separate call to configure
stapling would be much better.
I had hoped to keep those calls separate, but I couldn't see a clean way
to keep track of multiple server certs plus associated issuer certs
inbetween the calls to ngx_ssl_certificate() and ngx_ssl_stapling().
By combining the certificate configuration and stapling configuration
functions, I made this problem go away.
To preserve ngx_ssl_certificate() and ngx_ssl_stapling() as separate
functions, I think I'd have to:
- change ngx_ssl_certificate_index to keep an array (either
ngx_array_t or STACK_OF) of server certs.
- have ngx_ssl_certificate() put all of the intermediate CA
certificates it encounters into a temporary cert store; have
ngx_ssl_stapling() look in this temporary cert store for issuer
certificates; then destroy the temporary cert store.
Would that be preferable? Or do you have any better ideas?
Checks for extra ceritifcate chains with unsupported OpenSSL
versions looks a bit too extensive. I would think of just
dropping them completely.
OK, (assuming you mean drop the checks, rather than drop support for
those OpenSSL versions!)
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
