This chapter describes how to create and install SSL (Secure Sockets Layer) certificates using the Open SSL implementation and the Apache mod_ssl module on the FreeBSD operating system. (See Chapter 5 for basic information on SSL. See Chapter 6 and Chapter 7 for information about digital certificates.) We will also show you how to get a certificate that is signed by the VeriSign certification authority. The process is decribed in detail to give you a feel for how the mechanics of the process work. However, as it is likely you will be performing this process with different software than described here, refer to your own documentation before beginning the procedure.
To set up a cryptographically enabled web server, you must complete these steps:
Plan your SSL installation. Why do you want to use SSL? What protocols do you want to use with SSL? Which server will you be using? Where will you be keeping your web server’s private key? Do you want it to be possible for people to connect to your server without using SSL? Make sure that you know the answers to these questions before you proceed to avoid any false starts.
Obtain a web server that supports SSL. Most likely, you will either download your web server over the Internet or install it from a CD-ROM.
Install the web server.
Create a private/public key pair for your web server.
Create your own self-signed certificate so you can test your installation and get your secure web server running immediately.
Once your system is up and running, you may wish to get a signed certificate from a third-party certification authority (CA). If so, you must:
Send the public key to the CA.
Send other, supporting documents to the certification authority.
Receive your signed X.509 v3 public certificate from the certification authority.
Install the certificate on your web server.
We’ll describe each of these steps in detail in the following sections.
To deploy SSL within your organization, you will first need to decide what you want to do with the protocol. Some of your choices for SSL include:
Using SSL to encrypt HTTP traffic. By deploying a web server that understands the SSL protocol and changing your http:// URLs to https://, you can get protection from eavesdropping. This is the most common way that SSL is deployed within organizations.
Using SSL to encrypt POP, SMTP, IMAP, and other mail protocols. Many popular email clients (e.g., Microsoft Outlook, Outlook Express, and Netscape Communicator) allow email to be received and sent using SSL encryption. The advantage of SSL is that it prevents an attacker from sniffing your password or eavesdropping on the content of your email.
Using SSL to encrypt LDAP authentication traffic.
Using SSL to encrypt your own proprietary protocols.
A few years ago, obtaining, compiling, and installing an SSL-equipped web server could be quite a challenge. U.S. corporations had the option of purchasing an SSL-enabled web server from Microsoft or Netscape. But for organizations outside the U.S., or for U.S. organizations and individuals that wished to use open source software, patent and export restrictions made simply getting the software a real challenge.
Those days are long over. Both commercial and free SSL implementations are now readily available. Today there are many software packages that support SSL. A sampling of such programs is shown in Table 17-1.
Table 17-1. A few popular servers that support the SSL protocol
Package | Creator | Obtain from |
|---|---|---|
OpenSSL | OpenSSL Development Team | |
Apache mod_ssl (requires OpenSSL) | Apache Software Foundation | |
Microsoft Internet Information Server | Microsoft Corporation | Bundled with Windows NT, 2000, and XP |
Netscape Enterprise and Suitespot | Netscape Communications | |
Covalent SSL (SSL accelerator) | Covalent Technologies, Inc. | |
Apache Stronghold (commercial Apache) | C2Net |
If you are running a web server on Microsoft Windows NT, 2000, or XP, then you have an SSL-enabled web server bundled into your operating system. Furthermore, Microsoft’s CryptoAPI makes SSL/TLS services available to any program that sets a flag when opening or accepting a TCP/IP connection.
If you are using Linux, there’s a good chance that an SSL-enabled web server was bundled along with your operating system; if not, you can download the RPM installation packages from many different locations on the Internet. Versions of the Apache web server with either the Apache-SSL or mod_ssl SSL packages can be downloaded and automatically installed with NetBSD, FreeBSD, and OpenBSD.
SSL derives its security from public key cryptography. To use SSL, you need to have a public/private key pair and a certificate that is signed by an appropriate certification authority. The security of your web server’s SSL communications depends, in part, on the security of your private key. With the private key, any attacker who has access to the data stream can in theory decode the contents of your SSL communications. Thus, it behooves you to make sure that the key is properly protected.
There are three widely accepted practices for maintaining server private keys. In decreasing order of security, they are:
Several corporations have created special-purpose hardware that generates your SSL key pair, securely holds the SSL private key, and performs SSL cryptographic operations at high speed. Using special-purpose hardware, especially hardware that implements the FIPS 140-1 specification, is the most secure way that you can implement SSL within an organization. Even if an attacker breaks into your computer, that attacker will be unable to copy or otherwise compromise your private key.
If you opt for special-purpose hardware, your web server needs to have special drivers to interoperate with the hardware. Each time an SSL request comes in, the web server will hand the encrypted data to the special-purpose hardware to be decrypted. The decrypted data will then be returned to your web server. Special-purpose hardware can also significantly improve the speed of your SSL server.
Keeping your keys encrypted in a file on your web server is a compromise between security and cost. With this configuration, your key is protected with a passphrase. When the web server starts up, a person needs to manually type the passphrase on the computer’s console so that the web server can decrypt the key and start offering encrypted service. Although this approach seems secure, it is actually quite easy to find the decrypted key in the web server’s memory space. A second problem with this approach is that you need to have a person who knows the passphrase present whenever the web server is rebooted.
Keeping keys unencrypted on the web server is the most common way for cryptographically enabled web sites to maintain their private keys. This approach allows you to reboot the web server at will without having to worry about having somebody around who knows the passphrase. On the other hand, if somebody breaks into your web server, they will be able to make a copy of the key for themselves and decrypt any communications between your web server and your users that are intercepted. In practice, this is not a significant risk.
In the early days of e-commerce there was much concern and consternation about the security of web server keys. In practice, much of this concern seems to have been overblown. Most attackers do not try to steal server keys and then use those keys to decrypt intercepted communications. Instead, most attackers simply break into the web server and either compromise its operating system or download information from back-end databases, neatly circumventing the cryptography. This is possible because web server keys are only used to encrypt communications, not stored data.
In practice, the minor security improvement that comes from storing keys encrypted is not worth the increased difficulty of operations. For the overwhelming majority of SSL applications, keeping SSL keys unencrypted on the web server and using traditional host security to protect the web server and the computer’s operating system offers sufficient security.
Although we do not recommend encrypting SSL private keys, we do recommend that certification authority private keys be protected, either through encryption, special hardware, or by having them reside on computers that are not physically connected to the Internet. The reason for this added security is that a compromised CA key can be used to compromise an entire PKI system, rather than simply a single web server.
Every SSL server must have an SSL server certificate. When a browser connects to a web server using the SSL protocol, the server sends the browser its public key in an X.509 v3 certificate. The certificate is used to authenticate the identity of the server and to distribute the server’s public key, which is used to encrypt the initial information that is sent to the server by the client.
Netscape defined the SSL 2.0 certificate format in the document http://home.netscape.com/eng/security/ssl_2.0_certificate.html.
SSL certificates must contain the following fields:
Key length of signature.
Certificate serial number (must be unique within a certification authority).
Distinguished name.
Signature algorithm (specifies which algorithm is used).
Subject common name. This is the DNS name of the server. Netscape Navigator Version 3.0 allows wildcard patterns, such as *.netscape.com to sign all hosts with Netscape’s domain. Specifically, Navigator Version 3.0 allows the following wildcards in the subject.commonName field:
Pattern | Meaning |
|---|---|
| Matches anything |
| Matches one character |
| Escapes a special character (e.g., \ |
| Matches the end of a string |
| Matches |
| Matches the characters |
| Matches any character except |
| This character, followed by another pattern, causes any host whose name matches that following pattern to not match the subject.commonName field |
| Matches |
These pattern-matching operators are similar, but not identical, to the Unix regular expression matching functions. If you decide to use them, you should be careful: some clients do not properly implement these wildcards. Also, some CAs will not sign certificates that contain wildcards; others will sign them only on a case-by-case basis.
The reliance on DNS in the SSL specification is surprising, considering the DNS system itself is not secure, and considering DNS names are frequently different from the name of the organization that is offering web service. Instead of having a web browser attempt to validate that the DNS name in the certificate is the same as the DNS name of the machine it has connected to, web browsers would probably do better by displaying the server’s distinguished name prominently in the browser’s window. For reasons that are unclear, no browser vendor has ever taken this step.
Certificates for certification authorities are nearly identical to the certificates for SSL servers, except that instead of a distinguished name, the certification authority’s name is located in the Common Name field. According to Netscape’s documentation:
The common name will be displayed when the user chooses to view the list of trusted certification authorities in the Security Preferences dialog box (under the Options menu). Examples include Netscape Test CA or Certs-R-Us Level 42 CA. Examples of names that are not recommended are Certification authority and CA Root.