Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 and redirect the traffic to .

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?

share|improve this question
Your situation might be annoying, but it isn't ironic ;) – Gareth Aug 5 '10 at 14:59
@Gareth, It's the Alanis Morissette definition of ironic (aka annoying as you said). – ManiacZX Aug 5 '10 at 21:05
@ManiacZX I've always thought the irony in the Alanis Morissette song was actually the song. It's ironic that the song has no real irony. – Joshua Mar 12 '13 at 18:54
up vote 10 down vote accepted

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:

  • Have a wildcard certificate for *, so all subdomains can share the same certificate.
  • Run each SSL site at a different IP address. This way, the web server knows which SSL certificate it can send to the browser, by inspecting the IP address which received the incoming connection.

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.

share|improve this answer
You can also host multiple SSL sites at the same IP under a Unified Communication Certificate (UCC), see – ManiacZX Aug 5 '10 at 21:09
One other workaround for the multi-hostname/one IP certificate issue is to use alternative port numbers. This is not ideal, since some firewalls/public access points block non 80/443 traffic. – Bryan Agee May 18 '11 at 21:39

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 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.

share|improve this answer

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 to This is a legitimate reason to redirect from https to https.

This should work fine.

share|improve this answer
That scenario you described would be fine, however if you navigated to and were redirected to while having the actual address masked such that the browser still shows, THAT is not a good thing. This is fairly common with non-secure sites where it is irrelevant, but surely you can see the dangers inherent in displaying yourself as a secure website that you are in fact not. – Charles Aug 9 '10 at 15:20

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 will be fine but if you mask this such that the browser stillthinks it is pointed at when in reality you have sent it to, 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.

share|improve this answer
Thanks Charles. That must be the "undesired" situation I was thinking of. – Stefan Lasiewski Aug 6 '10 at 15:48

As a see it, this problem can be solved on a transport layer. Let's say you have DNS A record for pointing to When you type in a browser your PC established a TCP connection to a server with IP, 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 (аnother server with DNS A pointing to it. HA proxy linux utulity installed on the first server might solve this with a config like that:

        log    global
        mode    tcp
        retries 2
        option redispatch
        option tcplog
        option tcpka
        option clitcpka
        option srvtcpka
        timeout connect 5s      
        timeout client  24h     #timeout client->haproxy(frontend)
        timeout server  60m

listen front443
    server back443

But this will cause SSL certificate error unless your web-server would show a SSL certificate with and, for example.

Or you might set up a DNS slpit horizon when from users perstective and resolve to

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.