mailman with lighttpd and ssl

Step 3 – configuring lighttpd with SSL for mailman.

This document describes how to configure lighttpd for mailman on linux. It also describes how to configure the lighttpd name based virtual servers to use SSL certificates. The certificates in use are self-generated. This document is part of a set of four which collectively describe:

Step 1 – upstream SMTP authentication using TLS with postfix;
Step 2 – getting a mailman listserver running with postfix;
Step 3 – configuring lighttpd with SSL for mailman;
Step 4 – putting it all together and letting the world in.

This step does not have to use SSL. I choose to use SSL simply to protect the credentials of my mailman users. If you find it acceptable to transmit passwords in clear then simply ignore the SSL configuration options below.

Again you will need to install lighttpd for your particular distro. In debian, lighttpd’s configuration files are located in /etc/lighttpd. The main configuration file is called lighttpd.conf. This does not need much in the way of change. The important directives from our point of view are the ones covering the server modules. Mailman relies on the cgi module so we could either enable it here (in the “server.modules” listing) or in the separately loaded cgi-conf file. The top level configuration file contains an “include” directive (include_shell “/usr/share/lighttpd/include-conf-enabled.pl”) which tells the server to load additional configuration files from a sub-directory called “conf-enabled”. This directory contains symlinks to separate configuration files in a separate sub-directory called “conf-available”. My particular subdirectory has the following symlinks:

10-cgi.conf
10-simple-vhost.conf
10-status.conf

Note that the cgi-conf file is loaded. This file contains the directive to load the cgi-module – thus

server.modules += ( “mod_cgi” )

The most important configuration file here is “10-simple-vhost.conf” which gives the configuration directives for the virtual web on which “lists.ourdomain.org” runs. Mine looks like this:

## Simple name-based virtual hosting
##
## Documentation: /usr/share/doc/lighttpd-doc/simple-vhost.txt
## https://www.lighttpd.net/documentation/simple-vhost.html

else $HTTP[“host”] == “www.ourdomain.org” {
server.name = “www.ourdomain.org”
server.dir-listing = “disable”
}
}
# end

With the ssl engine enabled we need to give the server access to an appropriate SSL certificate which we have stored at /etc/lighttpd/keys/ourdomain.org/server.pem. You can. of course, pay for a commercial SSL certificate from a trusted third party such as Thawte. But if you (and more importantly, your users) don’t care about third party validation and only want to use the SSL transport to protect login credentials (as is my case) then you can easily generate your own certificate. The simplest way is the same way we created the certificate for the SMTP client at step 1 above:

openssl req -new -x509 -keyout server.pem -out server.pem -days 1000 -nodes

again answer the questions in a way which makes sense to you and then store the resulting output file in /etc/lighttpd/keys/ourdomain.org/server.pem and restart lighttpd.

Most on-line resources will tell you that it is not possible to use SSL cerificates with name based virtual servers. In fact the Apache FAQ seems to suggest that it is impossible. But this is not quite true. Certainly if you wish to use unique certificates for each server (thus one certificate would identify server1.ourdomain.org and a separate certificate would identify server2.ourdomain.org) then you must use IP address based virtual servers and bind each certificate to its own IP address. But here we are not using SSL certificates for server authentication, we are are only using SSL to encrypt traffic, so separate certificates are not necessary. If we generate a single certificate for the whole domain in use (ourdomain.org) then we can easily use that single certificate for all virtual servers on that domain without it looking too odd. Of course, if we host multiple domains on the server then a single certificate (say for ourdomain.org) would look odd if it were used to cover a server at another domain such as “www.i-need-to-be-trusted.com”. The configuration above uses a single certificate to cover all name based virtual servers running on 192.168.30.40.

Given that we are using self generated certificates which are not signed by a trusted third party it is worth telling your users that they will probably receive dire warnings from their browsers the first time they connect. The actual level of detail and severity of the warning will vary from browser to browser, but Firefox for example gets really worked up about the fact that you are trying to connect to a server which has no trusted verification mechanism. In my view this is a “good thing” (TM), but it might frighten some users unless they are forewarned and told what to do. It is also worth pointing out to these users that if ever they receive the same sort of reaction when attempting to connect to a commercial site which wants their money, then they should run a mile. Look upon it as a learning experience.

So now we have all the requisite configuration in place, it is time to open the service up to our users at Step 4.