httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: [users@httpd] RE: Apache SSL Feature - Please Advise (PATCH for mod_ssl)
Date Mon, 13 Dec 2004 16:59:12 GMT
On Fri, Dec 10, 2004 at 04:33:15PM -0500, TAYLOR, TIM (CONTRACTOR) wrote:
> 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.

Yup, it's not a big deal and your patch is pretty simple.  A directive
like SSLCADNRequest would probably be hard to document coherently

> >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.

The SSLProxy* directives control the operation of mod_ssl when it is
acting as an SSL *client* in the case where mod_proxy is used to proxy a
request to a remote SSL server.  But these new directives have no
meaning for an SSL client, only for an SSL server.

The existing SSL_init_FindCAList() call from ssl_init_proxy_ctx() is
indeed already superfluous (but harmless); that part of your patch is
OK, it's just the addition of the new SSLProxy* directives which should
not be done.



View raw message