Apache + SSL Howto

SiegeX · 08-01-2004, 08:00 PM

Ive been reading a few posts about how to set up SSL on apache. In case you didnt know SSL allows you to have secure encrypted data sent to and from your webserver. If you ever do online banking and notice all the URL's start with https:// and have a lockpad symbol on the browser, well thats SSL.

To setup SSL with the Apache server supplied with Slack10/9.1 is fairly easy but there are a few steps that arn't so intuitive so this faq should have you set up in no time.

In order to tell Apache to include SSL support we need to edit the /etc/apache/httpd.conf file and scroll ALL the way to the bottom. This is where we will uncomment the following line.

Code:

change this:
#Include /etc/apache/mod_ssl.conf

to this:
Include /etc/apache/mod_ssl.conf

Once that is done you need to make a simple edit to the /etc/rc.d/rc.httpd file so that the apache server knows you want to startup with SSL support.

Code:

change this:
'start')
      /usr/sbin/apachectl start ;;
to this:
'start')
      /usr/sbin/apachectl startssl ;;

Now all thats left is to setup the SSL Certs. If you really dont care about having offical certs, Slackware comes with pre-made ones, I use these, but if you ran a legit production webserver you would probably want to spend the money and have real certs made. You also have the option to create your own self-signed certs and if you are interested in that, jump all the way to the bottom of this Howto. Anyway, to use the premade certs run the following commands and say yes to overwrite:

Code:

cp /etc/apache/ssl.crt/snakeoil-rsa.crt /etc/apache/ssl.crt/server.crt
cp /etc/apache/ssl.key/snakeoil-rsa.key /etc/apache/ssl.key/server.key

Now all thats left to do is restart the apache server:

Code:

/etc/rc.d/rc.httpd restart

If you want to make sure that SSL is working correctly run this command:

Code:

netstat -tpan | grep 443

If everything is working correctly, you should get output that looks like the following:

Code:

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      27426/httpd

If you don't get any output whatsoever then something went wrong and you need to look at your /var/log/apache/error_log file.

Now that SSL is all set up, you are going to want to tell Apache what to serve up when sombody connects using https://. This is done by the VirtualHost directive and the one pertaining to SSL connections can be found in the /etc/apache/mod_ssl.conf file. The default looks like this and you will certainly need to change some of the settings.

Code:

<VirtualHost _default_:443>

#  General setup for the virtual host
DocumentRoot "/var/www/htdocs"
ServerName new.host.name
ServerAdmin you@your.address
ErrorLog /var/log/apache/error_log
TransferLog /var/log/apache/access_log

And finally if you want to create your own self-signed certs and not use the ones that come with Slackware thats easy to do as well. I got the following commands from http://www.apache-ssl.org/#FAQ

Code:

Step one - create the key and request:

  openssl req -new > new.cert.csr

Step two - remove the passphrase from the key (optional):

  openssl rsa -in privkey.pem -out new.cert.key

Step three - convert request into signed cert:

   openssl x509 -in new.cert.csr -out new.cert.cert -req -signkey new.cert.key -days 1825

Step four - copy the cert and key to the appropriate places

  cp new.cert.cert /etc/apache/ssl.crt/server.crt
  cp new.cert.key /etc/apache/ssl.key/server.key

A few things to note:

When asked for Common Name in step one, be sure to enter the FQDN of your webserver ie www.mywebserver.com

When asked for A challenge password in step one, go ahead and just press enter

If you don't remove the passphrase from the key in Step two, you will be prompted to enter a password everytime you run /etc/rc.d/rc.httpd start. This means if your box reboots for some reason, your webserver wont start unless you are there to provide the passphrase.

Cerbere · 08-01-2004, 11:39 PM

Great How-to, except for one thing:

Quote:

Originally posted by SiegeX
Now all thats left is to setup the SSL Certs. If you really dont care about having offical certs, Slackware comes with pre-made ones, I use these, but if you ran a legit production webserver you would probably want to spend the money and have real certs made.

You can get free (as in beer) certs from http://www.cacert.org.

And if I'm not mistaken, the certs provided with Slack expire after thirty days. Not sure about this, but the ones that OpenSSL/mod_ssl generates on install from source have this limit.

Enjoy!
--- Cerbere

SiegeX · 08-02-2004, 12:11 AM

This isnt meant to be flaimbait, but I hear this "free as in beer" thing all the time, especially on Slashdot. Can you explain the saying to me, cause I dont remember the last time I picked up 12 pack of Corona for free

And thanks for the link, ill go check it out myself.

Cerbere · 08-02-2004, 12:35 AM

Not sure of the actual origin of the expression, but it refers to there being no monetary cost for the product/service/etc. It generally is meant to distinguish these 'no-cost' items from GPL'd or other truly free licenses where one is free to modify and re-release the product. In the case of these 'free' certs, I think that's a good thing, since freely modifiable certs wouldn't really certify much of anything, now would they?

But now that you mention it, I haven't had free beer since college. Aaahh, good times :-)

Enjoy!
--- Cerbere

kodon · 08-02-2004, 02:25 AM

http://en.wikipedia.org/wiki/Free_as_in_freedom

Cedrik · 08-02-2004, 03:12 AM

Keep in mind that SSL layer works with IP before httpd can resolve name, so when using SSL with virtual host, you have to work with IP-based virtual hosting (see http://httpd.apache.org/docs/ for infos)

SiegeX · 08-02-2004, 04:51 AM

Quote:

Originally posted by Cedrik
Keep in mind that SSL layer works with IP before httpd can resolve name, so when using SSL with virtual host, you have to work with IP-based virtual hosting (see http://httpd.apache.org/docs/ for infos)

That's only true if you want to use SSL with more than one domain name. If you just want SSL with one domain you can still use named virtual hosts. For example, here is a portion of my vhosts.conf.

Code:

NameVirtualHost *:80

##############################
# NON-SSL www.identityflux.com
##############################
<VirtualHost *:80>
ServerName www.identityflux.com
DocumentRoot "/var/www/htdocs/idflux"
LogFormat "%h %l %u %t \"%r\" %>s %b" common
ErrorLog /var/log/apache/idflux.error
CustomLog /var/log/apache/idflux.access common
</VirtualHost>

##############################
# NON-SSL www.atozcomp.com
##############################
<VirtualHost *:80>
ServerName www.atozcomp.com
DocumentRoot "/var/www/htdocs/azcomp/"
LogFormat "%h %l %u %t \"%r\" %>s %b" common
ErrorLog /var/log/apache/azcomp.error
CustomLog /var/log/apache/azcomp.access common
</VirtualHost>

And here is my SSL virtualhost in mod_ssl.conf

Code:

NameVirtualHost *:443

#############################
## SSL www.identityflux.com
#############################
<VirtualHost *:443>
DocumentRoot "/var/www/htdocs/idflux"
ServerName www.identityflux.com
ServerAdmin webmaster@identityflux.com
ErrorLog /var/log/apache/idflux_ssl.error
TransferLog /var/log/apache/idflux_ssl.access

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache/ssl.key/server.key

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

CustomLog /var/log/apache/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>

As you can see, I got around using IP-based virtual hosting by specifying the port number in both the NameVirtualHost and VirtualHost directives. Now if I wanted SSL support for both www.atozcomp.com AND www.identityflux.com then yes, I would be forced to buy another IP (one for each domain) and use ip-based virtual hosting.

Cedrik · 08-02-2004, 06:00 AM

I am sorry but when you indicate <VirtualHost *:80>, apache resolves it to all IP adresses but no to domain names.

Try replace * with a domain name, you will see... but it will work if you replace * by an IP.

SiegeX · 08-02-2004, 02:00 PM

You're very correct, the asterisk * matches all address, but It's still considered name-based virtual hosting because Apache relies on the client sending the HOST directive for it to make the decision on what webpage to serve up. Not to mention that im using the "NameVirtualHost *:80" directive which IP-based obviously doesnt have. And just so you know im not making it up, here is a simple name-based example I got from apache.org, you'll notice it looks remarkably similar to my vhosts.conf file. If you want more clairification have a looksee at:

http://httpd.apache.org/docs-2.0/vhosts/name-based.html
http://httpd.apache.org/docs/vhosts/examples.html

Code:

NameVirtualHost *:80

<VirtualHost *:80>

ServerName www.domain.tld
ServerAlias domain.tld *.domain.tld
DocumentRoot /www/domain

</VirtualHost>

<VirtualHost *:80>

ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain

</VirtualHost>

Cedrik · 08-02-2004, 03:00 PM

I said that with SSL virtual hosting in apache is ip-based because from network protocols point of view, the SSL layer is between transport layer (like tcp) and application layer (like apache and bind) some call this layer the session layer.

Given that, how do you think SSL will accept the connection if the connection need apache to resolve host ?

SiegeX · 08-02-2004, 03:08 PM

Quote:

when using SSL with virtual host, you have to work with IP-based virtual hosting

Im not arguing with what layer SSL works on, all I am saying is that the above statement is not true, you can still use name-based as long as you only want to use SSL with one domain. Apache defines IP-based virtual hosting by putting the actual IP (and sometimes the domain) in the <VirtualHost> directive. Using the Asterisk *, even though it matches all ip's is still considered name-based.

Cedrik · 08-02-2004, 03:25 PM

Actually you do IP-based virtual hosting.
If you do name-based virtual hosting, why don't you set your host as this :

<VirtualHost www.identityflux.com:443>

In this case you are sure it is name-based, and I am sure it won't work too

Don't take what I say as a critic for your work though, I am sure you know how to manage your server, but for me this ip-based thing was important to understand, I did some error in the past about this so for now I configure ip-based virtual host in each case there is SSL.

[edit]
And I am sorry but your link confirm what I said :
source : http://httpd.apache.org/docs-2.0/vhosts/name-based.html

...Some reasons why you might consider using IP-based virtual hosting:
...
Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol.

J.W. · 08-02-2004, 04:51 PM

My 2 cents on the "free as in" metaphor:

"Free as in beer" simply means that Open Source software does not cost any money to acquire, ie, it's similar to someone giving you a free beer at a party. You are getting something of value without any monetary cost.

"Free as in speech" means that everyone has an equal standing and opportunity to participate in Open Source development (if they so choose) and that there are no barriers or restrictions to block someone from participating.

To elaborate on this somewhat, just like in a democracy, where people are free to express their thoughts without limitation, in the context of software development people are free to add their own contributions to the code without limitation. Futhermore, just as good ideas will florish and poor ideas with wither away, good code will florish and become widely adopted, while poor code will fade away.

Thus, Linux (and OSS) is both "free as in beer" and "free as in speech" -- it costs nothing to acquire, and you can use it without restriction. This may not be the best description of the difference, but FWIW it works for me. -- J.W.

SiegeX · 08-02-2004, 05:04 PM

Quote:

Originally posted by Cedrik
Actually you do IP-based virtual hosting.
If you do name-based virtual hosting, why don't you set your host as this :

<VirtualHost www.identityflux.com:443>

In this case you are sure it is name-based, and I am sure it won't work too
[/i]

Actually you have it backwards, according to apache.org writing out <VirtualHost www.identityflux.com:443> makes it ip-based. Here is the code snippit from the URL on ip-based vhosts http://httpd.apache.org/docs-2.0/vhosts/ip-based.html

Code:

<VirtualHost www.smallco.com>
ServerAdmin webmaster@mail.smallco.com
DocumentRoot /groups/smallco/www
ServerName www.smallco.com
ErrorLog /groups/smallco/logs/error_log
TransferLog /groups/smallco/logs/access_log
</VirtualHost>

<VirtualHost www.baygroup.org>
ServerAdmin webmaster@mail.baygroup.org
DocumentRoot /groups/baygroup/www
ServerName www.baygroup.org
ErrorLog /groups/baygroup/logs/error_log
TransferLog /groups/baygroup/logs/access_log
</VirtualHost>

I think you just have your terms mixed up. As far as apache is concerned, the difference between name-based and IP-based is whether or not apache relies on the client to tell it what hostname to serve up. The directive that takes care of this is NameVirtualHost. In my vhost.conf you'll notice I use the NameVirtualHost directive and thus apache does require help from the client thus making it name-based.

In contrast to the code above with no NameVirtualHost and the domain instead of a *, Apache doesnt care what the client says because presumably www.baygroup.com and www.smallco.com resolve to differnt IP's but are bound to the same interface.

And by the way, I have changed my vhost directive to <VirtualHost www.identityflux.com:443> and it works just fine, you can test it out yourself https://www.identityflux.com. And the reason why it works is because I only have one domain that needs SSL. Now if I were to add another vhost below my current one in mod_ssl.conf that looked like <VirtualHost www.atozcomp.com:443> then I would be up a creek because im trying to use SSL with two differnt domains but only one ip, which is why apache suggests ip-based for SSL. In actuality what happens in this case is that the vhost that is listed first is the one that will always get served up; which is identityflux.com in my example.

By the way I dont take any of this personally nor should you, I just don't think you're right

Cedrik · 08-03-2004, 02:12 AM

I saw the exemples in apache.org but for me, that will not change my thought nor my httpd configuration methods anyway, that is the result wich is important isn't it

(the server will work)

I explain my point of view from network protocols : a web client send the HTTP request, this request (in a tcp frame) go through IP (network layer), then TCP (transport layer), then it go through session layer where it meets SSL handshake (= the browser accepts the secure Web server's certificate) but BEFORE the HTTP (application layer) request which identifies the appropriate name based virtual host.

So it can not work for named based virtual host because in this case the SSL handshake has no way to know which virtual host has the certificate.

I works in your case because Apache listen on port TCP 443 (so at the transport layer) and just for one virtual host (so just one IP, network layer), so the adress is already resolved at the transport layer BEFORE SSL (session layer) send the certificate.

To clarify, I can say you do port-based virtual hosting (although the term does not exist). The port is in transport layer so it is before the session layer (SSL).

Also when you said hen I would be up a creek because im trying to use SSL with two differnt domains but only one ip...
This is not true, you can have two different domain for SSL Vhost if you change port number like :

Listen 443
Listen 8888

<VirtualHost www.secure-domain.com:443>
# SSL config
<VirtualHost www.another-secure-domain.com:8888>
# SSL config

(of course to access www.another-secure-domain.com, you specify port number in url like http://www.another-secure-domain.com:8888

I am sorry if I am not so clear, I never succeeded when I want to explain theory in an easy way, I prefer much practice

So for me, I think I am right when I say that SSL works with IP-based virtual hosting.