SSL IP Virtual Host problem

jonakoudijs

Verified User
Joined
Apr 4, 2013
Messages
8
I encountered a problem with the customers that use SSL. Every SSL customer has a owned IP-adres. Everything works fine. The only problem is the VirtualHost from a SSL customer is also used when typing in the IP-adres in the browser (instead of the url). Also an old DNS record (not controlled) by us points the DNS to that IP-adres and now the website is shown from a different url but with the exact same content, this is really bad for our SEO.

Does anyone know a good fix for this, that for example if the Name in the VirtualHost doesn't match, it just shows the default /var/www/html page.
 
I'm not 100% sure of the problem. Do you mean the IP# has changed but DNS is still pointing to the old IP#? If so, this needs to be fixed, so viewers will get to the page they're looking for.

Or am I misunderstanding something?

But to answer your question: probably not, but you might be able to get help on an apache-specific forum.

Jeff
 
Ssl

Thank you Jeff for you reply.
No not really. I have a few customers with SSL (with their own, owned IP-adress). The problem is that when someone (not our customer or us) points his DNS records to an owned IP, you see that specific website while the domain is not added in Directadmin. Apache uses the VirtualHost that has that specific IP in it. The problem we have now is that someone (we don't know who) point his domain to an owned IP-adres of a customer. Now the website can also be viewed from that unknown domain, this is really bad for our SEO.

I was thinking to add the following to the SSL template to the top:

"<VirtualHost [OWNED IP]:80 [DEFAULT IP]:80 >
DocumentRoot /var/www/html
UseCanonicalName OFF
</VirtualHost>

I tested this, this weekend and it worked.
Now if you typ in a domain other that the one that belongs to the customer you get the default placeholder page (/var/www/html).

You think this is a good idea or do you have other suggestions?

I'm not 100% sure of the problem. Do you mean the IP# has changed but DNS is still pointing to the old IP#? If so, this needs to be fixed, so viewers will get to the page they're looking for.

Or am I misunderstanding something?

But to answer your question: probably not, but you might be able to get help on an apache-specific forum.

Jeff
 
Now I understand. You know better than I, of course, because you've tested. So the question now is if DirectAdmin can make it standard? For SSL only? Hopefully they can.

I never worried about it; I never thought of it as an SEO issue, but I see that I can be.

The part of your solution with which I'm not yet familiar is why you feel it's important only for SSL.

And of course the change must only be in templates for dedicated-IP sites.

Once you've replied I can convert the thread to a feature request.

Jeff
 
Feature Request

Hey Jeff,

I am sorry for my late reply, I was on holiday and haven't touched the internet in weeks.
Now I did the following:

# cd /usr/local/directadmin/data/templates
# cp virtual_host2.conf custom
# cp virtual_host2_secure.conf custom

and this paste this in the virtual_host2.conf on the top, below the Variables:

<VirtualHost |IP|:|PORT_80| >
DocumentRoot /var/www/html
</VirtualHost>



and this paste this in the virtual_host2_secure.conf on the top, below the Variables:

<VirtualHost |IP|:|PORT_443| >
DocumentRoot /var/www/html
SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
</VirtualHost>



I know this includes changes to all vhosts, but it was the best way I could think of at the moment. Also we don't have many users per server so it does not impact usage (much).
Besides that it would be great to have this included in DirectAdmin; making vhosts with dedicated IP's only available to the domain name that goes with it.

Thank you for your help.

With kind regards,

Jona Koudijs



Now I understand. You know better than I, of course, because you've tested. So the question now is if DirectAdmin can make it standard? For SSL only? Hopefully they can.

I never worried about it; I never thought of it as an SEO issue, but I see that I can be.

The part of your solution with which I'm not yet familiar is why you feel it's important only for SSL.

And of course the change must only be in templates for dedicated-IP sites.

Once you've replied I can convert the thread to a feature request.

Jeff
 
However,

Won't this make it impossible to use IP# access direct to sites with dedicated IP#s? I kind of like the idea of being able to work on a dedicated IP# site before it propagates. I'm thinking this would prevent it.

What other methods will still work for access before propagation?

Comments, anyone, on how important this feature might be?

Jeff
 
host file

That is true, but that same fact is also what is causing my problem that is accesable through other domains (that point to the same IP). If you want to do this you can edit your host file or go to: [ip] / ~ [username]. That still works.


However,

Won't this make it impossible to use IP# access direct to sites with dedicated IP#s? I kind of like the idea of being able to work on a dedicated IP# site before it propagates. I'm thinking this would prevent it.

What other methods will still work for access before propagation?

Comments, anyone, on how important this feature might be?

Jeff
 
Solved

If anyone has this same issue I implemented a work around (it's tested and running in our prod environment).
It goes something like this:

Make the virtual host templates:
1. # cd /usr/local/directadmin/data/templates
2. # cp virtual_host2.conf custom
3. # cp virtual_host2_secure.conf custom
4. add the following between the VARIABLES and VHOST part in virtual_host2.conf:
Code:
<VirtualHost |IP|:|PORT_80| >
        DocumentRoot /var/www/html
</VirtualHost>
5. add the following between the VARIABLES and VHOST part in virtual_host2_secure.conf:
Code:
<VirtualHost |IP|:|PORT_443| >
        DocumentRoot /var/www/html
        SSLEngine on
        SSLCertificateFile |CERT|
        SSLCertificateKeyFile |CERT|
</VirtualHost>
6. After editing obviously save both files.
7. Then rebuild the (vhost) configs through Directadmin:
# echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

I know it is not perfect because there will be generated a lot of unused vhosts, but we didn't notice any increase of load because of it.


EDIT 27-09-2013:

We are still expecting some weird behavior if you edit a vhost in DirectAdmin. In one scenario we were getting SSL errors on the server which caused HTTP to refuse to start!
 
Last edited:
Back
Top