httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leif W" <>
Subject Re: [users@httpd] Help!: Error 400 when setting up Virtual Host
Date Fri, 05 Sep 2003 14:18:16 GMT
----- Original Message ----- 
From: "Brian Dessent" <>
To: <>
Sent: Friday, September 05, 2003 5:41 AM
Subject: Re: [users@httpd] Help!: Error 400 when setting up Virtual Host

> >   Right now I don't require any SSL but I would like to know what went
> > with my ssl.conf. I might require SSL in future.  (my original ssl.conf
> > attached). Kindly advise.

Basically, I just went through the ssl.conf file, copied every default line
that was not commented out, pasted into my VirtualHost section, and wrapped
the secure VirtualHost sections in <IfDefine SSL>.  It's working fine for a
simple test site with self-signed certificate.  See EXAMPLE 1 below.  Note
that this example uses non-standard HTTPS ports 4300+, because I have only
one IP address, and using SSL for VirtualHosts requires a unique IP:port
pair.  The other option is to have a single shared certificate running on with different domains accessible by the next
portion of the path, i.e. .


# Regular port 80 VirtualHost sections here, followed by the secure

<IfDefine SSL>
Listen 4300
NameVirtualHost *:4300
<VirtualHost *:4300>
    ServerName site1
    ServerAdmin e@mail.addr
    CustomLog "/path/to/site1/logs/site1-access.log" common
    ErrorLog "/path/to/site1/logs/site1-error.log"

    DocumentRoot "/path/to/site1/public_html"
    <Directory "/path/to/site1/public_html">
        Options None
        AllowOverride AuthConfig
        Order allow,deny
        Allow from all

    SSLEngine on
    SSLCertificateFile /path/to/site1/ssl/site1.crt
    SSLCertificateKeyFile /path/to/site1/ssl/site1.key
    <Files ~ "\.(cgi|php|php3|phtml|shtml)$">
        SSLOptions +StdEnvVars
    <Directory "/path/to/site1/cgi-bin">
        SSLOptions +StdEnvVars
    SetEnvIf User-Agent ".*MSIE.*" \
        nokeepalive ssl-unclean-shutdown \
        downgrade-1.0 force-response-1.0
    CustomLog "/path/to/site1/logs/site1-ssl.log" \
        "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"


Listen 4301
NameVirtualHost *:4301
<VirtualHost *:4301>
    ServerName site2

    # options like above, with site1 paths changed to site2 paths


> That aside, since you're using name-based virtual hosting you may need
> to change the SSL vhost to "*:443" instead of "_default_:443", I'm not
> sure if that makes a difference or not.  You'd also have to set the
> "ServerName" correctly inside that vhost section, etc.

I think the _default_ differs from the *.  I forget how, exactly, but I
think the * matches any IP (for me, on a network behind a firewall,
internally I may access the site from, 192.168.M.N, or someone
externally may access it fron W.X.Y.Z, so I needed the * to catch them all),
while the _default_ wasn't working for me.

> If you want to do this, I am positive there is a nice HOWTO that walks
> one through creating a self-signed certificate and setting up a server
> for SSL.  The caveat with going self-signed is that every browser will
> pop up a warning box when connecting because a self-signed certificate
> really isn't very trustworthy at all: "Trust me, I'm who I say I am."  I
> think that's why the Apache docs refer to this as the "snake oil"
> method.
> Brian

Snake oil, indeed.  Only to be used for testing or development purposes, not
for production sites.  Arguably, though, even the valid certs are snake oil.
Think, it's only strengthening one link in the chain.  The data may have
been transmitted securely, but is it stored securely?  Is it archived
securely?  Is it transmitted to others securely?  By itself it's no
guarantee of data security.  But it is a useful tool to strengthen perhaps
the weakest link of data transmission.  That said, I'll reiterate, this
self-signing process is not for production sites.  It's very easy to set up
certificates, self-signed or valid CA signed.


1) cd /path/to/site; mkdir ssl; chown root.root ssl; chmod 700 ssl; cd ssl
2) openssl genrsa -des3 1024 >
3) openssl req -new -key >
4) openssl req -x509 -days 365 -key -in >
5) chown root.root *; chmod 400 *


1) /path/to/site assumes a similar hierarchy as this (note that this is one
level above the web area of public_html and cgi-bin)

        |--- cgi-bin
        |--- logs
        |--- private
        |--- public_html
        |--- ssl

2) Generate the server's private key.  If for a production site, do not
loose this file or let it fall into the wrong hands or you loose money,
because you'll have to buy a new certificate.  That's why I have the
directory owned by root.root and set chmod 700 in step 1), and all files we
create owned by root.root and chmod 400 in step 5).  Also note: if you
specify the -des3 option, your certificate will be further encrypted with a
pass phrase.  A caveat to this, whenever you apachectl startssl, you will
have to enter this pass phrase.  There's no option (that I'm aware of at the
time of writing), to specify the passphrase in any automated way.  This
means, for instance, that if you're running a production site, and you
reboot the server, your apachectl startssl will HANG, waiting for input, and
may potentially not run the rest of the scripts init would run on startup.

3) This step generates the CSR (certificate signing request), which is the
file you would normally send to a CA (VeriSign, Thawte), or which you
yourself can use to sign your own certificate.

4) This step generates a self-signed certificate.  This is what you pay $200
or $400 or $800 for, the company runs this command with their key and your
CSR, that's it.  Oh, and paying for the year's worth of security to keep
their key secure.  This is snake oil, IMHO.  ;-)

5) Just to make sure these files are kept as secure as possible.  Apache
reads all SSL certs and keys on startup when it is still root, so it doesn't
matter if you have User and Group set to nonroot (as they should be).


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