httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif W <>
Subject Re: [users@httpd] Redirecting http traffic to an https virtual host
Date Mon, 20 Dec 2004 16:45:51 GMT
> Peter Clark; Mon, 20 Dec 2004 10:08:36 AM EST
>     I have been reassured by the documentation that this is an easy problem,

> but for some reason I'm not having much luck. I'm running Apache 2.0.52 on 
> Debian Sarge, and I want to use Squirrelmail with SSL.

I've had a similar configuration, except no Squirrelmail, and I compiled the
Apache httpd -- I didn't use the Debian package.  I don't see any problem

> No problems running
> Squirrelmail at https://webmail.mydomain.tld. But what I want is for all 
> requests to http://webmail.mydomain.tld to be redirected to https://. Here's

> where I run into trouble.

I've done the same redirection, and it's easy.  I'll explain.

> /etc/apache2/httpd.conf has the line 
> "NameVirtualHost" and I have the virtual domain for 
> webmail.mydomain.tld stored in /etc/apache2/sites-available/webmail:

I'd say ALWAYS include the IP:port pair, in EVERY Listen, NameVirtualHost,
VirtualHost, and ServerName line, if you want anything to work reliably. 
NEVER put a host name in VirtualHost, because it has to do a lookup for the IP




There's no need to use NameVirtualHost for because... short
answer: just because; long answer: NAME BASED Virtual Hosting doesn't work
with encryption, because the Host header, containing the name, is encrypted,
so there's no basis.  The VirtualHost container is chosen soley by matching a
unique IP:port pair.  This implies only one "default" (port 443) https site
can exist per IP.  Additional https sites are possible on the same IP if you
use other ports besides 443.  This is one reason why you should really use
IP:port everywhere possible.

> ---
> /etc/apache2/sites-available/webmail:
> <Directory /var/www/webmail>
>   php_flag register_globals off
>   Options Indexes FollowSymLinks
>   <IfModule mod_dir.c>
>     DirectoryIndex index.php
>   </IfModule>
> </Directory>

I don't see anything broken here.  It looks sparse, so I am guessing it was
pruned for the post?  And why is the directory all by itself in a file?  Is it
Included elsewhere?  Maybe Debian sets this up differently...

> # users will prefer a simple URL like
> <VirtualHost webmail.mydomain.tld:443>
>   SSLEngine on
>   SSLCertificateFile /etc/ssl/mydomain.tld/Cert.pem
>   SSLCertificateKeyFile /etc/ssl/mydomain.tld/PrivateKey.pem
>   DocumentRoot /var/www/webmail
>   ServerName webmail.mydomain.tld
>   ServerAdmin postmaster@mydomain.tld
> </VirtualHost>

Weird, I don't see the directory defined above Included here.  If you define
the directory globally as above, it will be available to all other sites,
which is usually not the desired intent when doing virtual hosting. 
Specifically you probably don't want non-https access.  Oh yeah, put
ServerName webmail.nmydomain.tld:443 to match the VirtualHost, and VirtualHost to avoid additional redundant DNS queries.

> <VirtualHost webmail.mydomain.tld:80>
>   ServerName webmail.mydomain.tld
>   Redirect permanent / https://webmail.mydomain.tld
> </VirtualHost>

Change to VirtualHost and ServerName webmail.mydomain.tld:80.  I've
used RedirectPermanent, which is an alternative syntax, but achieves exactly
the same thing with 1 less "space".  ;-)  Furthermore, I would add a trailing
slash to the https target.  Since you are using port 443, I think it should
work.  But you might try experimenting by explicitly specifying :443. 
Finally, I always put any SSL related stuff inside an IfDefine SSL, and
configure a safe fallback, in case something goes wrong with the SSL and you
have to bring it down temporarily.

<IfDefine SSL>
# Try in this order, pick one to uncomment
#Redirect permanent / https://webmail.mydomain.tld/
#Redirect permanent / https://webmail.mydomain.tld:443/
# Alternate Syntax
#RedirectPermanent / https://webmail.mydomain.tld/
#RedirectPermanent / https://webmail.mydomain.tld:443/
<IfDefine !SSL>
# Do something safe, like redirect everything to a pretty fail page
# that explains the nature of the problem.  Need to use a very simple
# rewrite for this.
#RewriteEngine On
#RewriteRule !^/ssl_error.html$ http://webmail.mydomain.tld/ssl_error.html
# or [R=302] or [R=temp]

> ---
>     If I have /etc/apache2/sites-available/webmail set up like this, I get
> following error when trying to start Apache:
> ---
> Starting web server: Apache2[Mon Dec 20 14:44:46 2004] [error] VirtualHost 
> webmail.mydomain.tld:80-- mixing * ports and non-* ports with a 
> NameVirtualHost address is not supported, proceeding with undefined results
> [Mon Dec 20 14:44:46 2004] [error] VirtualHost webmail.mydomain.tld:443 -- 
> mixing * ports and non-* ports with a NameVirtualHost address is not 
> supported, proceeding with undefined results  
> ---

Hopefully I explained this above.  It tells you that you're mixing IP:port (80
and 443) with IP (which defaults to IP:*).  The hostname instead of IP in the
VirtualHost may add to confusion.

> However, if I comment out the "<VirtualHost webmail.mydomain.tld:80>" and 
> following lines, and change "<VirtualHost webmail.mydomain.tld:443>" to 
> "<VirtualHost webmail.mydomain.tld>", traffic to http://webmail.mydomain.tld

> isn't redirected.
>     I also tried putting an .htaccess file in /var/www/webmail (which is a 
> symbolic link to /usr/share/squirrelmail, Squirrelmail's home directory)
> the following contents:

I'd personally avoid using symbolic links in general, and especially not to
solve a configuration error.

> ---
> DirectoryIndex index.php
> <IfModule mod_rewrite.c>
>         RewriteEngine On
>         RewriteCond %{SERVER_PORT}      !^443$
>         RewriteRule ^(.*)$      https://%{SERVER_NAME}/webmail/$1 [L,R=303]
> </IfModule>

A rewrite rule will work, but a simple redirect is much cheaper and just as

> ---
> But still traffic isn't redirected. I've checked that mod_rewrite is
> So what obvious thing am I missing?

If you have IP:port errors, fix those first.  Try checking syntax, but it's no
guarantee: (apachectl configtest) catches some major things, but lets many
more through.  Then the next test is to start the server and watch those error
logs.  The next test is when you get no errors on startup, but runtime
configuration errors when hitting a URL.   The final test is when you see
unexpected results with no server errors.  :-)  Fix what's wrong first, then
sometimes the other errors may simply disappear.  Don't forget the trailing /


The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message