 |  |
| |
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).
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.
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.
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.
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.
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
protocolIf 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.
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.
|
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 |
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:
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 300You 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.
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.
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.
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.
|
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 |
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):
-----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQDBpDjpJQxvcPRdhNOflTOCyQp1Dhg0kBruGAHiwxYYHdlM/z6k pi8EJFvvkoYdesTVzM+6iABQbk9fzvnG5apxy8aB+byoKZ575ce2Rg43i3KNTXY+ RXUzy/5HIiL0JtX/oCESGKt5W/xd8G/xoKR5Qe0P+1hgjASF2p97NUhtOQIDAQAB AoGALIh4DiZXFcoEaP2DLdBCaHGT1hfHuU7q4pbi2CPFkQZMU0jgPz140psKCa7I 6T6yxfi0TVG5wMWdu4r+Jp/q8ppQ94MUB5oOKSb/Kv2vsZ+T0ZCBnpzt1eia9ypX ELTZhngFGkuq7mHNGlMyviIcq6Qct+gxd9omPsd53W0th4ECQQDmyHpqrrtaVlw8 aGXbTzlXp14Bq5RG9Ro1eibhXId3sHkIKFKDAUEjzkMGzUm7Y7DLbCOD/hdFV6V+ pjwCvNgDAkEA1szPPD4eB/tuqCTZ+2nxcR6YqpUkT9FPBAV9Gwe7Svbct0yu/nny bpv2fcurWJGI23UIpWScyBEBR/z34El3EwJBALdw8YVtIHT9IlHN9fCt93mKCrov JSyF1PBfCRqnTvK/bmUij/ub+qg4YqS8dvghlL0NVumrBdpTgbO69QaEDvsCQDVe P6MNH/MFwnGeblZr9SQQ4QeI9LOsIoCySGod2qf+e8pDEDuD2vsmXvDUWKcxyZoV Eufc/qMqrnHPZVrhhecCQCsP6nb5Aku2dbhX+TdYQZZDoRE2mkykjWdK+B22C2/4 C5VTb4CUF7d6ukDVMT2d0/SiAVHBEI2dR8Vw0G7hJPY= -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIICvTCCAiYCAQAwDQYJKoZIhvcNAQEEBQAwgaYxCzAJBgNVBAYTAlVTMQ8wDQYD VQQIEwZOZXZhZGExFTATBgNVBAcTDEhvcGVmdWwgQ2l0eTEZMBcGA1UEChMQQnV0 dGVydGhsaWVzIEluYzEOMAwGA1UECxMFU2FsZXMxHTAbBgNVBAMTFHd3dy5idXR0 ZXJ0aGxpZXMuY29tMSUwIwYJKoZIhvcNAQkBFhZzYWxlc0BidXR0ZXJ0aGxpZXMu Y29tMB4XDTk4MDgyNjExNDUwNFoXDTk4MDkyNTExNDUwNFowgaYxCzAJBgNVBAYT AlVTMQ8wDQYDVQQIEwZOZXZhZGExFTATBgNVBAcTDEhvcGVmdWwgQ2l0eTEZMBcG A1UEChMQQnV0dGVydGhsaWVzIEluYzEOMAwGA1UECxMFU2FsZXMxHTAbBgNVBAMT FHd3dy5idXR0ZXJ0aGxpZXMuY29tMSUwIwYJKoZIhvcNAQkBFhZzYWxlc0BidXR0 ZXJ0aGxpZXMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBpDjpJQxv cPRdhNOflTOCyQp1Dhg0kBruGAHiwxYYHdlM/z6kpi8EJFvvkoYdesTVzM+6iABQ bk9fzvnG5apxy8aB+byoKZ575ce2Rg43i3KNTXY+RXUzy/5HIiL0JtX/oCESGKt5 W/xd8G/xoKR5Qe0P+1hgjASF2p97NUhtOQIDAQABMA0GCSqGSIb3DQEBBAUAA4GB AIrQjOfQTeOHXBS+zcXy9OWpgcfyxI5GQBg6VWlRlhthEtYDSdyNq9hrAT/TGUwd Jm/whjGLtD7wPx6c0mR/xsoWWoEVa2hIQJhDlwmnXk1F3M55ZA3Cfg0/qb8smeTx 7kM1LoxQjZL0bg61Av3WG/TtuGqYshpE09eu77ANLngp -----END CERTIFICATE-----
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.pemAs 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).
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.
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.
|  | |
| 11.6. Secure Sockets Layer |  | 11.8. SSL Directives |
Copyright © 2003 O'Reilly & Associates. All rights reserved.