0

I have an Apache server running two sub domains, one of them is configured with SSL.

To get the other sub domain to work, we of course had to set up a new IP (because the other one was configured with SSL).

However, we cannot reach our new sub domain and we cannot figure out why. The Apache configuration should be OK.

Here's a snippet of our virtual hosts directives:

# ssl domain
<VirtualHost 1.2.3.4.5:80>
    ServerName sub1.example.com
    DocumentRoot /var/www/sub1

    <Directory "/var/www/sub1">
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>


# "regular" domain
<VirtualHost 2.3.4.5.6:80>
    DocumentRoot /var/www/sub2
    ServerName sub2.example.com

    <Directory "/var/www/sub2">
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>
</VirtualHost>

Requests to sub1.example.com are OK, but nothing happens when we try sub2.example.com.

The "default" config for Apache is set to:

Listen 80
ServerName sub1.example.com

We are running Apache/2.2.15 on CentOS 6.

6
  • 1
    I don't understand, you don't need a second IP to run an additional non SSL vhost, only if you want two different SSL certificates on the same machine.
    – Ian Roberts
    Jul 17, 2012 at 8:10
  • @IanRoberts Yes, you need an additional IP when you want a non SSL vhost. It's because the other IP is set up with SSL, and therefore no other sub domains can be "linked" to that IP.
    – DavidS
    Jul 17, 2012 at 8:16
  • I operate a server which runs many different non-SSL NameVirtualHost websites on a single IP on port 80, plus one SSL vhost on the same IP on port 443. It's only if you want two different port 443 vhosts that use different certificates where you need an additional IP address (if the two SSL vhosts share the same certificate e.g. a wildcard *.example.com, or if they use different port numbers, then they can share the same IP).
    – Ian Roberts
    Jul 17, 2012 at 9:12
  • @IanRoberts As much as I want to agree with you, we tried setting up a non-SSL domain on the same IP, but with no luck. When we contacted our server supplier, they responded that the problems was because we did not have an additional IP. So they set up a new IP and said: "The config looks ok, so everything should work". Well, it didn't, and since they are all on holiday now, you guys are my best hope :-) Cheers, and thanks for helping!
    – DavidS
    Jul 17, 2012 at 9:26
  • When you run 'netstat -an|grep :80' what do you get? Have you restarted apache since the new ip was added? What errors do you get when you try and access sub2.example.com? Jul 17, 2012 at 12:52

2 Answers 2

1

For starters, make sure you have something to the tune of this in your config:

NameVirtualHost *:80  
NameVirtualHost *:443

As mentioned in the remarks, I guarantee you that while every unique SSL vhost needs it's own IP Address, you CAN have as many non-SSL (ala port 80) vhosts on any one of those IP's.

The problem you are more than likely coming up against is the way Apache's default mod_ssl config file is set up.

On CentOS it should be in /etc/httpd/conf.d/ssl.conf.

You'll see that for some reason, Apache (CentOS?) has a pre-configured SSL vhost using _default_ in that file - versus a sample at the bottom of httpd.conf, or an entry in sites-available on Debian systems...

I'd wager that this is why your initial SSL config never worked in the first place because it was doubling up on the same IP (default) that's configured using the default SSL vhost in that default ssl.conf file.

Typically when I set up a new CentOS Apache box, I comment out the entire VirtualHost entry in that file and place the config I want alongside all of the others in httpd.conf.

1
  • Apache isn't loaded with mod_ssl actually, and there does not exist any ssl.conf files. Our supplier has most likely done something really weird to get SSL to work. However, I copied the NameVirtualHost directives (replaced * with the actual IPs), but with no luck.. When I try to access HTTP sub2.example.com I actually get redirected to HTTPS sub2.example.com. That is not supposed to happen.. Will investigate further! Thanks for helping :)
    – DavidS
    Jul 18, 2012 at 9:04
0

I managed to get it working by creating another vhost directive for sub1.example.com, which listens on port 80.

My guess is that our supplier has made a hack somewhere, that redirects all requests from the first IP to HTTPS. That's clearly the reason why we needed an extra dedicated IP.. What is a bit strange, is that the sub1.example.com directive that listens on port 80 doesn't do a thing, besides making sure that the requests dont go to sub2.example.com. Users that access sub1.example.com through HTTP are redirected to HTTPS (somewhere..).

It works :)

NameVirtualHost *:80
NameVirtualHost *:443

# sub1.example.com PORT 80
<VirtualHost *:80>
    ServerName sub1.example.com
    DocumentRoot /var/www/sub1

    <Directory "/var/www/sub1">
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

# sub1.example.com SSL
<VirtualHost *:443>
    ServerName sub1.example.com
    DocumentRoot /var/www/sub1

    <Directory "/var/www/sub1">
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

# sub2.example.com PORT 80
<VirtualHost *:80>
    DocumentRoot /var/www/sub2
    ServerName sub2.example.com

    <Directory "/var/www/sub2">
        AllowOverride All
        Order Allow,deny
        Allow from all
    </Directory>
</VirtualHost>
4
  • FYI - That's not actually an SSL configured vhost; not sure if the end objective is to have apache merely listening on :443, or if it's meant to be a valid SSL(https) vhost.
    – thinice
    Jul 18, 2012 at 12:18
  • It is valid, we just dont utilize mod_ssl. I dont have all the information on how the SSL got solved, when we do have a working ssl connection (with a valid certificate). It is our server provider who set it up, and has just caused headaches, at least for me..
    – DavidS
    Jul 18, 2012 at 17:19
  • @DavidS It's not valid, because you are using 443 as a plaintext HTTP port. The first https: URL that you try to the Apache server will fail. However it will work provided the /var/www/sub1/.htaccess file contains the required SSL directives. Not a good assumption, they should be here as well, as least enough to turn SSL on.
    – user207421
    Aug 1, 2012 at 0:59
  • It turns out that we have a load balancer which routes every request to our server. The balancer also redirects every request to the "SSL IP" to HTTPS sub1.example.com. That's why we needed a new IP to get our sub domain to work, because the load balancer did not check whether or not people where accessing different sub domains.
    – DavidS
    Aug 2, 2012 at 5:59

You must log in to answer this question.

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