> -----Ursprüngliche Nachricht-----
> Von: Kaspar Brand
> Gesendet: Donnerstag, 2. April 2009 07:15
> An: [email protected]
> Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
>
> Plüm, Rüdiger, VF-Group wrote:
> > A question regarding your patch:
> >
> > @@ -427,29 +435,26 @@ int ssl_hook_Access(request_rec *r)
> > * function and not by OpenSSL internally (and our
> function is aware of
> > * both the per-server and per-directory contexts). So
> we cannot ask
> > * OpenSSL about the currently verify depth. Instead
> we remember it in our
> > * ap_ctx attached to the SSL* of OpenSSL. We've to force the
> > * renegotiation if the reconfigured/new verify depth
> is less than the
> > * currently active/remembered verify depth (because
> this means more
> > * restriction on the certificate chain).
> > */
> > - if ((sc->server->auth.verify_depth != UNSET) &&
> > - (dc->nVerifyDepth == UNSET)) {
> > - /* apply per-vhost setting, if per-directory
> config is not set */
> > - dc->nVerifyDepth = sc->server->auth.verify_depth;
> > - }
> >
> > Why don't you stick with the old approach of updating
> dc->nVerifyDepth and using
> > this later on consistently
>
> Because it was called "ugly" by Joe (and not threadsafe, possibly[?]):
>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox
> /%[email protected]%3e
>
Thanks for the pointer.
Going through the follow ups the following question remains for me:
Where did you address to adjust the
SSLCARevocation{File,Path} and
SSLOCSP{Enable,DefaultResponder,OverrideResponder}
settings in the case of an non SNI client connecting to the non default vhost?
> > (the same happens with other fields in the same way later on)?
>
> I don't think any of my changes to ssl_hook_Access adds an assignment
> to any dc->something parameter (or it would be an
> oversight/bug if it did).
This was a misunderstanding. I wanted to say that you followed this
design pattern throughout your patch and changed the logic from
assigning to dc->something to not assigning but to check the
server config separately. So your patch is consistent regarding this.
Regards
Rüdiger
