Ruediger Pluem wrote: > > On 05/01/2009 07:11 AM, Kaspar Brand wrote: >> Ruediger Pluem wrote: >>> I hope to get the SNI patches summarized in a backportable >>> way by then to have them included in 2.2.12. >> Didn't want to rush things, but since there were no objections to the >> recent trunk commits so far - here's an updated backport for 2.2 >> (including your improvements from March/April, see revision list at the >> top of the file): >> >> http://sni.velox.ch/httpd-2.2.x-sni.20090426.diff > > Thanks for this. Especially the list of revision numbers will be > very helpful for the further process.
I have only one small concern about adopting this. Consider the diversity of installations which users install httpd onto. --- httpd-2.2.x/modules/ssl/mod_ssl.c (revision 768694) +++ httpd-2.2.x/modules/ssl/mod_ssl.c (working copy) @@ -145,6 +145,10 @@ static const command_rec ssl_config_cmds[] = { "Use the server's cipher ordering preference") SSL_CMD_ALL(UserName, TAKE1, "Set user name to SSL variable value") +#ifndef OPENSSL_NO_TLSEXT + SSL_CMD_SRV(StrictSNIVHostCheck, FLAG, + "Strict SNI virtual host checking") +#endif This provides no clue why the directive fails. I'm not fond of conditional compilation of directives. If we can ensure the StrictSNIVHostCheck always exists, but exits when it is not supported with; #ifndef OPENSSL_NO_TLSEXT return "StrictSNIVHostCheck failed; OpenSSL is not built with support " "for TLS extensions and SNI indication. Refer to the " "documentation, and build a compatible version of openssl"; #else ... usual stuff #endif Does this make better sense to avoid user complaints?