Maybe mod_gnutls or libressl (working with patched mod_ssl, available in trunk but not yet backported) can do better here, I don't know enough about them to tell. Regards, Yann. On Wed, Jun 17, 2015 at 12:37 AM, karl karloff <karlkarloff@xxxxxxxxxxx> wrote: > So that does not actually help in the case of SSLv3 because SNI is an extension to TLS. It seems like this is not possible in Apache given the usage of OpenSSL as the SSL/TLS library. > > Does that sum it up? > > Thanks, > Karl > > ---------------------------------------- >> Date: Tue, 16 Jun 2015 23:54:39 +0200 >> From: ylavic.dev@xxxxxxxxx >> To: users@xxxxxxxxxxxxxxxx >> Subject: Re: VirtualHosts, SSLProtocol, and SSLCipherSuite >> >> On Tue, Jun 16, 2015 at 10:48 PM, karl karloff <karlkarloff@xxxxxxxxxxx> wrote: >>> I am attempting to set up more than one subdomain on :443 in this example. >>> >>> so something like >>> sslv3.example.com:443 responds with SSLv3 only >>> tlsv1.example.com:443 responds with TLSv1.0 only >>> ... >>> >>> I wasn't aware that could be achieved using the ServerName directive. >>> >>> The underlying IP/interface should be the same for all subdomains, but each subdomain responds by accepting only a single SSLProtocol. >>> >>> Does that make sense? >> >> It does, however there is a limitation currently in OpenSSL in that it >> can't renegotiate the protocol. >> Hence this configuration will work only with browsers/clients >> supporting (and advertising) the Server Name Indication (SNI), which >> allows to select the correct VirtualHost before the negotiation >> occurs. >> Otherwise, Apache HTTPd will have to negotiate before being able to >> read the requested Host header, and hence determine the VirtualHost. >> Thus it will do the negotiation occording to the parameters (protocol, >> ciphers, ...) of the first vhost declared on the listening IP:port. >> If finally the determined vhost is not the one used for the >> negotiation, it will ask for a renegotiation which, as said above, >> won't take the SSLProtocol into consideration due to OpenSSL not being >> able to do that (the SSLCipherSuite can be renegotiated though). >> >> So all should be fine with SNI only. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx >> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx