> There are just a handful of useful patches in STATUS lacking
> a single vote for inclusion in 2.2.9...
While not completely true for the SNI backport proposal (requires more
than a single additional vote), I'd nevertheless like to draw the
attention to that patch.
Looking at the current votes, I think that the -1 no longer applies,
actually (it was added in December '07, before the code was reworked
considerably):
> Backport version for 2.2.x of updated patch:
> http://people.apache.org/~fuankg/diffs/httpd-2.2.x-sni.diff
> +1: fuankg
> +0: like ssl upgrade of 2.2, perhaps this is a good reason to bring
> httpd-2.4 to completion? vhost changes could be disruptive to
> third party module authors.
> -1: rpluem: jorton found some problems with the trunk version and they
> should be fixed / discussed in trunk before we backport.
The last issue reported by Joe in April
(http://mail-archives.apache.org/mod_mbox/httpd-dev/200804.mbox/[EMAIL
PROTECTED])
can be addressed by the attached patch, if deemed appropriate [1]. All
other problems observed previously are already included in the backport
version.
So, is there still hope for SNI being added in 2.2.9...? Let me know if
there's anything else I can do to increase the chances of getting this
proposal accepted.
Thanks,
Kaspar
[1] The problem is already present in the current 2.2.x branch (it's not
introduced by the SNI patch, in particular): when setting up more than
one SSL-enabled VirtualHost (e.g. by using a wildcard certificate, or a
cert with several subjectAltName entries), only the per-vhost
SSLVerifyClient/SSLVerifyDepth statements set for the *first* vhost are
ever considered.
Index: modules/ssl/ssl_engine_kernel.c
===================================================================
--- modules/ssl/ssl_engine_kernel.c (revision 653796)
+++ modules/ssl/ssl_engine_kernel.c (working copy)
@@ -427,16 +427,21 @@ 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;
+ }
if (dc->nVerifyDepth != UNSET) {
/* XXX: doesnt look like sslconn->verify_depth is actually used */
if (!(n = sslconn->verify_depth)) {
sslconn->verify_depth = n = sc->server->auth.verify_depth;
}
/* determine whether a renegotiation has to be forced */
if (dc->nVerifyDepth < n) {
@@ -456,16 +461,21 @@ int ssl_hook_Access(request_rec *r)
* The order is: none << optional_no_ca << optional << require
*
* Additionally the following optimization is possible here: When the
* currently active verify type is "none" but a client certificate is
* already known/present, it's enough to manually force a client
* verification but at least skip the I/O-intensive renegotation
* handshake.
*/
+ if ((sc->server->auth.verify_mode != SSL_CVERIFY_UNSET) &&
+ (dc->nVerifyClient == SSL_CVERIFY_UNSET)) {
+ /* apply per-vhost setting, if per-directory config is not set */
+ dc->nVerifyClient = sc->server->auth.verify_mode;
+ }
if (dc->nVerifyClient != SSL_CVERIFY_UNSET) {
/* remember old state */
verify_old = SSL_get_verify_mode(ssl);
/* configure new state */
verify = SSL_VERIFY_NONE;
if (dc->nVerifyClient == SSL_CVERIFY_REQUIRE) {
verify |= SSL_VERIFY_PEER_STRICT;
