Hi everybody....I was sent over the following config section for a :443 virtualhost. I solved the problem...and I think it's a better approach, but I want to understand more about the root of the problem they were experiencing: VirtualHost *:443 ServerName prod.it.brand1.com RequestHeader set brand1-supersecret-override-flag "IT" ProxyRequests On <Proxy *> Order deny,allow Allow from all </Proxy> SSLEngine On SSLProxyEngine On SSLCertificateFile /opt/apache/http-2.2.15/conf/ssl/server.crt SSLCertificateKeyFile /opt/apache/http-2.2.15/conf/ssl/server.key ProxyPass / http://www.brand1.com/ ProxyPassReverse / http://www.brand1.com/ /VirtualHost ...essentially, by default a 3rd party service does a geolocate by IP address to determine what country code should be inserted into the RequestHeader. Customer Service is located in the US, so therefore they only have access to european sites by explicitly typing in the country prefix on the site. As a CSR flows through the site, the RequestHeader will disconnect them from the Italian site (for instance) and redirect them to the American site. A "supersecret-override-flag" was put into processing on the server to hijack the 3rd party geolocation and allow a CSR to tell the system which country they are needing to look at. So...when they set the flag to "IT", it correctly directs them to the Italian site as long as they are working on HTTP. However, as soon as they nav to a secure resource and SSL kicks in, it would bounce them from the Italian site and they would get tossed to the American site (which would disconnect them from their shopping cart) My solution to this was fairly simple: spoof the IP so that each VirtualHost uses a culturally recognized IP. Now, if a CSR tries to go to the Italian site, the RequestHeader gets a fake IP and the 3rd party Geolocation service kicks in and keeps them at the Italian site even when they go SSL. So...even though it's fixed: I'm still trying to determine WHY that behavior occurred. I have a hunch, but it's an assumption that I don't feel 100% confident about. Here's what I'm thinking: When the CSR is working in "HTTP", they are working with one header. The Virtual Host config sets the override flag and all is good. However, when the system tries to go to HTTPS on checkout, the SSLEngine flushes the header and when that override flag is erased, normal processing occurs, the 3rd party geolocator identifies the IP as being in the US, and tosses them to the secure us site. This sounds all hunky dory in my head, but I'll be the first to admit, all of that above is just a stab in the dark at what might have been causing the behavior. Is there anyone out there knowledgeable enough about how mod_ssl behaves to confirm my thoughts or simply blast them out of the water?? (I give you permission to be as mean as you want ...I want to learn lol)