tags:

views:

52

answers:

1

I have an interesting issue with HTTPS ports not being handled properly. It is a relatively small issue and I bet it is pretty simple to solve, I am just not thinking of it.

We have a website served with IIS 6, www.mylongdomainname.com. We have a secure portal which is handled via https://www.mylongdomainname.com. Now we have several vanity and marketing URLs that we use over the phone like www.shortname.com, etc. I have two websites setup, one that handles all request with the header www.mylongdomain.com which actually serves the website. The other accepts any traffic and permanently redirects to www.mylongdomain.com. This way if we ever add any more domains, they will all end up at the one, also it redirect mylongdomain.com to www.mylongdomain.com.

Everything here works fine. The issue now is when I google "shortname.com," the first result returned is the same as if I were googling "mylongdomain" however, google has been able to crawl the other pages via https://shortname.com and index them that way. We dont have SSL certificates for these other domains, so when you click through, you get a nasty un-trusted error.

This really wouldn't be an issue if we didn't use these URLs over the phone, and you all know how many people don't know the difference between the URL bar and a search box.

any suggestions or tips?

+2  A: 

I'd set up a redirect so that https://shortname.com is sent to http://shortname.com with a 301 (permanent) redirect. This will put an end to the nasty untrusted error immediately. Furthermore, this will also cause Google to slowly but surely update their index.

There are multiple ways to do this. If you're using IIS7 you can use the URL Rewrite Module and write a redirect rule to take care of it.

Or if you're not on IIS7 it may be perfectly acceptable to write some code to accomplish this. I wrote some ASP.NET I've used plenty of times to take care of this HTTP/HTTPS redirection. In your particular case you could simply take my code and call SetSSL(False) in the Application_BeginRequest function of your global.asax.

Steve Wortham
Aye, I didn't mention that, but I already had that handled though asp.net. Looking at it again, the mistake I made was I was using a Response.Redirect (302) instead of the 301. Silly me.
dgxshiny