Apache's Security Precautions (Apache: The Definitive Guide, 3rd Edition)

11.7. Apache's Security Precautions

Apache addresses these problems as follows:

When Apache starts, it connects to the network and creates numerous copies of itself. These copies immediately shift identity to that of a safer user, in the case of our examples, the feeble webusers of webgroup (see Chapter 2). Only the original process retains the superuser identity, but only the new processes service network requests. The original process never handles the network; it simply oversees the operation of the child processes, starting new ones as needed and killing off excess ones as network load decreases.
Output to shells is carefully tested for dangerous characters, but this only half solves the problem. The writers of CGI scripts (see Chapter 13) must be careful to avoid the pitfalls too.

For example, consider the simple shell script:

#!/bin/sh

cat /somedir/$1

You can imagine using something like this to show the user a file related to an item she picked off a menu, for example. Unfortunately, it has a number of faults. The most obvious one is that causing $1 to be "../etc/passwd" will result in the server displaying /etc/passwd! Suppose you fix that (which experience has shown to be nontrivial in itself ), then there's another problem lurking — if $1 is "xx /etc/passwd", then /somedir/xx and /etc/passwd would both be displayed. As you can see, both care and imagination are required to be completely secure. Unfortunately, there is no hard-and-fast formula — though generally speaking confirming that script inputs only have the desired characters (we advise sticking strictly to alphanumeric) is a very good starting point.

Internal users present their own problems. The main one is that they want to write CGI scripts to go with their pages. In a typical installation, the client, dressed as Apache (webuser of webgroup), does not have high enough permissions to run those scripts in any useful way. This can be solved with suEXEC (see the section Section 16.6).

11.7.1. SSL with Apache v1.3

The object of what follows is to make a version of Apache 1.3.X that handles the HTTPS (HTTP over SSL) protocol. Currently, this is only available in Unix versions, and given the many concerns that exist over the security of Win32, there seems little point in trying to implement SSL in the Win32 version of Apache.

There are several ways of implementing SSL in Apache: Apache-SSL and mod_ssl. These are alternative free software implementations of the same basic algorithms. There are also commercial products from RedHat, Covalent and C2Net. We will be describing Apache-SSL first since one of the authors (BL) is mainly responsible for it.

The first step is to get ahold of the appropriate version of Apache; see Chapter 1. See the Apache-SSL home page at http://www.apache-ssl.org/ for current information.

11.7.1.1. Apache-SSL

The Apache end of Apache-SSL consists of some patches to the Apache source code. Download them from ftp://ftp.MASTER.pgp.net/pub/crypto/SSL/Apache-SSL/. There is a version of the patches for each release of Apache, so we wanted apache_1.3.26+ssl_1.44.tar.gz. Rather puzzlingly, since the list of files on the FTP site is sorted alphabetically, this latest release came in the middle of the list with apache_1.3.9+ssl_1.37.tar.gz at the bottom, masquerading as the most recent. Don't be fooled.

There is a glaring security issue here: an ingenious Bad Guy might save himself the trouble of cracking your encrypted messages by getting into the sources and inserting some code to, say, email him the plain texts. In the language of cryptography, this turns the sources into trojan horses. To make sure there has been no trojan horsing around, some people put up the MD5 sums of the hashed files so that they can be checked. But a really smart Bad Guy would have altered them too. A better scheme is to provide PGP signatures that he can't fix, and this is what you will find here, signed by Ben Laurie.

But who is he? At the moment the answer is to look him up in a paper book: The Global Internet Trust Register (see http://www.cl.cam.ac.uk/Research/Security/Trust-Register/). This is clearly a problem that is not going to go away: look at keyman.aldigital.co.uk.

You need to unpack the files into the Apache directory — which will of course be the version corresponding to the previously mentioned filename. There is a slight absurdity here, in that you can't read the useful file README.SSL until you unpack the code, but almost the next thing you need to do is to delete the Apache sources — and with them the SSL patches.

11.7.1.2. OpenSSL

README.SSL tells you to get OpenSSL from http://www.openssl.org. When you get there, there is a prominent notice, worth reading:

PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY SOFTWARE, 
PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING TECHNICAL DETAILS ABOUT
CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS 
PACKAGE TO YOUR COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL 
SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER PEOPLE YOU ARE STRONGLY 
ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT AND/OR USE LAWS WHICH APPLY TO 
YOU. THE AUTHORS OF OPENSSL ARE NOT LIABLE FOR ANY VIOLATIONS YOU MAKE HERE. SO BE 
CAREFUL, IT IS YOUR RESPONSIBILITY.

We downloaded openssl-0.9.6g.tar.gz and expanded the files in /usr/src/openssl. There are two configuration scripts: config and Configure. The first, config, makes an attempt to guess your operating system and then runs the second. The build is pretty standard, though long-winded, and installs the libraries it creates in /usr/local/ssl.. You can change this with the following:

./config --prefix=<directory in which  .../bin, .../lib, 
         ...include/openssl are to appear>.

However, we played it straight:

./config
make
make test
make install

This last step put various useful encryption utilities in /usr/local/ssl/bin. You would probably prefer them on the path, in /usr/local/bin, so copy them there.

11.7.1.3. Rebuild Apache

When that was over, we went back to the Apache directory (/usr/src/apache/apache_1.3.19) and deleted everything. This is an essential step: without it, the process will almost certainly fail. The simple method is to go to the previous directory (in our case /usr/src/apache), making sure that the tarball apache_1.3.19.tar was still there, and run the following:

 rm -r apache_1.3.19

We then reinstalled all the Apache sources with the following:

tar xvf apache_1_3_19.tar

When that was done we moved down into .../apache_1.3.19, re-unpacked Apache-SSL, and ran FixPatch, a script which inserted path(s) to the OpenSSL elements into the Apache build scripts. If this doesn't work or you don't want to be so bold, you can achieve the same results with a more manual method:

patch -p1 < SSLpatch

The README.SSL file in .../apache_1.3.19 says that you will then have to "set SSL_* in src/Configuration to appropriate values unless you ran FixPatch." Since FixPatch produces:

SSL_BASE=/usr/local/ssl
SSL_INCLUDE= -I$(SSL_BASE)/include
SSL_CFLAGS= -DAPACHE_SSL
SSL_LIB_DIR=/usr/local/ssl/lib
SSL_LIBS= -L$(SSL_LIB_DIR) -lssl -lcrypto
SSL_APP_DIR=/usr/local/ssl/bin
SSL_APP=/usr/local/ssl/bin/openssl

you would need to reproduce all these settings by hand in .../src/Configuration.

If you want to include any other modules into Apache, now is the moment to edit the .../src/Configuration file as described in Chapter 1. We now have to rebuild Apache. Having moved into the .../src directory, the command ./Configure produced:

Configuration.tmpl is more recent than Configuration
Make sure that Configuration is valid and, if it is, simply
'touch Configuration' and re-run ./Configure again.

In plain English, make decided that since the alteration date on Configure was earlier than the date on Configure.tmpl (the file it would produce), there was nothing to do. touch is a very useful Unix utility that updates a file's date and time, precisely to circumvent this kind of helpfulness. Having done that, ./Configure ran in the usual way, followed by make, which produced an httpsd executable that we moved to /usr/local/bin alongside httpd.

11.7.1.4. Config file

You now have to think about the Config files for the site. A sample Config file will be found at .../apache_1.3.XX/SSLconf/conf, which tells you all you need to know about Apache-SSL.

It is possible that this Config file tells you more than you want to know right away, so a much simpler one can be found at site.ssl/apache_1.3. (Apache v2 is sufficiently different, so we have started over at site.ssl/apache_2.) This illustrates a fairly common sort of site where you have an unsecured element for the world at large, which it accesses in the usual way by surfing to http://www.butterthlies.com,and a secure part (here, notionally, for the salesmen) which is accessed through https://sales.butterthlies.com,followed by a username and password — which, happily, is now encrypted. In the real world, the encrypted part might be a set of maintenance pages, statistical reports, etc. for access by people involved with the management of the web site, or it might be an inner sanctum accessible only by subscribers, or it might have to do with the transfer of money, or whatever should be secret...

User webserv
Group webserv

LogLevel notice
LogFormat "%h %l %t \"%r\" %s %b %a %{user-agent}i %U" sidney

SSLCacheServerPort 1234
SSLCacheServerPath /usr/src/apache/apache_1.3.19/src/modules/ssl/gcache
SSLCertificateFile /usr/src/apache/apache_1.3.19/SSLconf/conf/new1.cert.cert
SSLCertificateKeyFile /usr/src/apache/apache_1.3.19/SSLconf/conf/privkey.pem

SSLVerifyClient 0
SSLFakeBasicAuth
SSLSessionCacheTimeout 3600

SSLDisable

Listen 192.168.123.2:80
Listen 192.168.123.2:443

<VirtualHost 192.168.123.2:80>
SSLDisable
ServerName www.butterthlies.com
DocumentRoot /usr/www/APACHE3/site.virtual/htdocs/customers
ErrorLog /usr/www/APACHE3/site.ssl/apache_1.3/logs/error_log
CustomLog /usr/www/APACHE3/site.ssl/apache_1.3/logs/butterthlies_log sidney
</VirtualHost>

<VirtualHost 192.168.123.2:443>
ServerName sales.butterthlies.com
SSLEnable

DocumentRoot /usr/www/APACHE3/site.virtual/htdocs/salesmen
ErrorLog /usr/www/APACHE3/site.ssl/apache_1.3/logs/error_log
CustomLog /usr/www/APACHE3/site.ssl/apache_1.3/logs/butterthlies_log sidney

<Directory /usr/www/APACHE3/site.virtual/htdocs/salesmen>
AuthType Basic
AuthName darkness
AuthUserFile /usr/www/APACHE3/ok_users/sales
AuthGroupFile /usr/www/APACHE3/ok_users/groups
Require group cleaners
</Directory>
</VirtualHost>

Notice that SSL is disabled before any attempt is made at virtual hosting, and then it's enabled again in the secure Sales section. While SSL is disabled, the secure version of Apache, httpsd, behaves like the standard version httpd. Notice too that we can't use name-based virtual hosting because the URL the visitor wants to see (and hence the name of the virtual host) isn't available until the SSL connection is established.

SSLFakeBasicAuth pretends the client logged in using basic auth, but gives the DN of the client cert instead of his login name, and a fixed password: password. Consequently, you can use all the standard directives: Limit, Require, Satisfy.

Ports 443 and 80 are the defaults for secure (https) and insecure (http) access, so visitors do not have to specify them. We could have put SSL's bits and pieces elsewhere — the certificate and the private key in the .../conf directory, and gcache in /usr/local/bin — or anywhere else we liked. To show that there is no trickery and that you can apply SSL to any web site, the document roots are in site.virtual. To avoid complications with client certificates, we specify:

SSLVerifyClient 0

This automatically encrypts passwords over an HTTPS connection and so mends the horrible flaw in the Basic Authentication scheme that passwords are sent unencrypted.

Remember to edit go so it invokes httpsd (the secure version); otherwise, Apache will rather puzzlingly object to all the nice new SSL directives:

httpsd -d /usr/www/APACHE3/site.ssl

When you run it, Apache starts up and produces a message:

Reading key for server sales.butterthlies.com:443 
Launching... /usr/www/apache/apache_1.3.19/src/modules/sslgcache
pid=68598

(The pid refers to gcache, not httpsd.) This message shows that the right sort of thing is happening. If you had opted for a passphrase, Apache would halt for you to type it in, and the message would remind you which passphrase to use. However, in this case there isn't one, so Apache starts up.[44] On the client side, log on to http://www.butterthlies.com.The postcard site should appear as usual. When you browse to https://sales.butterthlies.com,you are asked for a username and password as usual — Sonia and theft will do.

[44]Later versions of Apache may not show this message if a passphrase is not required.

Remember the "s" in https. It might seem rather bizarre that the client is expected to know in advance that it is going to meet an SSL server and has to log on securely, but in practice you would usually log on to an unsecured site with http and then choose or be steered to a link that would set you up automatically for a secure transaction.

If you forget the "s" in https, various things can happen:

You are mystifyingly told that the page contains no data.
Your browser hangs.

.../site.ssl/apache_1.3/logs/error_log contains the following line:

SSL_Accept failed error:140760EB:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
    protocol

If you pass these perils, you find that your browser vendor's product-liability team has been at work, and you are taken through a rigmarole of legal safeguards and "are you absolutely sure?" queries before you are finally permitted to view the secure page.

We started running with SSLVerifyClient 0, so Apache made no inquiry concerning our own credibility as a client. Change it to 2, to force the client to present a valid certificate. Netscape now says:

No User Certificate
The site 'www.butterthlies.com' has requested client authentication, but you
do not have a Personal Certificate to authenticate yourself. The site may
choose not to give you access without one.

Oh, the shame of it! The simple way to fix this smirch is to get a personal certificate from one of the companies listed shortly.

11.7.1.5. Environment variables

Once Apache SSL is installed, a number of new environment variables will appear and can be used in CGI scripts (see Chapter 13). They are shown in Table 11-1.

Table 11-1. Apache v1.3 environment variables

Variable	Value type	Description
`HTTPS`	flag	HTTPS being used
`HTTPS_CIPHER`	string	SSL/TLS cipherspec
`SSL_CIPHER`	string	The same as `HTTPS_CIPHER`
`SSL_PROTOCOL_VERSION`	string	Self explanatory
`SSL_SSLEAY_VERSION`	string	Self explanatory
`HTTPS_KEYSIZE`	number	Number of bits in the session key
`HTTPS_SECRETKEYSIZE`	number	Number of bits in the secret key
`SSL_CLIENT_DN`	string	DN in client's certificate
`SSL_CLIENT_``x509`	string	Component of client's DN, where `x509` is a component of an X509 DN
`SSL_CLIENT_I_DN`	string	DN of issuer of client's certificate
`SSL_CLIENT_I_``x509`	string	Component of client's issuer's DN, where `x509` is a component of an X509 DN
`SSL_SERVER_DN`	string	DN in server's certificate
`SSL_SERVER_``x509`	string	Component of server's DN, where `x509` is a component of an X509 DN
`SSL_SERVER_I_DN`	string	DN of issuer of server's certificate
`SSL_SERVER_I_``x509`	string	Component of server's issuer's DN, where `x509` is a component of an X509 DN
`SSL_CLIENT_CERT`	string	Base64 encoding of client cert
`SSL_CLIENT_CERT_CHAIN_``n`	string	Base64 encoding of client cert chain

11.7.2. mod_ssl with Apache 1.3

The alternative SSL for v1.3 is mod-ssl. There is an excellent introduction to the whole SSL business at http://www.modssl.org/docs/2.8/ssl_intro.html.

You need a mod_ssl tarball that matches the version of Apache 1.3 that you are using — in this case, 1.3.26. Download it from http://www.modssl.org/. You will need openssl from http://www.openssl.org/ and the shared memory library at http://www.engelschall.com/sw/mm/ if you want to be able to use a RAM-based session cache instead of a disk-based one.We put each of these in its own directory under /usr/src. You will also need Perl and gzip, but we assume they are in place by now.

Un-gzip the mod_ssl package:

gunzip mod_ssl-2.8.10-1.3.26.tar.gz

and then extract the contents of the .tar file with the following:

tar xvf mod_ssl-2.8.10-1.3.26.tar

Do the same with the other packages. Go back to .../mod_ssl/mod_ssl-<date>-<version>, and read the INSTALL file.

First, configure and build the OpenSSL: library. Get into the directory, and type the following:

 sh config no-idea no-threads -fPIC

Note the capitals: PIC. This creates a makefile appropriate to your Unix environment. Then run:

make
make test

in the usual way — but it takes a while. For completeness, we then installed mm:

cd ....mm/mm-1.2.1
./configure ==prefix=/usr/src/mm/mm-1.2.1
make
make test
make install

It is now time to return to mod_ssl get into its directory. The INSTALL file is lavish with advice and caution and offers a large number of different procedures. What follows is an absolutely minimal build — even omitting mm. These configuration options reflect our own directory layout. The \s start new lines:

./configure --with-apache=/usr/src/apache/apache_1.3.26 \
--with-ssl=/usr/src/openssl/openssl-0.9.6a \
--prefix=/usr/local

This then configures mod_ssl for the specified version of Apache and also configures Apache. The script exits with the instruction:

Now proceed with the following ncommands:
$ cd /usr/src/apache/apache_1.3.26
$ make
$ make certificate

This generates a demo certificate. You will be asked whether it should contain RSA or DSA encryption ingredients: answer "R" (for RSA, the default) because no browsers supports DSA. You are then asked for a various bits of information. Since this is not a real certificate, it doesn't terribly matter what you enter. There is a default for most questions, so just hit Return:

1. Contry Name              (2 letter code) [XY]:
....

You will be asked for a PEM passphrase — which can be anything you like as long as you can remember it. The upshot of the process is the generation of the following:

.../conf/ssl.key/server.key: Your private key file
.../conf/ssl.crt/server.crt: Your X.509 certificate file
.../conf/ssl.csr/server.csr: The PEM encoded X.509 certificate-signing request file, which you can send to a CA to get a real server certificate to replace .../conf/ssl.crt/server.crt

Now type:

$ make install

This produces a pleasant screen referring you to the Config file, which contains the following relevant lines:

##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
##

#
#   Some MIME-types for downloading Certificates and CRLs
#
<IfDefine SSL>
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl
</IfDefine>

<IfModule mod_ssl.c>

#   Pass Phrase Dialog:
#   Configure the pass phrase gathering process.
#   The filtering dialog program ('builtin' is a internal
#   terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog  builtin

#   Inter-Process Session Cache:
#   Configure the SSL Session Cache: First the mechanism 
#   to use and second the expiring timeout (in seconds).
#SSLSessionCache        none
#SSLSessionCache        shmht:/usr/local/sbin/logs/ssl_scache(512000)
#SSLSessionCache        shmcb:/usr/local/sbin/logs/ssl_scache(512000)
SSLSessionCache         dbm:/usr/local/sbin/logs/ssl_scache
SSLSessionCacheTimeout  300

You will need to incorporate something like them in your own Config files if you want to use mod_ssl. You can test that the new Apache works by going to /usr/src/bin and running:

./apachectl startssl

Don't forget ./ or you will run some other apachectl, which will probably not work.

The Directives are the same as for SSL in Apache V2 — see the following.

11.7.3. SSL with Apache v2

SSL for Apache v2 is simpler: there is only one choice. Download OpenSSL as described earlier. Now go back to the Apache source directory and abolish it completely. In /usr/src/apache we had the tarball httpd-2_0_28-beta.tar and the directory httpd-2_0_28. We deleted the directory and rebuilt it with this:

rm -r httpd-2_0_28
tar xvf httpd-2_0_28-beta.tar
cd httpd-2_0_28

To rebuild Apache with SSL support:

./configure --with-layout=GNU --enable-ssl --with-ssl=<path to ssl source> --prefix=/
usr/local
make
make install

This process produces an executable httpd (not httpsd, as with 1.3) in the subdirectory bin below the Prefix path.

There are useful and well-organized FAQs at httpd.apache.org/docs-2.0/ssl/ssl_faq.html and www.openssl.org.faq.html.

11.7.3.1. Config file

At ...site.ssl/apache_2 the equivalent Config file to that mentioned earlier is as follows:

User webserv
Group webserv

LogLevel notice
LogFormat "%h %l %t \"%r\" %s %b %a %{user-agent}i %U" sidney

#SSLCacheServerPort 1234
#SSLCacheServerPath /usr/src/apache/apache_1.3.19/src/modules/ssl/gcache
SSLSessionCache dbm:/usr/src/apache/apache_1.3.19/src/modules/ssl/gcache
SSLCertificateFile /usr/src/apache/apache_1.3.19/SSLconf/conf/new1.cert.cert
SSLCertificateKeyFile /usr/src/apache/apache_1.3.19/SSLconf/conf/privkey.pem

SSLVerifyClient 0
SSLSessionCacheTimeout 3600

Listen 192.168.123.2:80
Listen 192.168.123.2:443

<VirtualHost 192.168.123.2:80>
SSLEngine off
ServerName www.butterthlies.com
DocumentRoot /usr/www/APACHE3/site.virtual/htdocs/customers
ErrorLog /usr/www/APACHE3/site.ssl/apache_2/logs/error_log
CustomLog /usr/www/APACHE3/site.ssl/apache_2/logs/butterthlies_log sidney
</VirtualHost>

<VirtualHost 192.168.123.2:443>
SSLEngine on
ServerName sales.butterthlies.com

DocumentRoot /usr/www/APACHE3/site.virtual/htdocs/salesmen
ErrorLog /usr/www/APACHE3/site.ssl/apache_2/logs/error_log
CustomLog /usr/www/APACHE3/site.ssl/apache_2/logs/butterthlies_log sidney

<Directory /usr/www/APACHE3/site.virtual/htdocs/salesmen>
AuthType Basic
AuthName darkness
AuthUserFile /usr/www/APACHE3/ok_users/sales
AuthGroupFile /usr/www/APACHE3/ok_users/groups
Require group cleaners
</Directory>
</VirtualHost>

It was slightly annoying to have to change a few of the directives, but in real life one is not going to convert between versions of Apache every day...

The only odd thing was that if we set SSLSessionCache to none (which is the default) or omitted it altogether, the browser was unable to find the server. But set as shown earlier, everything worked fine.

11.7.3.2. Environment variables

This module provides a lot of SSL information as additional environment variables to the SSI and CGI namespace. The generated variables are listed in Table 11-2. For backward compatibility the information can be made available under different names, too.

Table 11-2. Apache v2 environment variables

Variable	Value type	Description
`HTTPS`	flag	HTTPS being used
`SSL_PROTOCOL`	string	The SSL protocol version (SSL v2, SSL v3, TLS v1)
`SSL_SESSION_ID`	string	The hex-encoded SSL session ID
`SSL_CIPHER`	string	The cipher specification name
`SSL_CIPHER_EXPORT`	string	True if cipher is an export cipher
`SSL_CIPHER_USEKEYSIZE`	number	Number of cipher bits actually used
`SLL_CIPHER_ALGKEYSIZE`	number	Number of cipher bits possible
`SSL_VERSION_INTERFACE`	string	The mod_ssl program version
`SSL_VERSION_LIBRARY`	string	The OpenSSL program version
`SSL_CLIENT_M_VERSION`	string	The version of the client certificate
`SSL_CLIENT_M_SERIAL`	string	The serial of the client certificate
`SSL_CLIENT_S_DN`	string	Subject DN in client's certificate
`SSL_CLIENT_S_DN_x509`	string	Component of client's Subject DN, where `x509` is a component of an X509 DN
`SSL_CLIENT_I_DN`	string	Issuer DN of a client's certificate
`SSL_CLIENT_I_DN_x509`	string	Component of client's Issuer DN, where `x509` is a component of an X509 DN
`SSL_CLIENT_V_START`	string	Validity of client's certificate (start time)
`SSL_CLIENT_V_END`	string	Validity of client's certificate (end time)
`SSL_CLIENT_A_SIG`	string	Algorithm used for the signature of client's certificate
`SSL_CLIENT_A_KEY`	string	Algorithm used for the public key of client's certificate
`SSL_CLIENT_CERT`	string	PEM-encoded client certificate
`SSL_CLIENT_CERT_CHAINn`	string	PEM-encoded certificates in client certificate chain
`SSL_CLIENT_VERIFY`	string	`NONE`, `SUCCESS`, `GENEROUS`, or `FAILED`: reason
`SSL_SERVER_M_VERSION`	string	The version of the server certificate
`SSL_SERVER_M_SERIAL`	string	The serial of the server certificate
`SSL_SERVER_S_DN`	string	Subject DN in server's certificate
`SSL_SERVER_S_DN_x509`	string	Component of server's Subject DN, where `x509` is a component of an X509 DN
`SSL_SERVER_I_DN`	string	Issuer DN of a server's certificate
`SSL_SERVER_I_DN_x509`	string	Component of server's Issuer DN, where `x509` is a component of an X509 DN
`SSL_SERVER_V_START`	string	Validity of server's certificate (start time)
`SSL_SERVER_V_END`	string	Validity of server's certificate (end time)
`SSL_SERVER_A_SIG`	string	Algorithm used for the signature of server's certificate
`SSL_SERVER_A_KEY`	string	Algorithm used for the public key of server's certificate
`SSL_SERVER_CERT`	string	PEM-encoded server certificate

11.7.4. Make a Test Certificate

Regardless of which version of Apache you are using, you now need a test certificate. Go into .../src and type:

% make certificate

A number of questions appear about who and where you are:

ps > /tmp/ssl-rand; date >> /tmp/ssl-rand; RANDFILE=/tmp/ssl-rand /usr/local/ssl/
bin/openssl req -config ../SSLconf/conf/ssleay.cnf  -new -x509 -nodes -out ../
SSLconf/conf/httpsd.pem  -keyout ../SSLconf/conf/httpsd.pem;  ln -sf httpsd.pem ../
SSLconf/conf/'/usr/local/ssl/bin/openssl  x509 -noout -hash < ../SSLconf/conf/httpsd.
pem'.0;  rm /tmp/ssl-rand
Using configuration from ../SSLconf/conf/ssleay.cnf
Generating a 1024 bit RSA private key
...........++++++
..........++++++
writing new private key to '../SSLconf/conf/httpsd.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Some-State]:Nevada
Locality Name (eg, city) []:Hopeful City
Organization Name (eg, company; recommended) []:Butterthlies Inc
Organizational Unit Name (eg, section) []:Sales
server name (eg. ssl.domain.tld; required!!!) []:sales.butterthlies.com
Email Address []:sales@butterthlies.com

Your inputs are shown in bold type in the usual way. The only one that genuinely matters is "server name," which must be the fully qualified domain name (FQDN) of your server. This has to be correct because your client's security-conscious browser will check to see that this address is the same as that being accessed. To see the result, go to the directory above, then down into .../SSLConf/conf. You should see something like this in the file httpsd.pem (yours should not be identical to this, of course):

This is rather an atypical certificate, because it combines our private key with the certificate. You would probably want to separate them and make the private key readable only by root (see later in this section). Also, the certificate is signed by ourselves, making it a root certification authority certificate; this is just a convenience for test purposes. In the real world, root CAs are likely to be somewhat more impressive organizations than we are. However, this is functionally the same as a "real" certificate: the important difference is that it is cheaper and quicker to obtain than the real one.

This certificate is also without a passphrase, which httpsd would otherwise ask for at startup. We think a passphrase is a bad idea because it prevents automatic server restarts, but if you want to make yourself a certificate that incorporates one, edit Makefile (remembering to re-edit if you run Configuration again), find the "certificate:" section, remove the -nodes flag, and proceed as before. Or, follow this procedure, which will also be useful when we ask one of the following CAs for a proper certificate. Go to .../SSLConf/conf. Type:

% openssl req -new -outform PEM> new.cert.csr
...
writing new private key to 'privkey.pem'
enter PEM pass phrase:

Type in your passphrase, and then answer the questions as before. You are also asked for a challenge password — we used "swan." This generates a Certificate Signing Request (CSR) with your passphrase encrypted into it using your private key, plus the information you supplied about who you are and where you operate. You will need this if you want to get a server certificate. You send it to the CA of your choice. If he can decrypt it using your public key, he can then go ahead to check — more or less thoroughly — that you are who you say you are.

However, if you then decide you don't want a passphrase after all because it makes Apache harder to start — see earlier — you can remove it with this:

% openssl rsa -in privkey.pem -out privkey.pem

Of course, you'll need to enter your passphrase one last time. Either way, you then convert the request into a signed certificate:

% openssl x509 -in new1.cert.csr -out new1.cert.cert -req -signkey
      privkey.pem

As we noted earlier, it would be sensible to restrict the permissions of this file to root alone. Use:

chmod  u=r,go= privkey.pem

You now have a secure version of Apache (httpsd), a certificate (new1.cert.cert), a Certificate Signing Request (new1.cert.csr), and a signed key (privkey.pem).

11.7.5. Getting a Server Certificate

If you want a more convincing certificate than the one we made previosly, you should go to one o the followingf:

Resellers at http://resellers.tucows.com/products/
Thawte Consulting, at http://www.thawte.com/certs/server/request.html
CertiSign Certificadora Digital Ltda., at http://www.certisign.com.br
IKS GmbH, at http://www.iks-jena.de/produkte/ca/
BelSign NV/SA, at http://www.belsign.be
Verisign, Inc. at http://www.verisign.com/guide/apache
TC TrustCenter (Germany) at http://www.trustcenter.de/html/Produkte/TC_Server/855.htm
NLsign B.V. at http://www.nlsign.nl
Deutsches Forschungsnetz at http://www.pca.dfn.de/dfnpca/certify/ssl/
128i Ltd. (New Zealand) at http://www.128i.com
Entrust.net Ltd. at http://www.entrust.net/products/index.htm
Equifax Inc. at http://www.equifax.com/ebusinessid/
GlobalSign NV/SA at http://www.GlobalSign.net
NetLock Kft. (Hungary) at http://www.netlock.net
Certplus SA (France) at http://www.certplus.com

These all may have slightly different procedures, since there is no standard format for a CSR. We suggest you check out what the CA of your choice wants before you embark on buying a certificate.

11.7.6. The Global Session Cache

SSL uses a session key to secure each connection. When the connection starts, certificates are checked, and a new session key is agreed between the client and server (note that because of the joys of public-key encryption, this new key is only known to the client and server). This is a time-consuming process, so Apache-SSL and the client can conspire to improve the situation by reusing session keys. Unfortunately, since Apache uses a multiprocess execution model, there's no guarantee that the next connection from the client will use the same instance of the server. In fact, it is rather unlikely. Thus, it is necessary to store session information in a cache that is accessible to all the instances of Apache-SSL. This is the function of the gcache program. It is controlled by the SSLCacheServerPath, SSLCacheServerPort, SSLSessionCacheTimeout directives for Apache v1.3, and SSLSessionCache for Apache v2, described later in this chapter.