https://bz.apache.org/bugzilla/show_bug.cgi?id=55707
--- Comment #17 from Dan McLaughlin <[email protected]> --- (In reply to Dan McLaughlin from comment #16) > Is this issue supposed to be fix? > > I'm trying to be as detailed as possible to help, so don't skim my comments > or notes below or you might miss important information. First I'll explain > how things are configure, then at the bottom I'll explain the behavior we > see. > > We have some third party clients that use our web service that have not > upgraded their applications so we have to temporarily support TLS 1.0 for > them. We are limited to only a single IP address and port because of > infrastructure outside of our control. We do have two domains however that > are registered in DNS that point to the same external IP address. What we > are attempting to do is use the two domain names we have registered to > support upgrading all of our clients that support TLS 1.2 & 1.3 using > www.domain-new.com, while still providing temporary support for clients that > still only support TLS 1.0 using www.domain-old.com. > > NOTE: There are couple things that I'll mention that aren't detailed in my > example, but I'm mentioning them just in case you think they could somehow > affect things. > > 1) <Location "/secure/myWebService">, <Location "/secure/AppA">, etc... are > contexts that are hosted on our back-end application servers and are > proxied/load balanced to the back-end Tomcat application servers using > mod_jk. > > 2) HAProxy sits in front of Apache load balancing a farm of Apache > webservers. We use mod_remoteip and send-proxy-v2 so that we can log the > actual client IP address in the Apache access logs instead of the HAProxy IP > address. > > The HAProxy config looks like this: > > ... > listen https_proxy > bind 144.192.168.2:443 > mode tcp > option tcplog > option ssl-hello-chk > balance roundrobin > server http01 144.192.168.5:443 check-send-proxy send-proxy-v2 > server http02 144.192.168.6:443 check-send-proxy send-proxy-v2 > > In each of our Virtual Hosts we configure mod_remoteip send-proxy-v2 support > using: > RemoteIPProxyProtocol On > RemoteIPTrustedProxy 144.192.168.2 > > > Here is the simplified version of what I'm running... > > Listen 144.192.168.5:443 > > <VirtualHost _default_:443> > > #NOTE: I added _default_ only because I saw a comment earlier in this ticket > #where it was stated that I had to have a default host configured that > #supported all of the SSL protocols that I needed to support in all vhosts. > #Adding this hasn't changed the behavior at all. Things behave the same > #regardless, meaning if I remove the _default_ vhost I see no change in the > #behavior I see. I'm leaving it here only to show I've tried it. > > DocumentRoot "/docroot" > RemoteIPProxyProtocol On > RemoteIPTrustedProxy 192.168.0.2 > > SSLEngine on > SSLProtocol all > SSLCipherSuite DEFAULT > SSLStrictSNIVHostCheck on > SSLCertificateFile /certs/www.domain-new.com.server.crt.pem > SSLCertificateKeyFile /certs/www.domain-new.com.priv.key.pem > SSLCACertificateFile /trustedCAs/cacerts.crt.pem > SSLCARevocationFile /crls/ca-bundle.crl > SSLVerifyClient none > SSLVerifyDepth 10 > </VirtualHost> > > <VirtualHost 144.192.168.5:443> > > #NOTE: We need to Support TLSv1 for Legacy Web Service Clients ie. .NET 3.5, > #JDK 6 > #The plan was to point all Legacy Clients that only support TLS 1.0 to > #https://www.domain-old.com/secure/myWebService > > ServerName www.domain-old.com > RemoteIPProxyProtocol On > RemoteIPTrustedProxy 192.168.0.2 > DocumentRoot "/docroot" > > SSLEngine on > SSLProtocol TLSv1 > SSLCipherSuite DEFAULT > SSLStrictSNIVHostCheck on > SSLCertificateFile /certs/www.domain-old.com.server.crt.pem > SSLCertificateKeyFile /certs/www.domain-old.com.priv.key.pem > SSLCACertificateFile /trustedCAs/cacerts.crt.pem > SSLCARevocationFile /crls/ca-bundle.crl > SSLVerifyClient none > SSLVerifyDepth 10 > > # Because we only want to support TLS 1.0 for two customers we use > mod_rewrite to rewrite anything that's not trying to hit > /secure/myWebService to the virtual host for our primary domain where all of > our applications are hosted on www.domain-new.com. Commenting this out makes > no difference in the behavior we see. > > RewriteEngine On > RewriteCond %{REQUEST_URI} !^/secure/myWebService.* [NC] > RewriteCond %{HTTP_HOST} www.\domain-old\.com$ [NC] > RewriteRule ^ https://www.domain-new.com%{REQUEST_URI} [L,R=301] > > <Location "/secure/myWebService"> > Require ip 143.33.44.43 201.23.45.3 > </Location> > </VirtualHost> > > <VirtualHost 144.192.168.5:443> > > #We need to support ONLY TLSv1.2 & TLSv1.3 for Newer Browsers and Web Service > #Clients ie. Latest Browsers, .NET 4.6.2, JDK 7u131 or greater > #The plan was to point all Newer Clients that support TLS 1.2 & 1.3 to > #https://www.domain-new.com/secure/myWebService > > ServerName www.domain-new.com > RemoteIPProxyProtocol On > RemoteIPTrustedProxy 192.168.0.2 > DocumentRoot "/docroot" > > SSLEngine on > SSLProtocol SSLProtocol TLSv1.2 TLSv1.3 > SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH > SSLStrictSNIVHostCheck on > SSLCertificateFile /certs/www.domain-new.com.server.crt.pem > SSLCertificateKeyFile /certs/www.domain-new.com.priv.key.pem > SSLCACertificateFile /trustedCAs/cacerts.crt.pem > SSLCARevocationFile /crls/ca-bundle.crl > SSLVerifyClient none > SSLVerifyDepth 10 > > <Location "/secure/myWebService"> > Require all granted > </Location> > > <Location "/secure/myWebService"> > Require all granted > </Location> > > <Location "/secure/AppA"> > Require all granted > </Location> > > <Location "/secure/AppB"> > Require all granted > </Location> > > <Location "/secure/AppC"> > Require all granted > </Location> > > <Location "/secure/AppD"> > Require all granted > </Location> > </VirtualHost> > > What I was expecting is that if I hit > https://www.domain-old.com/secure/myWebService that TLS 1.0 would be > negotiated, and if I hit https://www.domain-new.com/secure/myWebService that > TLS 1.3 or 1.2 would be negotiated. That's not what happens. In the example > above TLS 1.0 is what Chrome, FireFox, and Safari negotiate (all the latest > versions), regardless if I connect to > https://www.domain-old.com/secure/myWebService or > https://www.domain-new.com/secure/myWebService. > > In summary, what I'm seeing is that whatever the SSLProtocol is configured > to in the first VirtualHost is the SSL protocol that is used for ALL > VirtualHosts that share the same IP:Port. If I change the order of the > VirtualHosts, then the TLS version changes to whatever the first VirtualHost > is. If don't change the order but instead change the SSLProtocol for > www.domain-old.com VirtualHost to TLSv1.3 then all the VirtualHosts use > TLSv1.3. > > Based on everything I've read in this ticket and the related OpenSSL tickets > what I'm attempting to do should be working using the version of Apache and > OpenSSL that I'm using, but its clearly not. I'm running Apache/2.4.37 > (Win64) OpenSSL/1.1.1 mod_jk/1.2.46 VC15 from ApacheLounge on Windows 2008 > R2 SP1. I'd much rather be running on this on Linux, but it's out of my > control because of third-party integrations we have the require us to run on > Windows. All references to 192.168.0.2 above were a type, it was supposed to be 144.192.168.2. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
