Thanks, Joe. >Neither of the backwards-incompatible solutions look particularly >desirable. I can't think of a better way than Patch 3 really. It would >be nice if there was some way of just picking out the DNs by name from >the already configured SSLCACertificate* chain e.g. > > SSLCADNRequest /C=US/O=Blah/OU=... > >to avoid the chance of having a mismatch where the client is sent the >wrong DNS, but you get into syntax issues and I don't know if OpenSSL >even supports parsing dnames like that.
I thought about that too. It seems like a lot to do to get a stack of DNs built. But you know the OpenSSL code handles the I/O so well as is, I chose the lazy (smart) code reuse route. I haven't even bothered to look at the FindCAList code. Also, yes a person can, with this patch, in place shoot themself in the foot by requested CAs that he doesn't configure for trust. >I don't think there's any need for the SSLCAProxyDN* you added in your >patch, there is no equivalent point where the client sends DNs, but >otherwise it looks OK. Could you resubmit the patch without that bit? I am not sure I understand. The func ssl_init_proxy_ctx() calls the same ssl_init_ctx() that ssl_init_server_ctx() does. And ssl_init_ctx() calls ssl_init_ctx_verify() which loads client auth cert stuff. To take the proxy directive support out would cascade into more changes to see if a function is executing for a proxy or not. Please clarify and I'll update the patch. regards, tt 317-510-5987
