Correct ... Probably old app will always land in the first vhost, but only for the ssl options, the vhost itself works with its own rules of proxypass and proxy passreverse. The solutions are two: trash the oldapp or use an ip base vhost. Best regards Michele
On Fri, Jul 29, 2016 at 9:02 AM, Daniel <dferra...@gmail.com> wrote: > Follow Yann's advice, probably your only option is to set different ip for > the virtualhost for this client, most probably Java 1.4 does not support > TLS SNI either so using namedvirtualhosts with SSL for this client will > always land you in the first ssl virtualhost available. > > 2016-07-28 23:43 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>: > >> On Thu, Jul 28, 2016 at 10:00 PM, Michele Mase' <michele.m...@gmail.com> >> wrote: >> > >> > Any suggestion? >> >> Ciphers must be negotiated before HTTP is decrypted (and hence vhost >> selection can happen). >> With SSLHonorCipherOrder off, the negotiated cipher is probably >> RC4-SHA (the one preferred by the client). >> With SSLHonorCipherOrder on, the negotiated cipher is probably an >> ECDHE one (preferred by the server), which the old java also support >> but to some extent (eg. DH <= 1024, see >> https://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh). >> >> Anyway, since you still want stronger ciphers for the other >> clients/vhosts, why not put the legacy one on its own (different) IP >> or port, configured with a suitable/compatible CipherSuite >> (CipherOrder shouldn't matter here) ? >> >> Regards, >> Yann. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >> For additional commands, e-mail: users-h...@httpd.apache.org >> >> > > > -- > *Daniel Ferradal* > IT Specialist > > email dferradal at gmail.com > linkedin es.linkedin.com/in/danielferradal >
