I've been Googling for this question, and ironically annoyingly I can't find a concrete answer. I've answered this question myself in the past, and now I can't remember my own explanation.
Several times a year, someone will ask me to do this. I'd like to point them to some sort of respectable article which explains this.
I want to take the URL at https://www.example.com/ and redirect the traffic to https://www.example2.com/ .
I believe this should be technically possible, but is undesired. What is wrong with this method? Will browsers get a security popup since I am redirecting them to another site? Can anyone provide a link to some respectable documentation which explains this?
You can do this, both sites need to have a valid SSL certificate. This way browsers won't give a security pop-up. If both sites exist at the same server however, both domains need to be hosted from different IP addresses.
A web server looks at the "Host" header in the HTTP request to see which site it needs to serve. The SSL negotiation happens before the HTTP request is sent, so at that point the web server can't tell which website it will display. It will always send the same certificate to the browser.
There are two ways to work around this:
Note it's perfectly possible to attach multiple IP addresses to the same network adapter, it's just that you need a second IP address available in your IP address space.
Update: Nowadays, you can run multiple SSL sites at a single IP. To enable this, configure SNI support at your web server. Most modern browsers (except windows XP, and Android 2) support this.
I've never tried this so I don't speak from concrete experience, but it should work. You will need to have a valid SSL certificate for https://www.example.com as the hostname is encrypted inside the HTTP header so your server won't know to redirect until it's decrypted. After that it should redirect as it would a normal HTTP request.
Why would this be undesired?
As an example, Big Bank and Little Bank both run sites on https to give the customers a happy secure feeling. Big Bank buys Little Bank. At some point the IT people will set up a redirect for https://www.littlebank.com to https://www.bigbank.com. This is a legitimate reason to redirect from https to https.
This should work fine.
The one disconnect that I think is present in the current responses that may come up for you is that in any of these circumstances, a true redirect (ie: browser gets repointed to www.example2.com) will be fine but if you mask this such that the browser stillthinks it is pointed at www.example.com when in reality you have sent it to www.example2.com, this is where you will see security warnings precisely because you could be trying to spoof the user.
The short version is a normal redirect should be fine, address masking is probably going to leave you with a lot of explaining to do.
As a see it, this problem can be solved on a transport layer. Let's say you have DNS A record for example.com pointing to 192.168.0.1. When you type https://example.com in a browser your PC established a TCP connection to a server with IP 192.168.0.1, where some process listens on port 443. What if at the same time the server (which is not trying to get into details of the data sent over this TCP session like starting SSL negotiation) establishes a TCP connection to 192.168.0.2 (аnother server with DNS A example2.com pointing to it. HA proxy linux utulity installed on the first server might solve this with a config like that:
But this will cause SSL certificate error unless your example2.com web-server would show a SSL certificate with CN=example2.com and SAN=example.com, for example.
Or you might set up a DNS slpit horizon when from users perstective example.com and example2.com resolve to 192.168.0.1.