FreeBSD includes several Web servers, but the most popular on the Internet, by far, is Apache.

The Apache Web Server

If you look under /usr/ports/www, you'll see several different ports with "apache" in their names. Most of these are slightly different versions of the Apache Web server, and before installing anything, you'll need to pick a version. Here's a brief look at your options.

apache13−modssl This port includes modular Secure Sockets Layer (SSL) support, for secure

To build the programs in the most efficient manner possible, you can choose to build Apache from ports. This takes longer to build, but results in a stronger, better, faster Web server. To enable this option, set APACHE_PERF_TUNING=YES when building your chosen port:

...............................................................................................

# make APACHE_PERF_TUNING=YES all install

...............................................................................................

Apache Configuration Files

You'll find Apache's main configuration files in /usr/local/etc/apache. There are five main files: access.conf, httpd.conf, magic, mime.types, and srm.conf. Originally, Apache used all five files extensively, but these days httpd.conf, magic, and mime.types are the ones most often used. (The functions in access.conf and srm.conf have been rolled into httpd.conf; the original files remain mostly for us older admins who expect to find them.)

336

To properly administer Apache, you need to understand what each of these files is for and how to manage them.

Mime.types

The mime.types file contains a list of all standard file types and their identifying characteristics. All Web servers must identify the type of file they are transmitting to the client, so that the client can take appropriate actions. For example, most Web browsers open up a PDF reader when they download a PDF. The mappings contained in mime.types give Apache the information it needs to support this functionality. You should almost never have to touch this file, unless you are specifically told to in a program's documentation.

Magic

This file contains identifying characteristics for a variety of unusual file types that the mime.types file cannot cope with. Because the mime.types file can't deal with all of the file types in the world, Apache's built−in mime_magic module uses the magic file to try to identify unknown files. You should never have to touch the magic file, unless a program's installation documentation explicitly tells you to.

Httpd.conf

The httpd.conf file controls the Web server's behavior, and it's where the interesting things happen. This file is well commented (any line beginning with pound sign (#) is a comment), so we won't discuss it in much detail; we'll leave the discussion of every possible Apache configuration for much bigger books. Most of Apache's configuration takes place in this file, however, so we can't escape it entirely.

Configuring Apache

The best way to create an Apache configuration file is to edit and use the sample primary configuration file (httpd.conf). But whatever you do, don't touch what you don't understand. Unlike your DNS server, you don't want to create an Apache configuration from scratch! The default httpd.conf contains large sections that control things like character−set handling, and unless you really want your Web server's handling of the Chinese language to be completely different from any other Web server on the planet, your best bet is to leave these settings alone.

Note The arrangement of the default httpd.conf file is a bit irregular. While it probably makes sense to the authors, the rest of us are left scratching our heads if we try to just sit down and read it. (It doesn't help that the default file is over 1,000 lines long!) That said, we'll discuss the configuration options in a more sensible order.

Server−Wide Settings

The following configuration options define general server behavior.

Server Root Path

The ServerRoot setting specifies the path to the main Web site files.

...............................................................................................

ServerRoot "/usr/local"

...............................................................................................

337

If your server handles a single large site, you might want to point this at a different location on a partition dedicated to Web files.

Note When you reference another file in httpd.conf, Apache prepends the ServerRoot to it unless you begin the filename with a slash (/). For example, if your ServerRoot is /usr/local, " d o c s / c g i − b i n " w o u l d b e c o m e " / u s r / l o c a l / d o c s / c g i − b i n " , w h i l e "/usr/local/etc/apache/vhost.conf" would remain unchanged.

Document Root Path

...............................................................................................

DocumentRoot "/usr/local/www/data"

...............................................................................................

The HTML documents for the main Web site go in the DocumentRoot directory.

Httpd Servers

...............................................................................................

MinSpareServers 5

MaxSpareServers 10

StartServers 5

...............................................................................................

If you do a ps −ax on your server, You'll see a number of httpd processes because each request to the Web server is handled by a separate process. When a dozen people all type in your Web server's URL and hit ENTER simultaneously, a separate process handles each request. This is part of how Apache can handle such a high load.

When Apache first starts, it fires up a number of httpd processes equal to the StartServers value. Every so often, it checks to see how many httpd processes are running, and how many are actually serving content. In order to guarantee that there are enough httpd processes to handle additional requests, Apache keeps MinSpareServers and MaxSpareServers around.

If your Web server suffers from sudden floods of traffic, you might want to increase the

MinSpareServers and MaxSpareServers values. The StartServers value shouldn't need to be increased, though, because even if you were to shut down and restart Apache, it can handle several hundred httpd processes in just a few seconds.

Maximum Number of Clients

...............................................................................................

MaxClients 150

338

...............................................................................................

MaxClients specifies the maximum number of httpd processes that Apache is allowed to run at one time, and when this limit is reached, the Web server might appear to be unavailable. This limit is designed for older systems, and can easily be increased on more modern computers. Experiment to see how many httpd processes your system needs.

Note You can see how many httpd processes are running at any given time by running ps −ax | grep httpd | wc −l.

Maximum Httpd Requests

Each httpd process that starts answers requests and then hangs around waiting for the next request. If you have a fancy Web program that leaks memory, making each httpd process use more and more memory, You'll see the size of each httpd process increase when you run top.

If you have this memory usage problem, you can set MaxRequestsPerChild to shut down a process after it handles a set number of requests. Setting this to 0 means that each process can handle an unlimited number of requests:

...............................................................................................

MaxRequestsPerChild 0

...............................................................................................

Most FreeBSD systems run just fine with this set to 0, but you can change this option if you find that you have many httpd processes using a lot of memory. If that's the case, the problem is usually due to some Web application.

Listen

...............................................................................................

Listen 80

...............................................................................................

The Listen option controls which TCP ports or IP addresses Apache will bind to. You can specify individual IP addresses like this:

...............................................................................................

Listen 192.168.8.44

...............................................................................................

Then combine this with a port number to run Apache on an unusual port:

...............................................................................................

Listen 192.168.8.44:88

...............................................................................................

Or, you can listen on all the IP addresses on the system, on an unusual port:

339

...............................................................................................

Listen 88

...............................................................................................

You can use multiple Listen statements to make Apache available on any port or IP address on your system.

BindAddress

...............................................................................................

BindAddress *

...............................................................................................

Much like the Listen statement, BindAddress controls which IP address Apache attaches to. By default, Apache attaches to every port on the system, but you can restrict it to a single IP address with this option. BindAddress is basically identical to Listen.

Modules

...............................................................................................

LoadModule

AddModule

...............................................................................................

You can add functions to Apache with these modules. The modules listed in the base configuration provide basic Apache functionality, so don't alter the existing LoadModule and AddModule statements unless you know exactly what you're doing. (We'll discuss Apache modules in more detail in the "Apache Modules" section later in the chapter.)

Port

...............................................................................................

Port 80

...............................................................................................

This is the TCP port that Apache listens on. You can use multiple Port statements.

User and Group

...............................................................................................

340

User www Group www

...............................................................................................

These options specify the UNIX user and group that Apache runs as. Just as you can log into your FreeBSD system and start a program that runs with your permissions, the Apache Web server expects to be started by a particular user and use that user's permissions.

Recent FreeBSD systems ship with the user www and group www, generic accounts with no privileges that are intended for use by the Web server. (You can't log in as www.) While You'll sometimes see a document that suggests running Apache as root, don't run the Web server as root, whatever you do; if an intruder breaks into your Web server, they'll get root on your system as a side benefit!

Administrator Email Address

...............................................................................................

ServerAdmin webmaster@AbsoluteBSD.com

...............................................................................................

This setting specifies the email address of the person who runs the server. If someone notices a problem with your server, this is where he will be told to send email.

Server Name

...............................................................................................

ServerName www.AbsoluteBSD.com

...............................................................................................

This is a name of the Web site. It must be a real hostname, and whatever name you give must have a DNS entry or Apache won't start. For testing purposes, though, you can use an entry in /etc/hosts instead of an actual DNS entry.

Directory Index

The DirectoryIndex statement gives the name of the default document in a directory. When a client calls up a directory, rather than a filename, Apache checks for files with this name, in order.

...............................................................................................

DirectoryIndex index.php index.html

...............................................................................................

Here, if a Web browser calls up http://www.AbsoluteBSD.com/refunds/, Apache checks for index.php and then index.html, and returns the first it finds.

341

The default httpd.conf file has a fairly complicated set of rules for determining the DirectoryIndex setting. This is an excellent example of a conditional setting that is based on the modules loaded. You can strip out all that and replace it with a simple one−line entry, if you're not using any of these advanced modules.

Hostname Lookup for Logs

...............................................................................................

HostnameLookups Off

...............................................................................................

This setting controls whether Apache saves IP addresses or hostnames to its logs. Enabling this makes your logs look nicer, with computer names instead of IP addresses, but you should leave it off as a general rule. Turning it on will simply add load to your server, and most log−file analysis programs can do this lookup on their own.

Error Log Location

...............................................................................................

ErrorLog /var/log/httpd−error.log

...............................................................................................

This is the location of the error log.

Logging Level

...............................................................................................

LogLevel warn

...............................................................................................

The LogLevel statement controls the amount of data logged. Valid labels are debug, info, notice, warn, error, crit, alert, and emerg. The system logger uses these labels to determine the amount of data logged. The warn setting is a good, median level.

Log Format

...............................................................................................

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User−Agent}i\"" combined

...............................................................................................

342

The LogFormat statement controls the data logged by the server. There are several different default LogFormat settings established for your convenience:

∙The "common" format logs the IP address of the client, the time of the request, the file requested, and a few other basic things.

∙The "referrer" format logs the site that referred the client–meaning, another Web page with a link to yours.

∙The "agent" format records the Web browser used.

∙The "combined" format logs all of the above. (This can generate very large logs, so be sure you have lots of disk space.)

Note If you dig through the Apache documentation, you can write your own LogFormat statements easily enough. The formats mentioned here are understood by all the popular Web log analysis programs, however, so don't change them arbitrarily

Custom Logs

...............................................................................................

CustomLog /var/log/httpd−access.log combined

...............................................................................................

The CustomLog statement controls the name of the log file and the format used. In the preceding example, the main Web site logs to /var/log/httpd−access.log in the "combined" format.

You can have several CustomLog statements for different purposes. For example, if you're using an Apache module that provides special functionality that you want logged, but you don't want to break the WebTrends product being used by your clients, you can use multiple CustomLog statements to write to two separate log files.

Aliases

...............................................................................................

Alias /icons/ "/usr/local/www/icons/"

...............................................................................................

Use the Alias statement to provide aliases for directories on your Web site, much like a symlink. In the preceding example, someone looking at http://www.AbsoluteBSD.com/icons/ would actually be pulling files from the directory /usr/local/www/icons/.

343

Error Document

...............................................................................................

ErrorDocument 404 /missing.html

...............................................................................................

When a browser requests a document that's not on the server, the server returns an error. You can create a custom error page with the ErrorDocument directive.

Include

...............................................................................................

Include /usr/local/etc/apache/vhosts.conf

...............................................................................................

The httpd.conf file can include other files, a feature that can be useful when you have several subsystems maintained by different people. This can also be useful if you want to make your configuration easier to digest.

For example, many add−on Apache modules have their own bits of configuration code. It's simpler to give each model its own configuration file and include it than to pile it on the main httpd.conf file. Similarly, if you have a person whose job it is to maintain virtual hosts, you can create a virtual hosts file with permissions that allow that person (or group of people) to maintain it (see Chapter 8).

Directory Configuration

Apache has many nifty features, but it's not a good idea to enable everything everywhere–a bit of sloppy programming can result in your giving out too much information from your Web site, or even letting someone break in.

Permissions to access Apache functions are set on a directory−by−directory basis. The configuration looks much like XML: You have a Directory label in angle brackets, a list of permissions and settings, and then a closing directory entry with a backslash. Any options or settings between the opening and closing Directory statements affect that directory. Here's the basic format:

...............................................................................................

<Directory /path/to/files>

...options and settings here

</Directory>

...............................................................................................

By default, Apache uses very restrictive permissions and settings. For example, You'll see the following entry right at the top of the directory listings in httpd.conf:

344

...............................................................................................

<Directory />

Options FollowSymLinks AllowOverride None

</Directory>

...............................................................................................

Apache allows users to upload their own configuration files to change the server's behavior–in short, to let users specify their own options, password protection, MIME types, and so on. The AllowOverride None line shown in the preceding example means that users can't set these options on a directory unless we say so.

And yes, that slash (/) represents the ServerRoot directory, as specified in the systemwide options. Unless specified otherwise, every directory on the server has these permissions, though you can override these settings on particular directories. (We'll briefly discuss the various permission options in "Directory Configuration," later in this chapter; for now, just realize that nobody does diddly without our say−so.) To loosen permissions on a directory−by−directory basis, have a look at the default httpd.conf, where You'll find a set of looser permissions set on various directories.

Directory Features

Now that we've disallowed every feature Apache offers, we can explicitly enable the features we'd like to have. They will allow your Web designers to do many different things, but as an administrator you need to know what each one does. Here are some of the features you might set on a directory.

Controlling Access with IP Addresses and Netblocks

The Allow and Deny options control which IP addresses and hostnames are permitted to access content in a directory. Browser clients are compared against the "allow" and "deny" lists in the order given in the Order statement. Apache then permits or rejects access depending on the results. When Order is deny, allow, the default is to allow access unless prohibited by a Deny statement. When Order is allow,deny, the default is to deny access unless permitted by an Allow statement.

You allow and deny hosts by IP address and hostnames. Every attempted connection is compared against these descriptions, and is treated appropriately. Every attempted connection is part of a special group, All. Much like with TCP Wrappers, you can use the All group and more specific client identification to allow and exclude particular hosts.

Confused? Let's walk through a sample.

...............................................................................................

Order allow,deny

Allow from all

Deny from *.AbsoluteBSD.com

...............................................................................................

I'm browsing to a site from an http://absolutebsd.com/ machine. Apache first checks the Order list (because this is the first statement it encounters), and is told to look at the Allow list and then the Deny list. Since http://absolutebsd.com/ is part of all, I'm allowed in at first. But then Apache checks the deny list and, whoops, I'm cut off.

345

Note that Apache gets the hostnames from reverse DNS. Because, in many cases, it's trivial for an administrator to change the reverse DNS hostname, you're safer using IP addresses, or even blocks of IP addresses, to control access.

All of the following are legitimate types of IP address and IP address block arguments for an Allow or Deny statement.

...............................................................................................

192.168.0.1,192.168.0.2,192.168.0.3

192.168

192.168.0.0/16

192.168.0.0/255.255.0.0

...............................................................................................

The first line here controls a series of three IP addresses. The last three lines mean exactly the same thing as each other, and are simply three different ways of expressing all IP addresses beginning with 192.168.

You can easily restrict access to your internal Web site to only company IP addresses by doing something like this:

...............................................................................................

Order allow,deny

Allow from 192.168.1/24

Deny from all

...............................................................................................

(This, of course, assumes that your company firewall is configured to block spoofed traffic.)

Httpd.conf Options

Options are general server features that can be enabled and disabled on a directory−by−directory basis. They allow a Web developer to do all sorts of nifty tricks, such as execute programs on the server, enable and disable password protection on directories, and change language handling. These options give the Web developer a lot of power, and they can also generate a lot of support calls, so you need to know what each is and how it works.

You specify options inside a directory with the Options keyword. For example, to enable the ExecCGI option for the directory /usr/local/www/data/catalog, you would use the following configuration:

...............................................................................................

<directory /usr/local/www/data/catalog>

Options ExecCGI

</directory /usr/local/www/data/catalog>

...............................................................................................

You can also specify multiple options on a single line:

...............................................................................................

346

<directory /usr/local/www/data/catalog> Options ExecCGI,MultiViews

</directory /usr/local/www/data/catalog>

...............................................................................................

Now, let's examine the standard options.

All The All option is the Apache server's built−in default. If you have an empty httpd.conf, the Apache server lets almost any Apache function work in the directory. If a user uploads a password−protection script to keep people out of the directory, it will work. If a user uploads a CGI script that exploits a local system flaw to start a root shell on a high−numbered TCP port, giving anyone in the world a backdoor into your system, it will work too. The All option allows every single Apache option except MultiViews (described shortly).

The sample httpd.conf file shipped with Apache specifically sets Options None in the ServerRoot directory, which means that the Apache program's built−in permissive default is turned off by the sample configuration. If you're using the sample httpd.conf as a base (as you should), the All option is explicitly shut off, and you will need to specifically enable options in any directory in which you wish to use them.

ExecCGI CGI scripts that are in a directory with this option set can run.

FollowSymLinks You can use symlinks (or symbolic links, or aliases, as discussed in ln(1)) to point to other files on the server. A user could symlink to just about any file on the server, and that file would be visible (if the file permissions allow it, of course).

Includes Server−side includes (SSI–HTML files that include shell commands) and CGI scripts will work in a directory with this option set, but both can be a security risk unless defensively programmed. After all, you're allowing anyone who can call up your Web site to run the command you use in your HTML page. With a bit of conniving, many intruders can make a command do things the Web designer never intended. (Search the Web on server−side includes and security, and You'll find many different security problems described.) If you don't know how to use SSI safely, don't enable this!

IncludesNOEXEC This allows server−side includes, but disables the #exec SSI feature and the include function of CGI scripts. Without the #exec feature, HTML code cannot run just any command, and SSI commands must be written within a carefully restricted range. Basically, this allows simple server−side includes and CGI scripts, while eliminating the most common security holes. Again, check Google for many different descriptions of the thousands of security issues caused by sloppy server−side includes.

Indexes If a directory doesn't contain an index document (such as Directory Index), the server will return a prettily formatted list of the directory contents. You might consider this a security problem, depending on the contents of your directory. For example, if someone browses the directory of my personal Web page, I don't care, but if they browse a directory that contains private code, I care a great deal.

MultiViews The server can handle documents that are written to be viewed in multiple languages. For example, a Web developer could write a single HTML document that contains text in English, Chinese, and Spanish. With MultiViews enabled, Apache will send the client the page in the language the Web browser uses.

347

None No options are allowed. Every one of the nifty features discussed here will not work.

SymLinksIfOwnerMatch The server will use symlinks if the owner of the symlink is the owner of the file that the symlink points to. This means, in English, that a user can use symlinks to point to her own documents.

AllowOverride If you allow override, users can alter the options permitted in a directory. When you allow override, Apache checks each directory for a file called .htaccess, and processes the contents as additional server configuration info. This allows Web developers to both handle much routine configuration themselves and to install insecure CGI scripts in random locations.

You'll need to decide whether to permit the use of .htaccess overrides. If you're running a corporate Web server, and your Web developer pretty much gets what he wants anyway, there's no reason not to allow whatever override he desires. If, on the other hand, you're running a public or ISP Web server, and you don't allow a certain group of clients to use CGI scripts, you should be sure to disallow certain overrides.

These are the valid AllowOverride statements; all allow the user to override anything with an

.htaccess entry.

∙AuthConfig allows you to password−protect directories. This is a pretty safe option, and it is generally expected on server farms where any idiot with a credit card can get an account.

∙FileInfo allows users to insert their own MIME information for a directory. While it's generally better to add this sort of information to the server's mime.types file, there will be occasions where people need this–for example, when they upload a file that's used only within their company, and they need to tell the browsers what to expect.

∙Indexes allows the user to control how indexing is handled, including setting a new default document, controlling how icons appear in server−generated indexes, and so on.

∙Limit allows the user to use the Allow, Deny, and Order keywords. This option is also quite safe.

∙None means that the user can make no changes. This is a good option to use as a default, but it's a little too restrictive for most applications.

∙Options allows the user to set any of the options described here. This is good if you know and trust the Web developers, or if you don't care if someone uploads an insecure program and the server is compromised.

With the foregoing in mind, a reasonable set of user defaults is

...............................................................................................

AllowOverride Limit, AuthConfig, Indexes, FileInfo

...............................................................................................

Controlling HTTP Requests

An HTTP method is a command sent by a browser to a server. you've probably heard of the HTTP methods GET and POST. These tell the server to transmit a particular page and to process a list of uploaded information, respectively. There's a whole list of methods, however, each with a separate

348

purpose. You can use the Limit directive to restrict the methods your server accepts.

The Limit and LimitExcept directives control which HTTP methods can be used in a directory. In most cases, you won't have to worry about which methods are used within a particular Web page–that'll be the Web developer's problem. You do need to know how to enable and disable them, however. (If you're a Web developer reading this book to learn about how the server works, good for you! Now go look up the various methods in your HTTP book.)

The Limit directive explicitly lists methods that can be used in a directory, along with rules for their usage, in an "allow" and "deny" format. We considered Limit when restricting access to a directory by particular IP addresses, in the previous section, "Httpd.conf Options."

The LimitExcept directive is similar to Limit, except that the rules you create only apply to the unlisted methods. Like the Directory directive, both the Limit and LimitExcept statements use angle brackets (< and >) to show when they begin and end.

For example, to prevent all users from uploading files to your server, you could use the following configuration:

...............................................................................................

<Directory />

<Limit GET POST OPTIONS PROPFIND> Order allow,deny

Allow from all </Limit>

<LimitExcept GET POST OPTIONS PROPFIND> Order deny,allow

Deny from all </LimitExcept>

</Directory>

...............................................................................................

In the first part of this code, beginning with Limit, we use the Limit statement to create a list of specific HTTP methods–GET, POST, OPTIONS, and PROPFIND—that we want to control. The Order and Allow statements, as discussed earlier, let every method in this list go through. We end this section with /Limit.

In the LimitExcept section that follows, we're creating a list of everything not in the Limit list. (This is the same list we saw in the first section.) We don't want to block what we specified in the previous list, but we do want to block what is not in that list. That's why we use LimitExcept. Here, the Order and Deny statements prevent any method not on the list from working.

If you add an HTTP method (say, from an Apache module), the LimitExcept module will automatically include it.

There are quite a few other uses for Limit and LimitExcept, but if you're really interested, You'll want to get one of the many big books on Apache.

Password−Protecting Directories

How about creating a password−protected directory on a Web site? While there's a quick−and−easy way to do this with a plain−text file containing usernames and encrypted passwords, like many other

349

quick−and−easy methods, this one is quite slow. Since we're building high−performance Web servers here, we're not going to do it the easiest way.[1] Instead, we'll look at a way that's very slightly more trouble to deal with but will perform much better.

Much as system usernames and passwords are stored in a database for efficient access, Apache can use a database to store usernames and passwords. You can use the FreeBSD system's user database (/etc/passwd and friends) to authenticate Web users, but this is a bad idea. If you do, you'll allow hackers to break in more easily, you may increase system load, and you can cause all sorts of bad things that you'd go nuts trying to track down. In fact, this is such a massively bad idea

that I'm not going to tell you how to do it. Go hunt down the Apache FAQ if you want to know how to do this.[2]

Directory Setup

To use the Apache database, you'll first need to set up your directory to require a database file. To do so, create a file named .htaccess, in the directory in question, that looks something like this:

...............................................................................................

AuthName "Private Directory" AuthType Basic

AuthDBMUserFile /usr/local/etc/apache/userdb require valid−user

...............................................................................................

AuthName is the text that will appear in the password box, and you can change the text between quotes to anything you want. AuthType tells Apache what sort of authentication to use. For standard usernames and passwords, use an AuthType of "basic."

The AuthDBMUserFile directive tells Apache where the user database is kept. Do not put this file in a directory in the Web site itself, or users could then download it and try to break it–and with enough time, anything breaks. Instead, put it in a location on the server completely outside of the ServerRoot directory. If you have user accounts on the system, and each manages a Web site, put it in the user's home directory.

Web Users Database

Now that you know where you're going to put the database file, You'll use dbmmanage(1) to create it. Dbmmanage takes at least two arguments: the name of the database file and a command to execute on that file.

To create the database, just add a user to it; dbmmanage will notice that the file doesn't exist, and will create it. Specify the username you want to create on the command line, and dbmmanage will prompt you for a password:

...............................................................................................

# dbmmanage /usr/local/etc/apache/userdbm adduser username

...............................................................................................

View, update, and delete are three other useful dbmmanage options. Use view to see all the users in the database, and their encrypted passwords. In the following example, we see the contents of a very small username database, with only one user:

...............................................................................................

350

# dbmmanage /usr/local/etc/apache/userdbm view mwlucas:jvvAuD7bpZwY2

#

...............................................................................................

Use update to change a user's password. To remove a user, use the delete option. (See dbmmanage(1) for a discussion of several other options.)

Once you have a user database and your directory is set up to require passwords, any visitor to that Web directory will be asked for a username and a password to access the site.

Apache and SSL

Many online shopping malls and password−protected areas use what they call "secure Web sites." What they normally mean is that they use SSL to encrypt traffic between the server and the client. While these sites aren't as secure as the name implies, SSL functionality is a vital part of almost any Web server, and Apache has an add−on module to handle SSL connections. To use it, install the apache13−modssl port.

All SSL servers require a certificate. (We discussed generating a public−key certificate request in Chapter 13.) You can either create a legitimate certificate or generate your own test certificate, though if you use a test certificate with an SSL Web server, your clients will get warnings when they attempt to view pages over SSL.

The completed certificate has two parts: a certificate file (server.crt) and a private key (server.key). Place both of these files on the Web server, in a location outside of the ServerRoot, to protect your private key from being downloaded. Then make the private−key file only readable by the Web server with chmod and chown.

...............................................................................................

#chmod 600 server.key

#chown www server.key

...............................................................................................

Now that you have the certificate on the computer, you need to tell Apache about it. Take a look at the httpd.conf file installed by the apache13−ssl port and You'll see that most of it looks exactly like the configuration file installed by the standard Apache port, though You'll see a few additional IfDefined SSL statements to load the SSL modules. Near the bottom of httpd.conf, however, You'll find some entries to define the certificate file and the key file:

...............................................................................................

SSLCertificateFile /usr/local/etc/apache/ssl.crt/server.crt

...............................................................................................

This is the path to your certificate file. It needs to begin with a slash (/); remember, any path in httpd.conf that doesn't begin with a slash is assumed to be under the DocumentRoot! Give the full path to your certificate file here; the default works, but you can change it if you're using virtual hosts.

Similarly, there's an httpd.conf option to tell Apache where your server key lives:

351