If you’ve got an Apache server running and you’re going to deploy Web applications that require high-level security such as financial transactions or private messaging, you will want to encrypt most of the traffic and establish key-driven authentication in both directions. At first glance, this job is tough enough (and sufficiently unfamiliar) that you’re thinking of outsourcing it.

But you have some formidable resources at your disposal. With Apache’s mod_ssl module, you have considerable power over your encryption/authentication implementation. Secure Sockets Layer (SSL), in its open protocol form (Transport Layer Security, or TLS), has what you need and, with mod_ssl, you can make it conform to your particular needs.

The module comes with Apache 2.0 and up and can be downloaded from www.modssl.org. Working directly with the module, you can fine-tune your SSL security implementation considerably. Here’s a run down on the module directives that will give you the most effective results.

Directives for keys
Two keys are used for SSL cryptography, a public key and a private key. The public key goes to clients for encrypting information, and the server then decrypts it with a private key. There are some additional useful features, however.

SSLPassPhraseDialog: The private server key is encrypted, for obvious reasons. It goes to the server at startup with a pass-phrase required. If this is how you want it, instruct SSL as follows:
SSLPassPhraseDialog     builtin

You have the option, however, of handing the key over unencrypted or verifying it at handoff.

SSLCipherSuite: There are a number of cipher suites (31) available to you in SSL/TSL. The choice may be arbitrary to you, but if one in particular is appropriate, you may implement it with the directive below. Remember that this cipher is employed for the secure exchange of keys, and, with this directive, you may option to accept only ciphers and encryption algorithms with strengths you define. The available suites and options are all listed in the mod_ssl documentation.
SSLCipherSuite     {suite}:!{option}:!{option}

Directives for certificates
A Certificate Authority (CA) is basically an authorized user in possession of a digital certificate that permits validation of the server, authenticates the user, and, optionally, permits the CA access to server/client interactions as a valid third party. You can further refine your handling of certificates with these convenient mod_ssl directives.

SSLCertificateFile: The server public certificate file is obviously a very sensitive document. This directive allows you to control where it is stored.
SSLCertificateFile     /usr/local/apache/conf-/ssl.crt/server.crt

SSLCertificateKeyFile: Similarly, this directive gives you control over where the server private key file is located.
SSLCertificateKeyFile     /usr/local/apache/conf-/ssl.key/server.key

SSLCertificateChainFile: This file is your list of accepted CAs. Your server will accept certificates signed by these CAs, so it is an important and powerful list that must be kept secure. It should be server-readable only. This directive gives you control over where it is stored.
SSLCertificateChainFile     /usr/local/apache/conf-/ssl.crt/ca.crt

SSLCACertificatePath: In addition to the list above, your server is storing individual Certificate Authority files. They will be kept in a common directory, which you can specify with this directive.
SSLCACertificatePath     /usr/local/apache/conf-/ssl.crt

SSLRequire: You can set up authorization requirements, including strength of ciphers, IP client addresses, and other options, with this directive. There are a great many options, so refer to your mod_ssl documentation for a complete list. The format of this directive is shown in Listing A.

SSLVerifyClient: This forces the client authentication process.
SLLVerifyClient     require

SSLVerifyDepth: More than one CA can sign a certificate, not all of them known to the server. A server may need to keep track of how many of these unknown CAs are wandering through the door before a known CA signs, completing the authentication. This option permits a limit to be set on the number of unknowns permitted in such a chain:
SSLVerifyDepth     10

Other important features
Finally, here are a couple of utility directives you’ll want to know about.

SSLSessionCache: This directive is used when multiple parallel requests are going to be made. Such requests generate child processes that must renegotiate the SSL session, degrading performance. With this directive, Apache will automatically pass the session information to the child processes (Listing B).

The “memory-to-be-reserved” in Listing B refers to the amount of memory set aside in shared memory cache.

You can also limit the length of time that the server is permitted to reuse session information for these temporary processes.
SSLSessionCacheTimeout     {seconds}

SSLRandomSeed: We’ve all used seed values for random number generators. This is particularly important in cryptography. You can control the particular seed value for random number generation for the session key with this directive.
SSLRandomSeed    startup     builtin

This version hashes a random value from operating system parameters.
SSLRandomSeed     startup file:/dev/random 512

This version specifies that 512 bytes are required by the random number generator. It also points to the virtual file where random data can be found for hashing. Note that if you use this option, the key-generating process won’t proceed until there is enough junk data for seeding and random number generation.