| Table of Contents Previous | Next |
Apache Server Survival Guide |
With the increase in the use of the Internet as a vehicle for commercial transactions, there are more reasons now than ever to protect sensitive information from reaching unintended eyes. A whole slew of secure client/server applications are appearing every day. Also making an inroad is the digital signature technology, which helps certify that messages you received were indeed sent by the sender. Both of these technologies are rooted in the same core of public-key encryption, which is currently the only feasible way of implementing security over an insecure network such as the Internet. The scope of this technology is to ensure that any form of communication that may contain sensitive information is protected while in transit and to assure the receiver that the message was really sent by the sender.
In the case of Web server technology, this is accomplished with a server that implements encryption at the communication level. The current crop of products implementing security are based on the Secure Socket Layer (SSL) protocol specification developed by Netscape Communications for use with their server and browser products. For details on the SSL protocol, visit http://home.netscape.com/newsref/std.
Of the many reasons to use a secure HTTP server, the two most important ones are information privacy and data integrity. If you put sensitive information on your server, you may want to protect your information from being captured or modified by unscrupulous people while in transit. The SSL technology ensures this.
An SSL server is not secure in terms of prohibiting access to unauthorized users. All versions of the Apache server, SSL or plain, provide you with tools and configuration directives to help you control access to your site. The SSL technology only secures or makes it really difficult to spy or modify the transmission of the information from the server to the destination—the communication channel. Servers that contain highly sensitive information and should be secure don't belong on the Internet. The SSL technology is only designed to permit the safe transfer of sensitive data through an unsecured network such as the Internet; this technology is not designed to keep people out of your system.
Two variants of the Apache server, Apache-SSL and Stronghold (Apache-SSL-US), are available. They both provide 128-bit symmetric-key encryption that is fully compatible with the Netscape's SSL protocol. These servers are fully compatible with browsers that understand this protocol. Currently, this includes browser offerings from Netscape, Microsoft, and others.
Because of the technology involved, which flavor of the Apache software you'll be able to legally use will depend on where you live. There are two issues that affect most products that implement encryption technology, including SSL technologies:
Exportation of cryptographic technology is highly restricted and regulated by the U.S. State Department under the International Trade in Arms Regulation. This regulation classifies cryptographic devices, including software, as munitions (as in armament and ammunition).
Ultimately, any export license request for cryptographic technology is passed down for approval to the National Security Agency (NSA). The NSA has jurisdiction over the exportation of cryptographic technology issues because its mandate as an agency is to listen and decode all foreign communications of interest to the security of the United States. Encryption technology can obviously create problems for this agency when they are trying to go about their business. Naturally, from their point of view, they need a policy to eliminate sources of grief where they can. This means putting restrictions on the exportation of U.S. products that implement encryption technology.
In other words, the intention of the law is to reduce or prevent the possibility of some subversive country utilizing a U.S.-developed encryption technology that is too strong and time consuming for the NSA to break. This type of technology could make it difficult to decode information that may adversely affect the security of the United States.
The problem with this law is complex. The NSA will approve (and has done so in the past) exportation of cryptographic technologies that it is able to crack or have some sort of backdoor available for this purpose. Rumor has it that they have all the toys and best minds in the business dedicated to this purpose alone.
From a technology provider's point of view, the problem is that the intention of any cryptographic technology is to make it very difficult to read encrypted data. Even if it was feasible to crack through brute force, the resources needed for this task would approach government budgets. Even then it should take some time to crack. The result is that many encryption products don't make a debut outside of the United States because an international version may have to compromise its security to get the export license or the hassles involved in exporting it are too great. Developers of encryption technology are angry because this policy limits their ability to reach a world market. In a world-information system such as the Internet, it becomes very difficult to police and enforce this type of law.
The second issue regarding use of Apache-SSL, Apache-SSL-US, and other encryption technologies has to do with the patent on public key encryption systems.
The traditional problem with encryption is that in order for the recipient to decode encrypted material, she would need to know the key used by the sender to encrypt it; the sender uses a key (like a password) to encrypt a message. The receiver must use the same key to decrypt it. Since the keys need to be the same, for both encryption and decryption, the problem with this technology (secret-key cryptography) lies in the transmission of the key. Exchange of the key information needs to transpire without anyone else learning it.
This makes the data vulnerable because even though the encrypted data could be easily and securely transmitted over open communication lines, the key portion could not. If anyone else got a hold of your key, be it by looking at your e-mail or listening in on your phone lines, they could decode the information. The more times you transmit and reuse the key, the more vulnerable the key becomes.
To eliminate the problem of key transmission, public-key cryptography was developed. This system uses two keys: a private key and a public key. The private key, as its name suggests, is kept private by its owner. This key is used for decoding information, it is never sent to anyone (see the following note). The public key on the other hand can be freely disseminated and can be publicly posted because it can only be used to encrypt messages destined to its owner.
When you wish to send a message to someone, you would use their public key to encrypt your message. Only the recipient, with his private key, would be able to decipher that message.
A second benefit of public-key cryptography is that it can be used to create digital signatures. Digital signatures are great because they provide digital proof of the sender of the message. If you send a message to me, a value is computed using your private key and the message itself. That value can then be attached to a message. When I receive the message, I can compute another value by using the public key and the message itself. If your digital signature has a mathematical relation to the computed value, then I know that the message was unaltered, and that it was encoded by you. The only way to forge a message is to get a hold of your private key.
RSA, the algorithm that implements public-key encryption, is patented under U.S. Patent 4,405,829, which was issued on August 20, 1983 (this patent expires in the year 2000). The patent is held by Public Key Partners (PKP) of Sunnyvale, California. RSA is licensed under a royalty-based licensing policy, which works as follows:
As mentioned earlier, there are currently two versions of the Apache server implement SSL encryption technology. The SSL technology uses a public-key encryption system to encode the transmission.
Apache-SSL is a set of patches developed in the United Kingdom by Ben Laurie ( ben@algroup.co.uk) that incorporate SSL functionality to Apache. In addition to his patches available from http://www.algroup.co.uk/Apache-SSL, you'll need to obtain the sources to Apache and the SSLeay library to build Apache-SSL. The product is free for both commercial and noncommercial use. It supports 128-bit encryption, client authentication, and all the other features of Apache.
Apache-SSL uses the SSLeay, an implementation of the Netscape's SSL, the software encryption protocol behind Netscape's products. SSLeay was developed by Eric Young as a library that can provide SSL security to any TCP application. This implementation was programmed using only the publicly available protocols and supports DES, RSA, RC4, and IDEA encryption algorithms. You can obtain the SSLeay library from http://www.psy.uq.oz.au/~ftp/Crypto/. However, its use is only legal outside of the United States and Canada because of the patent issues with RSA and RC4.
Stronghold, developed by Community ConneXion ( http://www.us.apache-ssl.com), also uses the SSLeay SSL implementation. However, it licenses the RSAREF libraries from RSA Data Security Inc., which provide SSL configuration documentation. Stronghold also provides Certificate of Authority tools. Stronghold is free for noncommercial use. Commercial users must pay a licensing fee of $495.00. Customers upgrading from a competing SSL Web server from Netscape have a special discount price of $295.00.
Some of the technical differences between Apache-SSL and Stronghold are the licensing of the RSA technology, availability of the CA, additional software tools, and availability of support. Apache-SSL's SSL implementation doesn't license the RSA technology; Stronghold does. Because Stronghold licenses the RSAREF libraries, it is an approved product. So VeriSign, an offshoot of RSA, will issue a Certificate Authority (CA) for Stronghold, although in the future they may also do it for Apache-SSL. Stronghold also provides additional tools useful for creating new certificates and manage existing ones. Lastly and most importantly, you can think of Stronghold as shrink-wrap. Commercial licenses of Stronghold (paid versions) are entitled for technical support. The Stronghold software is also much easier to install because it comes as a complete package, not just as a set of patches. Stronghold is currently compatible with 16 platforms including SunOS, Sparc, Solaris, X86 Solaris, AIX, BSDI, Linux (ELF & a.out), FreeBSD, IRIX, UnixWare, Ultrix, DG/UX, HP-UX, OSF/1, and NEXTSTEP.
As I mentioned earlier, which version of Apache you are allowed to use depends on where you live. If you live in the United States or Canada, you must use Stronghold (Apache-SSL-US). This version of Apache uses the same SSLeay libraries as Apache-SSL, but it licenses the RSA libraries. By licensing the RSA libraries, Community ConneXions eliminated the patent issues associated with the RSA public-key encryption implemented by the SSLeay libraries.
To add another twist, by legalizing Stronghold in the United States by incorporating the RSA libraries, exportation of Stronghold now falls under the regulations of the U.S. State Department under the International Trade in Arms Regulation, making its use only possible in the United States and Canada. Stronghold is not licensed to be exported outside of the United States under the current law.
In you live outside of the United States and Canada, then the United States patent on the public-key cryptographic system doesn't apply to you. Apache-SSL, with its own implementation of the RSA algorithm that doesn't incorporate any code from the RSAREF toolkit, can be used legally anywhere but in the United States and Canada. In those two countries it violates U.S. patent law. To be certain, you may also want to become aware of other local restrictions and regulations regarding the use of cryptographic technology before you implement a server that uses this technology.
For users outside of the U.S. and Canada, Apache-SSL is distributed in patch form (note the version of the patches). The patches can be obtained from http://www.algroup.co.uk/Apache-SSL. You'll also need the SSLeay libraries, available in source form from http://www.psy.uq.oz.au/~ftp/Crypto, and pick the latest version. You'll also need to verify that you have a matching version of the Apache server from http://www.apache.org.
As of this writing, the patches were for Apache version 1.1.1. The files you'll need are
Apache source: apache_1.1.1.tar.gz
SSLeay library: SSLeay-0.6.3.tar.gz
SSL patches: apache_1.1.1+1.3.ssl.tar.gz
You should move all the distribution files to a directory. You can use Apache Server as a temporary holder. Here's how the patches are unpacked and applied. Note that apache_1.1.1+1.3.ssl.tar.gz is unpacked in the Apache 1.1.1 distribution directory. Doing this will install additional files for the patch program as well as create some files unique to the SSL distribution. The SSL patches are applied with the patch utility. If your system does not have patch, I have included a copy on the CD-ROM. Otherwise, you can download the latest version from ftp://prep.ai.mit.edu/systems/gnu/patch-2.1.tar.gz.
Before compiling SSLeay, read the INSTALL document. Then edit Makefile.ssl to match your system configuration. If your perl binary is in /usr/local/bin/perl and you don't mind installing the libraries and other programs in /usr/local/ssl, all you may need to do is set up your compiler options.. When you are done, run the Configure program. Here's a listing of the commands you'll need to apply:
% mkdir ApacheServer % mv apache_1.1.1 ApacheServer % mv SSLeay-0.6.3.tar.gz ApacheServer % cd ApacheServer % gzcat apache_1.1.1.tar.gz | tar -xf - % cd apache_1.1.1 % gzcat ../apache_1.1.1+1.3.ssl.tar.gz | tar -xf - % patch < SSLpatch % cd .. % gzcat SSLeay-0.6.3.tar.gz | tar -xf - % cd SSLeay-0.6.3 % ./Configure os-compiler
Replace os-compiler with the name of your system. To see a list of available configurations, run Configure, but don't provide an argument. Run by issuing make at the command prompt:
% make
After a while the libraries and tools will be built. To install them in their proper places, execute as root: make install.
After the libraries compile properly, you'll need to edit the Apache src/Configuration file. For an idea of a basic configuration, see Chapter 2, "Installing and Configuring the Apache Server." The SSL patch installed a few more directives in this file that you need to set values for. The ones you'll want to look for are SSL_BASE.
I set SSL_BASE=../../SSLeay-0.6.1 to the location of our SSLeay-0.6.1 distribution. You should be able to do a make and the binary httpsd will be built. Move the httpsd binary to the apache_1.1.1 directory:
% mv httpsd ../
At this point your software is properly installed. The next step is configuring the software and generating a CA so that you can use the software.
Before you configure Apache-SSL you'll need to generate a Certificate Request. A test certificate can be generated simply by issuing a make certificate in the apache-sll/src directory:
control1 > make certificate ../../SSLeay-0.6.1/apps/ssleay req -config ../../SSLeay-0.6.1/apps/ssleay.conf -new -x509 -nodes -out ../SSLconf/conf/httpsd.pem -keyout ../SSLconf/conf/httpsd.pem; ln -s ../SSLconf/conf/httpsd.pem ../SSLconf/conf/`../ ../SSLeay-0.6.1/apps/ssleay x509 -noout -hash < ../SSLconf/conf/httpsd.pem`.0 Generating a 512 bit private key ..+++++ .....................+++++ writing new private key to '../SSLconf/conf/httpsd.pem'
Next, you'll be prompted to enter information about yourself and your company. Follow the directions:
You are about to be asked to enter information that will be incorperated 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) [AU]:DO State or Province Name (full name) [Queensland]:Distrito Nacional Locality Name (eg, city) []:Santo Domingo Organization Name (eg, company) [Mincom Pty Ltd]:CXA Organizational Unit Name (eg, section) [MTR]:"" Common Name (eg, YOUR name) []: Email Address []:webmaster@CXA.DO
Next, you'll need to edit the SSLconf/conf/httpd.conf file. This file contains many of the same configuration directives as conf/httpd.conf, but it also includes directives for specifying the location of the certificate and other things. The directives you need to set are fully documented.
Stronghold comes as a prebuilt binary, and it is by far the easiest Apache server to install. Community ConneXion has made a very nice interactive shell script that installs and configures both servers (the distribution includes both the non-SSL version of Apache (httpd) and Stronghold (httpsd). A future version, currently under development, will implement both the secure and plain servers in one server process.
To start the installation process, type the following:
# ./Install.sh
The program will show you a list of the available prebuilt binaries (if your distribution contains more than one). Enter the name of the operating system matching your platform like this:
Available platforms: Pick your platform > NS
Next, it will ask you where to store the SSL security utilities. Enter a different pathname if you want Stronghold stored elsewhere.
Where do you want to install SSLeay? [/usr/local/ssl] Testing permissions...done Installing SSLeay...done
The installation script will then ask for the name of the directory where Stronghold will store Apache and other files necessary for the operation of the Web server.
Where would you like to locate the ServerRoot? [/usr/local/apache]
Next it will request a directory for the normal logs (nonsecure transactions).
Where would you like to locate the non-SSL logs? [/usr/local/apache/logs]
And for the secure transaction logs:
Where would you like to locate the SSL logs? [/usr/local/apache/ssl_logs]
Next, the script will configure some of the server runtime configuration directives. First, it will request the server name. If the server will use an alias such as www.company.com, enter that name here:
What's the name of your server? [www.company.com]
Next, it will ask you for the e-mail address for the administrator responsible for this site. This address gets returned to the client in case of an error:
What is the email address of the server admin? [webmaster@company.com]
Next, it will ask you for the TCP port address for the plain (non-SSL) server. The standard HTTP port is 80:
What port do you want to run the plain server on? [80]
Next, it will ask you for the TCP port address for the SSL server. The standard SSL port is 443:
What port do you want to run the SSL server on? [443]
The following setting will control the user ID (UID) that the children server processes will run as. It should be set to a UID with minimal privileges, such as nobody:
What user should the server run as? [nobody]
Never set the UID the server runs as to root!
The final setting will control the group ID (GID) that the children server processes will run as. It should be set to a UID with minimal privileges, such as nogroup:
What group should the server run as? [nogroup] Installing Stronghold...done Configuring Stronghold...done
At this point the basic software is configured. The installation program will add the /usr/local/ssl path to your environment. This will allow you to use the installed utilities without having to type their complete pathnames. You should follow the instructions printed by the program and add them to your .cshrc, .login, or .profile files. The instructions printed are:
Now you must add SSLTOP=/usr/local/ssl to your environment. Also add /usr/local/ssl/bin to your PATH. Edit your .cshrc, .login, or .profile appropriately: csh: > setenv SSLTOP /usr/local/ssl > setenv PATH /usr/local/ssl/bin:/etc:/usr/etc:/usr/ucb:/bin:/usr/bin:/usr/ local/bin:/usr/sybase/bin:/. sh: $ SSLTOP=/usr/local/ssl $ PATH=/usr/local/ssl/bin:/etc:/usr/etc:/usr/ucb:/bin:/usr/bin:/usr/local/bin:/ usr/sybase/bin $ export SSLTOP PATHHit return when ready:
You now need to generate the public/private encryption key pair. If you don't have an existing key, type B and follow the instructions:
Now you need to install a key/cert pair. A) Convert an existing Netscape Commerce key/cert pair B) Generate a new key/cert pair Choose [A/B] B The key will be called www.key. The certificate will be called www.cert. They will be stored in /usr/local/ssl Hit return: ********* READ ME ************* You are now generating a new key and key request. The key request will be sent to the CA of your choice and the keyfile will reside /usr/local/ssl/private/www.key. If you have already sent off a key request for this server before, make sure you aren't overwriting your old key which is awaiting a corresponding certificate from your CA. If they key generation fails, move the file /usr/local/ssl/private/www.key to a backup location and try again. ********* READ ME ************* Hit return: Choose the size of your key. The smaller the key you choose the faster your server response will be, but you'll have less security. Keys of less than 512 bits are trivially cracked, while for high security applications you probably don't want a key of less than 1024 bits. Choosing an appropriate keysize is your responsibility. How many bits of key (384 minimum, 1024 maximum): 1024 Now we will generate some random data, using the truerand library developed by Matt Blaze, Jim Reeds, and Jack Lacy at AT&T. This may take some time. Generating 2048 bits of randomness................................................................ Now we generate more random data, from keystrokes We need to generate 2048 random bits. This is done by measuring the time intervals between your keystrokes. Please enter some random text on your keyboard until you hear the beep: 0 * -Enough, thank you. Finally, choose some files with random bits, to complete our random number seed generation. You might want to put in logfiles, utmp, wtmp, etc. Once the key is generated you will be asked to enter a PEM pass phrase. This is the pass phrase used to encrypt the key on the disk. --- DO NOT LOSE THIS PASS PHRASE --- Enter colon-seperated list of files: /usr/adm/messages Now we are generating the key. This may also take some time. Be patient. The passphrase you enter here is very important. Do not lose it. 22320 semi-random bytes loaded Generating RSA private key, 1024 bit long modulus .+++++ ........................................................+++++ e is 65537 (0x10001)
Next, you'll enter the permission phrase (your private password). Characters entered here are not echoed. Do NOT forget your permission phrase! Enter the following:
Enter PEM pass phrase: Verifying password Enter PEM pass phrase: Key generated
If you would like to send your Certificate Signing Request (CSR) to a CA, type y, otherwise type n. If you type y, the CSR will be sent to the CA. This process costs $290.00 from VeriSign. The session to prepare the Certificate Signing Request looks like this:
Would you like to send a Certificate Request to a CA? [Y/n] n Not generating CSR Now we will create a self-signed certificate for use until the CA of your choice signs your certificate. You will have to use this cert until your CA responds with the actual signed certificate. Enter PEM pass phrase: You are about to be asked to enter information that will be incorperated 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) [US]: State or Province Name (full name) [California]:Somestate Locality Name (city, town, etc.) [Springfield]:Somecity Organization Name (company) [Random Corporation]:company, com. Organizational Unit Name (division) [Secure Services Division]: Common Name (webserver FQDN) [www.random.com]:www.company.com --COMPLETE-- Your key has been generated and a test certificate has been installed --COMPLETE-- Starting the server... helium: Jul 22 23:41:19 1996 UTC - Aug 21 23:41:19 1996 UTC WARNING: Certificate expires in 29 day(s)
Before the SSL server starts, you'll be asked to enter the permission phrase. This is done because the server is trying to access an encrypted file. The prompt will look like the following:
Enter PEM pass phrase:
Congratulations! Your secure server is now running. To access it you'll need an SSL-compliant browser. Secure servers are accessed by specifying an extra s following http (http secure) https://www.company.com URL. The visual differences between a secure and nonsecure site are shown in Figures 14.1 and 14.2.
To start and stop the server, use the scripts created by the installation program, start and stop.
In the case of Netscape, accessing the secure site causes the browser to show warnings because it doesn't know who certified this site. If the Certificate Request that you prepared earlier was approved by one of the authorities, such as VeriSign, the browser will not show these warnings.
As of the second beta, Microsoft Internet Explorer (MIE) will not allow you to access a secure site when the CA was unknown to the software. Netscape Navigator had this same sort of behavior in its 1.x release. You'd think Microsoft would think about this possibility!
Figure 14.1. The installed SSL server looks like this when viewed by Netscape. Note the bar under the address area and the icon on the lower left corner (on the computer the bars are rendered in blue).
Figure 14.2. A plain server looks like this when viewed by Netscape. Note the bar under the address area is missing, and the key icon is broken.
In addition to generating a key pair when doing the initial installation, you can use the genkey program to generate additional keys. Why do you need the key pair? The server generates a private and public key pair. The public key is used to encrypt transmissions to the server. The server's private key is used to decrypt the transmissions. Only the private key can be used to decrypt an encrypted message. It is kept in the server while the public key is sent to the client.
In addition to the private/public key pair, genkey generates a CSR for sending to a CA—an entity that acts as a notary public, authenticating that the holder of a certificate is indeed the entity listed in the certificate itself. The certificate contains your server's public key, an expiration date, information about your organization, and the digital signature of the issuer.
When a server starts up a secure connection, it transmits the certificate to the client. The client decodes it by revealing your public key, an expiration date, information about your organization, and the digital signature of the issuer it displays to the user. The client then authenticates that the certificate has not been altered, and that it is signed by a CA it knows. This allows the client to generate a symmetric key that it can use to communicate with the server.
The genkey program allows you to generate the key pair and e-mail it to a CA, typically VeriSign. The certification process costs $290 and takes a few days. To complete the certification process, VeriSign will request more information about you or your organization before they issue the CA for your server. For more information, please visit http://www.verisign.com.
Once you receive your certificate, you must install it using the getca program. Remember to save a copy of this certificate in a safe place. As root install it with the following commands:
# getca hostname < certificate
hostname is your fully qualified hostname. certificate is the path to the certificate. Don't keep copies of your certificate laying around!
Most of the time you will only need to get one certificate. You will need to get an additional certificate if you are
However, there may be creative ways of reducing your costs. Using Apache virtual hosts (described in Chapter 4, "Virtual Hosts"), you could implement a common site in your organization that handles all secure transactions for the various divisions in your organization, such as a point of sale system. All you need to do is create a link from your HTML to the secure URL when you need to transfer information via a secure environment. The secure server will then handle all secure transactions for all the other sites. Just remember to leave the "Organization Unit" field blank during configuration so that you don't confuse visitors. You may want to consider that while the most popular browsers support SSL, some may not, and you may want to offer a nonsecure transaction choice.
The SSL distribution also includes a number of program utilities to help you manage your certificates and passwords.
| change_pass | Sets the passphrase used to encrypt the server's private key. The private key should be kept encrypted to avoid any problems if someone obtains it. However, an encrypted private key will require providing a passphrase every time the server is started. |
| decrypt_key | This utility decrypts the private key to allow the server to start without requesting a passphrase. Having an unencrypted private key may jeopardize your key if someone is able to obtain it. |
| gencert | This tool is used to generate a test certificate. It also allows you use private certificate authorities such as yourself (you authorize your own CA). Third-party tools are available to help you implement a more complex CA. For information, visit http://www.xcert.com. |
| genkey | This utility generates a private/public key pair and a CSR that you can send to a CA, such as VeriSign, for processing. |
| getca | This utility installs a certificate provided by a CA such as VeriSign. |
| getreq | This utility generates a CSR based on an existing private key located in $SSLTOP/private/hostname.private |
| makeca | This utility sets up a self-signed CA for Stronghold. |
| renewal | This utility submits a certificate renewal request to your CA. |
Apache SSL extensions are incorporated into Apache via ssl_module. This module provides a number of configuration directives that you can use to control where the server will find configuration files, logs, and certificates among other things. Most of these configuration files are written to a httpd.conf file that resides in the ssl_conf directory if you are using Stronghold, or in SSLconf/conf/ directory for Apache-SSL installations.
These directives can be used in a <VirtualHost> section. However, note that browsers such as Netscape Navigator 2.x and better check the URL against the hostname on the server certificate. This requires that you provide a different certificate for each virtual host you house.
Syntax: BanCipher cipher
Scope: server configuration, directory, virtual host
This directive limits the use of ciphers that do not meet your security requirements for a particular directory:
<Directory path> BanCipher cypher </Directory>
| Syntax: | RequireCipher cipher |
| Scope: | server configuration, directory, virtual host |
This directive is typically used inside a <Directory> section to require a specific cipher for the specified directory:
<Directory path> RequireCipher cipher </Directory>
cipher can be any of the following cipher types:
| Cipher Type | Description |
| NULL-MD5 | No encryption, MD5 hash |
| RC4-MD5 | Export-controlled, RC4-compatible cipher; MD5 hash |
| EXP-RC4-MD5 | 8-cent–secure, RC4-compatible cipher; MD5 hash |
| RC2-CBC-MD5 | Export-controlled, RC2-compatible cipher in CBC mode; MD5 hash |
| EXP-RC2-CBC-MD5 | Export-crippled, RC2-compatible in CBC mode; MD5 hash |
| IDEA-CBC-MD5 | IDEA cipher in CBC mode, MD5 hash |
| DES-CBC-MD5 | DES in CBC, MD5 hash |
| DES-CBC-SHA | DES in CBC, SHA hash |
| DES-CBC3-MD5 | 3DES in CBC, MD5 hash |
| DES-CBC3-SHA | 3DES in CBC, SHA hash |
| DES-CFB-M1 | DES in CFB |
| Syntax: | SSLCACertificateFile filepath |
| Scope: | server configuration, virtual host |
The SSLCACertificateFile directive specifies the trusted CA root client certificate file instead of a certificate directory like the following SSLCACertificatePath directive.
| Syntax: | SSLCACertificatePath path |
| Scope: | server configuration, virtual host |
The SSLCACertificatePath directive specifies a path were trusted CA root certificates can be found. Root certificates for client certification should be stored here.
| Syntax: | SSLErrorFile filename |
| Default: | SSLErrorFile SSLLogFile |
| Scope: | server configuration, virtual host |
The SSLErrorFile directive specifies a file where error messages and SSL-diagnostic output are sent. If omitted, these messages are logged to the file specified with the SSLLogFile directive.
| Syntax: | SSLFakeBasicAuth |
| Scope: | server configuration, virtual host |
If set, this option will translate client X509 in usernames that can be used for authentication.
| Syntax: | SSLLogFile filename |
| Scope: | server configuration, virtual host |
The SSLErrorFile directive specifies a file where all SSL connections to the server are logged. It stores cipher and client authentication data.
| Syntax: | SSLRequireCiphers cipher:cipher:cipher... |
| Scope: | server configuration |
This is a colon (:)-delimited list of cipher types permitted for all SSL transmission in order of preference.
| Syntax: | SSLRoot path |
| Default: | SSLRoot /usr/local/ssl |
| Scope: | server configuration, virtual host |
The SSLRoot directive specifies where the SSL directory tree lives. path is prepended to all SSL file directives (except for the logging directives) that don't specify an absolute path.
| Syntax: | SSLVerifyClient [0] | [1] | [2] |
| Default: | SSLVerifyClient 0 |
| Scope: | server configuration, virtual host |
This directive sets the X.509 Client Authentication option:
| Option | Value |
| 0 | No certification is required. |
| 1 | X.509 certificate is optional. |
| 2 | X.509 certificate is required. |
Client authentication can be an effective way of restricting access to your Web site.
| Syntax: | SSLVerifyDepth n |
| Default: | SSLVerifyDepth 0 |
| Scope: | server configuration, virtual host |
This directive controls the depth that the server will follow when verifying client certificates. The server will progressively search the CA chain until it reaches a decisive authority or reaches n.
Secure transactions are the foundation for the commercialization of the Web. Currently there are a lot people looking at what's new, but not many people are using the Internet to purchase things. Most buyers have been frightened by the media into thinking that shopping the Internet could lead to someone using your credit card to make fraudulent charges. While this is possible, the real issue here is privacy and assurance that the person or company you are communicating with is indeed who they say they are. In the electronic age, the need for this technology is undeniable.
The Internet makes it possible to put bits of information about yourself together that are much more descriptive about you as a person. If you are using the Web to connect to another system, it is trivial for me to figure out what machine you are connecting from because this information is sent with every request you make. Some browsers, such as Internet Explorer, send additional information, such as the computer processor you are running and the color capabilities of your monitor. If you happen to be running some version of UNIX that allows fingering of your machine, there's a good chance of figuring out your name and address. With your name, it's easy to find your telephone number and everything you may have posted to Usenet. From that your hobbies and interests can be determined. With your address, it's easy to get a map of how to get to you or find where junk mail can be sent. All it takes is a few seconds. As more and more information about us floats out there, the scarier it becomes.
Encryption may solve one of the problems—how to avoid thugs from looking up your credit card number or some other important information. However, it doesn't do anything about other information that can easily be extracted from just pointing a Web browser to some URL.
