> -----Ursprüngliche Nachricht-----
> Von: Kaspar Brand 
> Gesendet: Donnerstag, 2. April 2009 07:15
> An: dev@httpd.apache.org
> 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
> /%3c20080604140111.ga12...@redhat.com%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

Reply via email to