2

I recently acquired an SSL certificate for my primary site (https://wemarsh.com/). It works great, and I've even set up an .htaccess rule so all traffic on that site is encrypted. (I'm running Apache.)

However, I also have other sites on this same server, with the same IP address. For example, I have a blog (http://gallivant.wemarsh.com/). It works great as long as I connect to the non-encrypted version. I do not want to enable encryption for this site, as I know that my existing certificate does not include that subdomain and I do not want to pay for the additional IP address to do so. So all is good if the user types http:// but if the user types https:// (for whatever reason), a warning appears saying that the site is an imposter (as expected, because the cert is wrong). But if the user clicks to proceed anyway, it brings them to the main site instead of the blog on the subdomain. This is a circumstance that will rarely be encountered in practice, but I feel that the correct behavior is to give a warning and then proceed to the correct "imposter" site. Or it would probably be fine with me if it just failed completely.

I understand some of the problems in play. First, I understand that the SSL stuff happens before Apache gets the request, which is why one can't generally have multiple certs on the same IP address. It also seems to be preventing me from just using an .htaccess rule to forward everybody to the http:// version of the site (opposite of what I do on the main site).

So the way I understand what is happening is this: The SSL handles the certificate request by returning the wrong certificate to the browser. The browser balks, but allows us to proceed. Then Apache doesn't know what URL was requested but knows it was on port 443, so it returns the main site. The browser thinks it got the subdomain blog, so it still displays that URL.

My current vhosts for the main site are like this:

<VirtualHost *:80>
  ServerAdmin [email protected]
  ServerName  www.wemarsh.com
  ServerAlias wemarsh.com

  DirectoryIndex index.html
  DocumentRoot redacted
</VirtualHost>

<VirtualHost *:443>
  ServerAdmin [email protected]
  ServerName  www.wemarsh.com
  ServerAlias wemarsh.com

  SSLEngine on
  SSLCertificateFile redacted
  SSLCertificateKeyFile redacted
  SSLCertificateChainFile redacted
  SSLCACertificateFile redacted

  DirectoryIndex index.html
  DocumentRoot redacted
</VirtualHost>

My current vhost for the subdomain blog is like this:

<VirtualHost *:80>
  ServerAdmin [email protected]
  ServerName  gallivant.wemarsh.com

  DirectoryIndex index.php
  DocumentRoot redacted
</VirtualHost>

I attempted to also define port 443 in the vhosts for the subdomain, but that didn't work.

Is it possible to do what I'm trying to do? Does anybody have a solution? At some future point the situation will get more complex when I do add an additional IP address and another certificate to the server, so please keep that in mind when making suggestions.

I suppose that shared hosting providers must be doing this somehow, otherwise all non-https sites would break, right?

(Note: I've intentionally not linked to the https version of gallivant. The last thing I need is Google directing people to this bug, so please avoid linking that in your responses.)

Thanks in advance!

1 Answer 1

0

You can't get around the warning that user get since you are right - it can't be determined what's the name of the domain until it's too late. It works only with TLS (TLS is supported on modern browsers, but not on older ones and also most automated crawlers and api scripts won't know TLS also).

Only fixes you could do is after the user has passed the warning page - check if hostname is correct, and if it's not then redirect to correct non-ssl (or ssl) domain.

Best fix would be of course to get separate ip for SSL, so that it would not collide with other domains, but as you pointed out you don't want to do that.

1
  • "check if hostname is correct, and if it's not then redirect to correct non-ssl (or ssl) domain." - So how would I do this? From what I'm seeing, it seems that Apache doesn't really know the desired hostname.
    – Eric Marsh
    Commented Oct 19, 2013 at 11:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .