SSL and vhosts

[jeffshead]

First off, I am using Web-Developer Server Suite v1.95. I am using this version because I am using some scripts (can’t remember what they are at the moment) that need mod_perl. I would love to upgrade to the latest paid version, but I am pretty sure I need mod_perl for those scripts, but it looks like Apache 2.2.6 does not support mod_perl.

1. Is there a way to use those scripts with Web.Developer Server Suite v3.0?

The main reason for my post is to find out why my server is behaving as described below. Let me start by describing my set up.

I have two domains and two separate SSL certs. (e.g. www.mysite1.com, www.mysite2.com)
I have added the following in my 'www\Apache22\conf\extra\httpd-vhosts.conf' file as well as other subdomains:

Code:

<VirtualHost *:80>
   DocumentRoot /www/webroot/
   ServerName localhost
</VirtualHost>
######################################
<VirtualHost *:80>
ServerName mysite1.com
DocumentRoot E:/htdocs/mysite1.com
ScriptAlias /cgi-bin/ "C:/www/cgi-bin/"
ScriptAlias /fcgi-bin/ "C:/www/fcgi-bin/"
ServerAlias www.mysite1.com
ServerAdmin webmaster@mysite1.com
<Directory E:/htdocs/mysite1.com>
Options IncludesNOEXEC
Order allow,deny
Allow from all
AllowOverride All
</Directory>
</VirtualHost>
######################################
<VirtualHost *:80>
ServerName mail.mysite1.com
DocumentRoot E:/htdocs/mail.mysite1.com
ScriptAlias /cgi-bin/ "C:/www/cgi-bin/"
ScriptAlias /fcgi-bin/ "C:/www/fcgi-bin/"
ServerAdmin webmaster@mysite1.com
<Directory E:/htdocs/mail.mysite1.com >
Options IncludesNOEXEC
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
######################################
<VirtualHost *:80>
ServerName mysite2.com
DocumentRoot E:/htdocs/mysite2.com
ScriptAlias /cgi-bin/ "C:/www/cgi-bin/"
ScriptAlias /fcgi-bin/ "C:/www/fcgi-bin/"
ServerAlias www.mysite2.com
ServerAdmin webmaster@mysite2.com
<Directory E:/htdocs/mysite2.com>
Options IncludesNOEXEC
Options FollowSymLinks
Order allow,deny
Allow from all
AllowOverride All
</Directory>
</VirtualHost>
######################################
<VirtualHost *:80>
ServerName support.mysite2.com
DocumentRoot E:/htdocs/support.mysite2.com
ScriptAlias /cgi-bin/ "C:/www/cgi-bin/"
ScriptAlias /fcgi-bin/ "C:/www/fcgi-bin/"
ServerAdmin webmaster@mysite2.com
<Directory E:/htdocs/support.mysite2.com>
Options IncludesNOEXEC
Options FollowSymLinks
Order allow,deny
Allow from all
AllowOverride All
</Directory>
</VirtualHost>

I have added the following in my 'www\Apache22\conf\extra\httpd-ssl.conf' file:

Code:

<VirtualHost 192.168.0.101:443>
ServerName mysite1.com
DocumentRoot E:/htdocs/mysite1.com
ScriptAlias /cgi-bin/ "C:/www/cgi-bin/"
ScriptAlias /fcgi-bin/ "C:/www/fcgi-bin/"
ServerAlias www.mysite1.com
ServerAdmin webmaster@mysite1.com
SSLEngine On
SSLCertificateKeyFile "C:/www/Apache22/conf/ssl.key/www.mysite1.com.key"
SSLCertificateFile "C:/www/Apache22/conf/ssl.crt/www.mysite1.com.crt"
<Directory E:/htdocs/mysite1.com>
Options IncludesNOEXEC
Order allow,deny
Allow from all
AllowOverride All
</Directory>
</VirtualHost>
######################################
<VirtualHost 192.168.0.102:443>
ServerName mysite2.com
DocumentRoot E:/htdocs/mysite2.com
ScriptAlias /cgi-bin/ "C:/www/cgi-bin/"
ScriptAlias /fcgi-bin/ "C:/www/fcgi-bin/"
ServerAlias www.mysite2.com
ServerAdmin webmaster@mysite2.com
SSLEngine On
SSLCertificateKeyFile "C:/www/Apache22/conf/ssl.key/www.mysite2.com.key"
SSLCertificateFile "C:/www/Apache22/conf/ssl.crt/www.mysite2.com.crt"
<Directory E:/htdocs/mysite2.com>
Options IncludesNOEXEC FollowSymLinks
Order allow,deny
Allow from all
AllowOverride All
</Directory>
</VirtualHost>

For some reason, I could not access 'mysite2.com' via "https://www.mysite2.com" until I added "FollowSymLinks" to the 'Options' directive of '<VirtualHost 192.168.0.102:443>' in 'httpd-ssl.conf'. I did not have to add "FollowSymLinks" to the domain 'mysite1.com'. I could access it via "https://www.mysite1.com" just fine.

2. Any ideas as to why I had to add "FollowSymLinks" to one domain but not the other?

I can access any subdomain of 'mysite1.com' via https (e.g. https://mail.mysite1.com, https://www2.mysite1.com). Of course I get the IE7 warning about the SSL cert name not matching, but I can gain access.

When I try to access any subdomain of 'mysite2.com' via https, I get the following 403 error:

"You don't have permission to access / on this server."

3. Any ideas?

Now for the main reason of this post… I just added a shopping cart to my 'mysite2.com' site and this cart has a very feature rich backend which includes "one click" setup for secure access to certain parts of the site such as the admin area and checkout. When I try to enable SSL (via the cart's admin panel) for these areas, it fails. I can access pages via https in this domain, but not the subdomains as I mentioned earlier. I have been in contact with their support department, but they are telling me it is a server configuration issue.

4. Can you tell me what I have done wrong?

As I said earlier, I would like to upgrade to the latest version, but I fear I will "break" my web sites because mod_perl is no longer supported.

Sorry for the long post. I tried to keep it concise.

[admin]

Some of the things that I spot are...

1. All your sub domains are for http only, not for https, as they are all under port 80 VHs.

2. Make sure you have not used a wildcard for the port number under NameVirtualHost.

Any ideas as to why I had to add "FollowSymLinks" to one domain but not the other?

If anything used an .htaccess file with rewrite rules within under that domain it would not have worked without followsymlinks. Aside from that, I have no idea.

I would like to upgrade to the latest version, but I fear I will "break" my web sites because mod_perl is no longer supported.

Usually, mod_perl is just a convenience to have. Scripts should run find without it. Though I'm not a perl guy so this is all IMO.

[jeffshead]

Thank you.

Usually, mod_perl is just a convenience to have. Scripts should run find without it. Though I'm not a perl guy so this is all IMO.

I’m not an anything guy (still learning) so I don’t know exactly what mod_perl does.

1. Without it, how do perl scripts run? They must interface in a different way which would presumably be faster, slower, more or less secure. I do however remember one or more of my Perl scripts requiring mod_perl.

1. All your sub domains are for http only, not for https, as they are all under port 80 VHs.

I did have them in my 'httpd-ssl.conf' file. It did not make any difference. The '*.conf' files in my previous post are just excerpts. Not the entire file. What's really confusing me is how this issue is affecting the second domain, but not the other. I do not have the subdamains of 'mysite1.com' in the 'httpd-ssl.conf' file, but I can still access those subdomains via https. Not true for the second domain.

I am really considering upgrading to v3 since viewing the video that shows how easy it is to up domains and subdomains. At the end of the video, it mentions resolving the domains via DNS or the Windows HOSTS file.

2. Does this mean there are no entries added to the Apache vhosts config file? If not, what if a domain or subdomain requires special directives?
3. How is SSL set up if the admin no longer has to manually set up vhosts?
4. How would one resolve via DNS?
5. What would an entry in the HOSTS file look like and does that mean Windows is now resolving and Apache is not?
6. What happens if a user does not add "www." to the beginning of the URL (e.g. mysite.com vs. www.mysite.com) when they type into their browser? Do they simply get served whatever documents are in the parent directory of “mysite.com”?

[admin]

1. mod_perl just makes perl scripts a bit faster to load and execute. Without it, perl scripts are executed directly with the perl cgi binary. If you did not configure mod_perl, you probably are not even using it right now. [I don't recall the old setup]

2. No config updates or directives are required.

3. The dynamic domains only work for http, for https you would still need to setup VirtualHosts manually.

4. If you have a static IP address and a domain name, you usually would be able to resolve that domain to that IP via your registrar or your hosting provider; using their DNS system/nameservers. The other option is to run your own DNS Server.

5. Apache does not resolve domains to IPs. That is the job of a DNS Server. Apache just listens on IP addresses/interfaces, and if a request comes in that it can handle, it handles it. An entry in the hosts file looks something like...

Code:

127.0.0.1 example.com
127.0.0.1 www.example.com
127.0.0.1   blog.example.com
127.0.0.1   wiki.example.com
127.0.0.1   forums.example.com

...which will cause your local Windows copy to resolve those domains to 127.0.0.1 without querying DNS. Its really good for testing and doing local only work.

6. The default setup is to redirect all requests for base domain to www. This can be changed by removing a few lines from httpd-vhosts.conf and creating a '_' [underscore] sub-folder that will now be next to the www, blog, etc, folders and will server base domain.

[jeffshead]

Wow, you are fast!

I think I am going to make my purchase over this weekend. I need to sort some things out first and still need a little clarification.

A. I still don't understand how the dynamic domains work if you do not have to edit the vhosts config file. Can you give me a short rundown on how Apache knows what domain/subdomain to serve a page from? I always thought there had to be vhost containers in order for Apache to know what page to serve.

B. How does Apache distinguish regular directories from subdomain directories when using dynamic domains? In an example on your Web site, you have the following:

URL: http://forums.example.com/  Folder: example.com\forums\

What if I want the following URL: http://example.com/forums What would the folder be?

C. What about setting up directory authentication? Is there a .conf file already included for directory directives?

Thanks again,

Jeff

[admin]

A. I still don't understand how the dynamic domains work if you do not have to edit the vhosts config file. Can you give me a short rundown on how Apache knows what domain/subdomain to serve a page from? I always thought there had to be vhost containers in order for Apache to know what page to serve.

The dynamic domains feature uses a mass vhost module that is configured to search for a specific folder structure at runtime. The main configuration for this module is located within httpd-vhosts.conf and you can fine tune it if you wish.

B. How does Apache distinguish regular directories from subdomain directories when using dynamic domains? In an example on your Web site, you have the following:

URL: http://forums.example.com/  Folder: example.com\forums\

What if I want the following URL: http://example.com/forums What would the folder be?

If you wanted www.example.com/forums the dir structure would be C:\www\vhosts\_dynamic\example.com\www\forums
If you made the necessary adjustments to not redirect to www, that same dir structure would now be C:\www\vhosts\_dynamic\example.com\_\forums

Basically, any folder you create under the base domain folder is a sub-domain, and anything within those sub-domain folders are URL paths.

C. What about setting up directory authentication? Is there a .conf file already included for directory directives?

You can create an .htaccess file either under the base domain folder, its sub-domain folders, or folders within. .htaccess functionality is enabled for all dynamic domains.

If you need something more elaborate than .htaccess, you can also include a global *.conf to be shared/loaded for all dynamic domains. If you need something a bit more individual/refined, you can also create static domains/ VHs...

There are three types of VHs in the new Suite:
\www\vhosts\localhost
\www\vhosts\_dynamic [completely dynamic]
\www\vhosts\_static [will require a new VH block under httpd-vhosts.conf]

[jeffshead]

I currently have all of my document roots on a seperate drive.

It looks as if Web.Developer Server Suite v3.0 is set up to have the document roots on the C: drive.

A. If I upgrade to Web.Developer Server Suite v3.0, can I still have my Web folders on a seperate drive?
B. If so, exactly what will I need to edit and will I still be able to use the dynamic domains feature?
C. Is there a performance hit for using the dynamic domains feature?
D. When using dynamic domains, can I specify a seperate access and error log for each domain or will I have to make them static Vhosts?.

Is there any type of user guide which will tell me what I should do and what files I should edit if I need to add specifics to my vhosts? The maybe I can answer most of my own questions and not bother you.

[admin]

A. Yes, if you change the configuration.

B. You can still use the dynamic domain feature as long as you edit \www\Apache22\conf\extra\httpd-vhosts.conf and update all the paths you see from either '/www/vhosts', or 'C:/www/vhosts' to your other location. This goes for any 'DocumentRoot', 'Directory', and 'Virtual...' lines and paths in this file.

You will also need to edit httpd.conf to update the main DocumentRoot and Directory "/www/vhosts/localhost" line.

There will be other files affected by this that will also need path changes.

extra\httpd-ssl.conf
extra\suite-global\suite-cgi.conf,suite-php5.conf
extra\other\suite-aspdotnet-example.conf [if you ever use it]
extra\vhosts\localhost\suite-private.conf

The most important thing to do here is to rename the original \www\vhosts\ directory, that way you can run 'httpd -t' to check the configuration and Apache will give you the next problem line and file name if you miss a path.

C. No, at least nothing that would be noticeable.

D. All dynamic domains share the same access and error log. This is a limitation of the mass vhost module. On the other hand, the log lines do start with the specific Virutal Host of the request.

The Suite Guide under /support has some info that you might find relevant. The Suite also comes with several example VH configurations under httpd-vhosts.conf -- simple static with no subdomains, smart static with auto subdomains. httpd-vhosts.conf is probably where you will do all your work.

[make sure to backup your old mysql database, your webroots, and any configurations you might want to keep before uninstalling the old suite and installing the new, and place them outside 'www' as some of the older Suite's uninstalls deleted the main www dir on final exit.]

[jeffshead]

Well, I'm in the proccess of backing everything up. I already purchased and downloaded Web.Developer Server Suite v3.0.

My CGI folder is currently outside of the document root. I see v3 puts them in the document root. Is this as secure?

[admin]

The "_cgi-bin" folders are all outside of the perceived DocumentRoot... In example, for localhost:

We have C:\www\vhosts\localhost\_ which represent URL 'localhost'
We have C:\www\vhosts\localhost\blog which represents URL 'blog.localhost'
We have C:\www\vhosts\localhost\_cgi-bin which represents URL 'localhost/cgi-bin' [and also blog.localhost/cgi-bin, wiki.localhost/cgi-bin, and all other subdomains: cgi-bin is shared among all sub-domains]

The _cgi-bin folder is not reachable via URL, only via it's alias of URL /cgi-bin.

Remmember that with dynamic domains [and localhost, and example VH 'smarthost'], the main domain folder is not really a DocumentRoot, but rather a container for base domain ['_' folder], www.domain ['www' folder], any other sub-domains, and some aliases like /cgi-bin.

[I'm going to move this thread into the Pro forum.]

[admin]

A clarification:

That is only for localhost and dynamic domains. Anything else will use suite-cgi.conf which enables cgi for all 'cgi-bin' folders. So yes, that would be inside DocumentRoot. But that is also okay as it's not much of a security risk.

[jeffshead]

I still have the same issue as in this thread:
http://forums.devside.net/index.php?topic=1611.msg7977

I followed your instructions and put all directory blocks that require authentication outside of any virtual host, in a seperate *.conf file.

Same results as before.

Any ideas?

[admin]

Was that the problem when you redirect from http to https to authenticate and you get the authentication routine twice? But if you go directly to https everything is fine?

Looking at the documentation for all this...
http://httpd.apache.org/docs/2.2/mod/mod_authz_groupfile.html#authgroupfile
http://httpd.apache.org/docs/2.2/mod/mod_authn_file.html#authuserfile
http://httpd.apache.org/docs/2.2/howto/auth.html

I would test this: Comment out the AuthGroupFile part and use 'Require valid-user'. Restart Apache. Probably won't help but just a wild guess.

Here is something I've come across...
http://www.webmasterworld.com/linux/3180571.htm

Maybe its as simple as adding a '/' to the end of your redirect code.

[admin]

When do the authentication prompts happen? Once before redirection, once after?

[admin]

I also see this as a problem since you are redirecting in php code, and any authentication routines will happen long before that code is parsed.

Instead of using php code to redirect, create an .htaccess file under the directory that is protected, with this code...

Code:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Make sure that when you link to this directory in html, always have an ending '/' on it.

I think that would fix it.