mod_spdy prevents SSLVerifyClient from working

[d...@threerings.org.uk]

I have the following fragment in my <VirtualHost>:

  <Location /auth/key>

    SSLVerifyClient require

    SSLOptions +ExportCertData

    SSLVerifyDepth 1

  </Location>

With mod_spdy disabled, this works fine - requests to /auth/key require that an SSL client certificate is presented, and then the details of that certificate are passed on to my application.

With mod_spdy enabled, these directives are ignored, and the client certificate is neither required nor passed to the application.

Is anybody aware of a workaround to this? Without it, we're going to have to roll back and stop using mod_spdy. :-(

[Ryan Sleevi]

> --
> You received this message because you are subscribed to the Google Groups "mod-spdy-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mod-spdy-discu...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

The SPDY spec is clear (as is the ongoing HTTP/2.0 work) that it is conceptually incompatible with TLS renegotiation.

ModSSL directives within Location directives - as opposed to top-level VirtualHost/Server directives - forces TLS Renegotiation to occur. The most common way to force renegotiation is what you are doing - path based authorization - but that does not work with SPDY.

There is work investigating this - eg, see http://tools.ietf.org/html/draft-thomson-httpbis-catch - but at present, you cannot carve out such URLs as SPDY-exempt, nor can you do TLS Renego, so you are correct that SPDY is not suitable for your use case.