Understanding encryption and SSL

his section describes the major concepts of encrypted communications over both the Internet and an intranet network. You should understand these concepts if you plan on using encryption with your server.

Netscape servers use a communication system called Secure Sockets Layer (SSL) to ensure privacy when communicating with other SSL-enabled products, such as other servers, Netscape® Navigator®, and Netscape Communicator.

Internet security issues

Fortunately there are ways to safeguard privacy over the Internet. You encrypt, or disguise, your information before you send it over the Internet. That way, if someone intercepts it, the data is meaningless. And if the intercepted data is changed, the intended recipient will know it was altered.

Without security precautions, you might encounter three types of problems when you send information over the Internet or an intranet.

• Eavesdropping: Information remains intact, but its privacy is compromised. For example, someone could obtain your credit card numbers, spy on an intimate conversation, or intercept classified information.
  
• Modification: Original information is changed or replaced and then sent to the recipient, who would not know of any changes. For example, someone could alter an order for goods or change a person's resume.
  
• Impersonation: Information passes to a person who poses as the intended recipient. Impersonation can take two forms:
  
  • A person can pretend to be, for instance, jdoe@novell.com, or a computer can identify itself as a site called www.novell.com when it is not. This type of impersonation is known as spoofing.
  • The second type of impersonation is more subtle. For example, suppose the site www.store.com pretends to be a furniture store when it is really just a site that takes orders (and gathers credit card numbers), but never sends any goods.

Taking precautions

• Confidentiality: Ensured through encryption. (See "What is encryption?" for more information on encryption.) If the information is intercepted, it will be unreadable by a third party. The only information that can be discovered is that the two parties are communicating.
  
• Integrity: Ensured through encryption. If someone attempts to alter an encrypted message, it will not decrypt correctly, alerting the recipient to the fact that someone has tampered with the message.
  
• Authentication: Provided through digital authenticity certificates , which are very difficult to falsify. See "Authentication and certificates" for more information.You purchase or otherwise receive a certificate from a third party that both parties trust. Digital certificates help ensure that users or computers are who they say they are. In this way, the certificate acts as a sort of digital identity badge or passport.
  

What is encryption?

The encryption process

Decryption reverses the encryption process, turning the ciphertext back into the original message. Only the recipient can decrypt the text because only the recipient has a key, or the required information to decrypt the ciphertext. Only someone with the correct key can "unlock" a message. To see how encryption is able to resist "brute force" attacks by someone without the key, see "How does encryption work?"

In fact, both the encryption and the decryption processes require keys and sometimes use the same key. Symmetric encryption is like a combination lock protecting a safe--the same combination is used to secure and retrieve something. Netscape servers use symmetric encryption as part of the SSL process, which also includes public-key encryption (see "Public-key encryption").

One problem with symmetric encryption is that anyone who uncovers the key can decrypt your messages, as well as encrypt new messages so they would appear as authentic as yours. This same person could edit or replace messages in transit from you to your intended recipient.

You can avoid this problem by using different keys for encryption and decryption. Then you would have a system like the one described "Public-key encryption."

Public-key encryption

Public-key encryption is one of the processes that Netscape servers use to exchange data. Here's how public-key encryption works with a server:

1. Your server uses two keys: a public key and a private key, which are stored in a single file.
   
2. Your server sends only your public key to any client that requests it, such as Netscape Navigator or Netscape Communicator. The server never sends the private key.
   
3. Any client can use your public key to create ciphertext that can be decrypted only by your server using its private key. Conversely, if your server receives a client's public key, your server can encrypt messages that only that client can decrypt using its private key.
   

As with any encryption process, as long as you actually keep your private key private, your encrypted messages are safe from tampering. Even an eavesdropper who gets both the public key and the ciphertext can't work backwards and discover your private key or your original message. In Netscape servers and clients, you have the additional safeguard of password protection before your private key can be used by the application--with servers you type the password when you start your server, not every time a secure connection is requested by a client.

What keeps public-key encryption secure is that you never share your private key with anyone, so no one can ever decrypt your messages. If anyone gets your private key (that is, they copy the <alias>-key.db file), you must immediately create a new key-pair file. See "Generating a key-pair file" for more information.

How servers use encryption

• A client and server exchange public keys (public-key encryption), and then the client generates a symmetric encryption key that is used only for a single transaction (symmetric encryption). This key is called a session key.
  
• The client encrypts the session key with the server's public key and sends it to the server.
  
• When the server receives the session key, it uses its private key to decrypt it.
  
• For the rest of that transaction, the client and the server can use the quicker symmetric encryption.
  

During an SSL connection, the client and the server agree to use the strongest cipher that they both can communicate with.

Signing files

You can use this "proof of sender" feature of public-key encryption in conjunction with the ability to guarantee message integrity. This is called authentication. You can do this without disguising the contents of a file. This process is called signing a file. When you sign a file, you guarantee message integrity as with normal encryption, but without forcing the recipient to decrypt the message to read it. To the recipient, the signed message appears as a normal unencrypted message with a section of encrypted text after it. Even though the message itself isn't encrypted, you still decrypt the section to make sure that the digital signature matches the message. If the message has been changed after the file was signed, the signature will not decrypt correctly.

When you sign a file with your private key, you are sending out a public message, readable by anyone, that can be proved to be from you because it can only be decrypted with your public key. When the server requests a certificate from a Certificate Authority (CA), it "signs" the request. This way the CA knows that the request for the certificate could only come from the server (See "Choosing Certificate Authorities" for more information about CAs).

How does encryption work?

It might seem odd that you can give an eavesdropper both your public key and a sample of your ciphertext and still be sure that your original message and private key can't be discovered, but it is possible.

The encryption keys discussed in the previous sections are complex mathematical functions that are easy to compute in one direction and extremely difficult to compute in the reverse. It's easy for a computer to figure out the ciphertext when presented with the original message and the encryption key, but very difficult to figure out the original message with only the ciphertext and the encryption key. Because all data stored in computers can ultimately be expressed numerically, you can perform mathematical functions on any information on your computer.

Here's an example of a simple mathematical function:

m+3=c

This is an easy equation to reverse. If you know c (the ciphertext), you can figure out m (the message). In fact, even if you kept this equation (the key) secret, someone could figure it out relatively quickly by examining your ciphertext for patterns.

However, the types of functions used in public-key encryption are vastly more complex. They are also resistant to pattern searches because they use prime numbers in their calculations. A prime number is divisible only by itself and 1. The first ten prime numbers are 2, 3, 5, 7, 11, 13, 17, 19, 23, and 29. The number 6 is not prime because it can also be divided by 2 and 3. There are no patterns for determining prime numbers, so if you use an encryption key that uses prime numbers in the right manner, examining the ciphertext for patterns is not possible. In fact, the SSL protocol uses a number of different types of encryption keys throughout its sequence.

If it is next-to-impossible to determine the original message once it's in ciphertext, how is the private key holder able to uncover it? It's because the private key is also a complex mathematical function, one that is incorporated into the function of the public key as a built-in shortcut to "solving" the public key function (or turning the ciphertext back into the original message). Even if someone gets your public key, it's as difficult to determine what that corresponding private key is as it is to determine the original message from the ciphertext and the public key.

How safe is encryption?

Of course, you could use several computers in conjunction. For example, if you dedicated ten computers to cracking that same encryption, it would take you one-tenth the time. Even then, only the single message in question would be deciphered because SSL generates a new encryption key for every exchange. For more details, see "Putting all the pieces together: SSL."

The precise level of security a key offers is measured by the size of certain numbers used in creating the key. These numbers are measured in bits. The greater the number of bits, the more secure the key. The key used in the previous example is a 128-bit key, which is so strong that the United States government doesn't allow products containing it to be exported. International versions of Netscape products are limited to 56-bit encryption keys. This is still strong enough to stop most hackers. However, it is conceivable that someone could use 100 dedicated computers working together to crack it more quickly. Of course, the cost of making such powerful machines unavailable for other tasks for that amount of time would be very high indeed--probably millions of dollars. Finally, keep in mind that new computing power tends to double every 18 months. The encryption that keeps you safe today may not hold up to cracking 10 years from now.

Note

Authentication and certificates

A CA can be a company that sells certificates over the Internet, or it can be a department responsible for issuing certificates for your company's intranet. You decide which CAs you trust enough to serve as verifiers of other people's identities. See "Choosing Certificate Authorities" for more information on certificates.

Both clients and servers can have certificates. Also clients can have multiple certificates, much like a person might have several different pieces of identification. When a server sends its certificate to a client, the process is called server authentication. When a client sends a certificate to a server, the process is called client authentication. For example, if you participate in newsgroup discussions with a Netscape Collabra Server called news.novell.com, you might find it possesses a certificate issued from a company named CertSafe, assuring you that this site is the one true news.novell.com. If you trust CertSafe's judgment, then you can trust that news.novell.com is the site it claims to be.

Conversely, you might be in charge of a company's internal Human Resources server. You could use your server's access control features in conjunction with client authentication to allow only Human Resources employees access to certain directories. For more information on access control, see Chapter 4, "Controlling access to your server."

When SSL is enabled on a server, server authentication is accomplished with these steps:

1. A client requests a connection with an SSL-enabled server.
   
2. The server signs, but does not encrypt its certificate and sends it to the client.
   
3. The client uses the server's public key, which is included in the certificate file, to verify that the owner of the certificate is the same one who signed it. See "Public-key encryption" and "What's in a certificate?" for more information.
   
4. The client checks whether the certificate's CA is one that it accepts. If so, the client proceeds to the next step; otherwise, the client program informs its user that this certificate was issued by an unknown CA.
   
5. The client compares the information in the certificate with the information it just received about the server. If all the information matches, the client accepts the site as authenticated.
   

Note that the preceding steps are a simplified version of what occurs during server authentication. In addition, there is also the possibility of certificate chaining.

Client authentication is accomplished with these steps:

1. A client (such as Netscape Communicator) requests a connection with the server.
   
2. The server is authenticated or not (through the previous section).
   
3. The client signs, but does not encrypt its certificate and sends it to the server.
   
4. The server uses the client's public key, which is included in the certificate file to verify that the owner of the certificate is the same one who signed it.
   
5. The server attempts to match the CA to a trusted CA. If the client's CA isn't listed as a trusted CA, the server ends the transaction. The server logs an error (with code -8179) and returns this message to the client: the server cannot verify your certificate.
   
6. If the client's CA is trusted, some servers fulfill the transaction. However, some servers attempt to match the information from the certificate with an entry in the LDAP directory. If all the information matches, the server accepts the client as authenticated. If entries in your LDAP directory contains certificates, some servers can compare the sent certificate with the one in the LDAP directory, and if they match, the user can get access.
   

Server and client authentication is not essential to an SSL connection--you can still exchange encrypted information--but it does give extra assurance to both parties that they are sending the encrypted information to the correct parties. Also although a client and server can communicate without authentication, if your server requires client authentication for access control, the client will be rejected if it doesn't have a valid certificate.

Note

Chaining certificates

For example, say your certificate is issued from a certification authority named CertSafe. When you present your certificate, the receiving client doesn't initially accept CertSafe as a trusted CA. However, you also present CertSafe's own certificate, issued from a CA named Global Certificates. The client does accept Global Certificates as a trusted CA. Additionally, the client has been preset to trust any CAs that Global Certificates verifies as CAs. So CertSafe is accepted as a trusted CA. Therefore, your certificate, issued by the now-trusted CertSafe, is accepted for this transaction.

Certificate chaining can be extended beyond your CA and your CA's CA. You could keep any number of certificates. Your server knows to send all of these certificates when your certificate is sent to a client. A client then checks each certificate--working its way up the chain--until it finds one that it trusts.

The administration server contains some default CA certificates. These certificates are self-signed, each one vouches for itself. This is to provide a starting place to a certificate chain for clients that require it.

What's in a certificate?

• holder's name, organization, and address
  
• holder's public key
  
• certificate's validation dates
  
• certificate's serial number.
  

Important

It is important to understand that certificates don't prove conclusively that people or computers are who they claim to be. It merely proves that a CA has some degree of trust in the person. By exchanging information with a certificate holder, you trust the CA who issued the certificate. If you choose to purchase a certificate, buy it from a CA with a good reputation, or your investment might be wasted.

Choosing Certificate Authorities

1. Install a server certificate.
   
2. Under General Administration, Click Keys & Certificates | Manage Certificates.
   
3. Select the alias the server is using for encryption.
   
4. Click OK.
   
5. The administration server lists the certificates you can automatically trust for the alias. You can trust different CAs for different aliases, and any server using the alias inherits the list of trusted CAs.
   

If a server sends Netscape Navigator or Netscape Communicator a certificate that uses an unknown CA, the browser displays a dialog box notifying the recipient that the certificate is from an untrusted CA. Users of Netscape Navigator 2.0 and later or Netscape Communicator can edit their list of trusted CAs. If you are purchasing your certificates from a third party, use a reputable CA.

A server administrator can also edit the list of CAs the server accepts. You can add other CAs when you have decided to trust them. This becomes an increasingly important decision as more and more CAs appear. Just because a CA can purchase a program for issuing certificates doesn't mean you should trust that CA. You can use your server's error log file to view the names of the CAs belonging to people who tried to access your server but couldn't. You can then decide whether you want to add the CA to your list of trusted CAs.

Using client certificates

• The server matches the CA in the client certificate with a trusted CA listed in the administration server. This simply ensures that the client has a valid certificate from a CA the server trusts. If the client is Netscape Navigator or Netscape Communicator and the certificate is expired, the client warns the user before sending the out-of-date certificate. Most Netscape servers will log an error, reject the certificate, and return a message to the client.
  
• The server gathers information from the client certificate and matches it with a user entry in an LDAP directory. This ensures that the client has a certificate and an entry in the LDAP directory. It can also ensure that the client certificate matches the one in the LDAP directory.
  

Note

Mapping client certificates to LDAP

After the server checks that the certificate's CA is trusted, the server goes through three steps to map the certificate to an LDAP entry:

1. It maps the subject (user's) Distinguished Name (DN) to a branch point in the LDAP directory. See "Distinguished names" for more information about DNs.
   
2. It searches the LDAP directory for entries that match the information about the subject (end user) of the client certificate.
   
3. It optionally verifies the client certificate with one in the LDAP directory.
   

The server uses a certificate mapping file called certmap.conf to determine how to do the LDAP search. The mapping file tells the server what values to take from the client certificate, such as the end user's name, e-mail address, and so on. The server uses these values to search for a user entry in the LDAP directory, but first the server needs to determine where in the LDAP directory it needs to start its search. The certificate mapping file also tells the server where to start.

Once the server knows where to start its search and what it needs to search for (step 1), it performs the search in the LDAP directory (step 2). If it finds more than one matching entry and the mapping is not set to verify the certificate, the search fails. Some servers end the transaction at this point.

When the server finds multiple matching entries in the directory, the server can optionally verify the client's certificate by comparing it with certificates for the matching entries in the LDAP directory. If the client certificate doesn't match any certificates in the matching entries or if the matching entries don't contain certificates, the certificate mapping fails. At this point, some servers end the transaction with the client; others perform an action based on the failed match. If none of the LDAP entries contain a certificate, the server also ends the transaction.

After the server finds a matching entry and certificate in the LDAP directory, it can use that information to process the transaction. For example, some servers use certificate-to-LDAP mapping to determine access to a server.

The following section describes the certmap.conf file. You need to edit this file to fit the entries in your LDAP directory and to match the certificates you expect your users to have.

Using the certmap.conf file

• where in the LDAP tree the server should begin its search
  
• what certificate attributes the server should use as search criteria when searching for the entry in the LDAP directory
  
• whether the server goes through an additional verification process.
  

certmap <name> <issuerDN>

<name>:<property> [<value>]

certmap moz1 ou=novonyx Certificate Authority,o=Netscape,c=US

certmap moz2 ou=novonyx Certificate Authority, o=Netscape, c=US

• DNComps: A list of comma-separated attributes used to determine where in the LDAP directory the server should start searching for entries that match the user's information (the owner of the client certificate). The server gathers values for these attributes from the client certificate and uses the values to form an LDAP DN, which then determines where the server starts its search in the LDAP directory. For example, if you set DNComps to use the o and u attributes of the DN, the server starts the search from the o=<org>, c=<country> entry in the LDAP directory, where <org> and <country> are replaced with values from the DN in the certificate.
  
  • If there isn't a DNComps entry in the mapping, the server uses either the CmapLdapAttr setting or the entire subject DN in the client certificate (the end user's information).
  • If the DNComps entry is present, but has no value, the server searches the entire LDAP tree for entries matching the filter.
• FilterComps: A list of comma-separated attributes used to create a filter by gathering information from the user's DN in the client certificate. The server uses the values for these attributes to form the search criteria used to match entries in the LDAP directory. If the server finds one or more entries in the LDAP directory that match the user's information gathered from the certificate, the search is successful and the server optionally performs a verification.
  For example, if FilterComps is set to use the e-mail and user ID attributes (FilterComps=e,uid), the server searches the directory for an entry whose values for e-mail and uid match the end user's information gathered from the client certificate. E-mail addresses and user IDs are good filters because they are usually unique entries in the directory. The filter needs to be specific enough to match one and only one entry in the LDAP database.

• verifycert: A notification that tells the server whether it should compare the client's certificate with the certificate found in the LDAP directory. It takes two values, on and off. You should only use this property if your LDAP directory contains certificates. This feature is useful to ensure your end users have a valid, unrevoked certificate.
  
• CmapLdapAttr: A name for the attribute in the LDAP directory that contains subject DNs from all certificates belonging to the user. This attribute isn't a standard LDAP attribute, so to use this property, you have to extend the LDAP schema. For more information on configuring LDAP, see "Using Netscape Directory Server LDAP."
  If this property exists in the certmap.conf file, the server searches the entire LDAP directory for an entry whose attribute (named with this property) matches the subject's full DN (taken from the certificate). If the search doesn't find any entries, the server retries the search using the DNComps and FilterComps mappings.

  This approach to matching a certificate to an LDAP entry is useful when it's difficult to match entries using DNComps and FilterComps.

• Library: A property whose value is a pathname to a shared library or DLL. You only need to use this property if you create your own properties using the certificate API. For more information on this API, see the release notes for your product.
  
• InitFn: A property whose value is the name of an init function from a custom library. You only need to use this property if you create your own properties using the certificate API.
  

Creating custom properties

Once you have a custom mapping, you reference the mapping as follows:

<name>:library <path_to_shared_library> 

<name>:InitFn <name_of_init_function> 

certmap default1 o=Netscape Communications, c=US 

default1:library /usr/netscape/suitespot/userdb/plugin.so 

default1:InitFn plugin_init_fn 

default1:DNComps  ou o c 

default1:FilterComps l 

default1:verifycert on

Example #1

certmap default default

default:DNComps ou, o, c

default:FilterComps e, uid

default:verifycert on

The server then uses the values for e-mail address and user ID from the certificate to search for a match in the LDAP directory. When it finds an entry, the server will verify the certificate by comparing the one the client sent to the one stored in the directory.

Example #2

certmap default default

default:DNComps

default:FilterComps e, uid

certmap usps ou=United States Postal Service, o=usps, c=US

usps:DNComps ou,o,c

usps:FilterComps e

usps:verifycert on

Caution

Example #3

certmap myco ou=My Company Inc, o=myco, c=US

myco:CmapLdapAttr certSubjectDN

myco:DNComps  o, c  

myco:FilterComps mail, uid 

myco:verifycert on

uid=Henry Jones Junior, o=Ark Inc, c=US

certSubjectDN=uid=Henry Jones Junior, o=Ark Inc, c=US

Note

Putting all the pieces together: SSL

Essentially, SSL is symmetric encryption nested within public-key encryption, authenticated through the use of certificates. An SSL connection can occur only between an SSL-enabled client and an SSL-enabled server. In fact, when a server is running in SSL mode, it can communicate only through SSL.

Technically speaking, SSL is a protocol that runs above TCP/IP and below HTTP, NNTP, or other top-level protocols, as shown in Figure 5.2.

Note

How SSL relates to TCP/IP and application protocols

An SSL connection is initiated by a network browser when it prompts a server to send a document through HTTPS, LDAPS, SNEWS, or other secure protocol.

Here are the general steps of SSL-encrypted communication:

1. The client sends a request to connect to the secure server.
   
2. The server sends its presigned certificate to the client. This, and the first step, are collectively known as the handshake.
   
3. The client checks whether the certificate was issued by a CA it trusts. If so, it proceeds to the next step. Otherwise, the client can cancel the connection or proceed. Netscape Navigator and Netscape Communicator display a warning message saying the certificate isn't trusted and then prompts the user if they want to proceed or not.
   
4. The client compares the information in the certificate with the information it just received concerning the site: its domain name and its public key. If the information matches, the client accepts the site as authenticated.
   
5. The client tells the server what ciphers, or types of encryption keys, it can communicate with.
   
6. The server chooses the strongest common cipher and informs the client.
   
7. Using that cipher, the client generates a session key (a symmetric encryption key used with one transaction) and encrypts it using the server's public key.
   
8. The client encrypts the session key using the server's public key, then it sends the encrypted session key to the server.
   
9. The server receives the encrypted session key and decrypts it using its private key.
   
10. The client and the server use the session key to encrypt and decrypt the data they send to each other.
    

Increasing server security

So in addition to enabling SSL on your server, you should take extra security precautions. For example, put the server machine into a secure room that has a lock, and don't allow untrusted individuals to upload programs to your server.

When considering how much extra security to implement, keep in mind that the strongest encryption in the world does you no good if someone can get to your data some other way. The following sections describe the most important things you can do to make your server more secure.

Limit physical access

Also protect your machine's administrative (root) password, if you have one.

Limit administration access

You should also turn on encryption for the administration server. If you don't use an SSL connection for administration, then you should be cautious when performing remote server administration over an unsecure network. Anyone could intercept your administrative password and reconfigure your servers.

Choose good passwords

• Your administrative password is the most important password of all because anyone with that password can configure any and all servers on your computer.
  
• Most important after that is your private key password. If someone gets your private key and your private key password, they can create a fake server that appears to be yours or intercept and change communications to and from your server.
  

A good password is one you'll remember, but others won't guess. For example, you could remember MBi12!mo as "My Baby is 12 months old!" A bad password is your child's name or birthdate.

It's not a good idea to write your passwords anywhere, but if you feel you must, store them in a safe place, perhaps in a safe or other locked box.

Secure your key-pair file

Limit other applications on the server

Limit ports

Know your server's limits

Being aware of these limitations helps you know what situations to avoid. For example, you might acquire credit card numbers over an SSL connection, but are those numbers stored in a secure file on the server machine? What happens to those numbers after the SSL connection is terminated? You should be responsible for securing any information clients send to you through SSL.

Enabling SSL encryption

1. Generate your server's key-pair file (public and private keys). See "Generating a key-pair file" for instructions.
   
2. Request a certificate from a Certification Authority (CA). See "Requesting a certificate" for instructions.
   
3. Install the certificate the CA sends to you. See "Installing the certificate" for instructions.
   
4. Turn on SSL encryption for your server. See "Activating SSL encryption" for instructions.
   

What is an alias?

You specify an alias when you generate the key-pair file. The key-pair file is then used when requesting a certificate. Both the key-pair file and the certificate file use the alias as part of their filename. For example, if you generate a key with an alias named mail, the key-pair and certificate files will be named mail-key.db and mail-cert.db.

Creating an alias

To create an alias for an existing key-pair file and certificate file, perform the following:

1. Under General Administartion, click Keys & Certificates | Create Alias.
   
2. In the Alias field, type an alias name. This name becomes part of the new file names for the key-pair and certificate files. For example, if you generate a key with an alias named mail, the key-pair and certificate files will be named mail-key.db and mail-cert.db.
   
3. In the Key Pair File field, type the absolute paths and filenames to the key-pair file.
   
4. In the Certificate File field, type the absolute paths and filenames to the certificate file.
   
5. Click OK.
   

You can use these steps to create an alias for an existing key-pair file only. You can then install the certificate at a later time. To do this, omit the certificate file information in the form.

Removing an alias

To remove an alias, perform the following:

1. Under General Administration, click Keys & Certificates | Remove Alias.
   
2. In the Alias drop-down list, select the alias you want to remove.
   
3. Select Yes to remove the alias.
   
4. Click OK to remove the alias and delete the key-pair and certificate files from your hard disk. You'll get a prompt asking you to confirm the deletion. Click OK. This procedure cannot be undone!
   

Listing aliases

1. Under General Administration, click Keys & Certificates | List Aliases. The List Aliases form shows all aliases and the key-pair and certificate files associated with the alias. All aliases and their key-pair and certificate files are stored in the directory <server_root>/alias.
   
2. Click Refresh to read the entries in this directory; you can use this button if you've made changes to your aliases and you want to view the most up-to-date information stored on your disk. You only need to use this button if your browser has cached copy of the form data and you recently made changes to the information.
   

Generating a key-pair file

See "Generating a key-pair file on Windows NT platforms" if you have NT as a client and wish to generate the key-pair file from the client. Note that the key-pair file should be generated from the NetWare console in most cases as the private key should never leave the server for security reasons.

Generating a key-pair file on NetWare platforms

1. Run the key-pair file generation program by typing load <server_root>/bin/admin/admin/bin/sec-key at the NetWare server console.
   
2. When prompted, type an alias for the new key-pair file. You might choose an alias that matches your server, for example, web or mail. The alias cannot contain spaces, but it can use symbols that your operating system allows in filenames, such as underscores. Also, the alias name cannot exceed seven characters in length.
   By default, the key-pair file is stored in <server_root>/alias/<alias>- key.db, where <alias> is the alias you typed. If you used the alias mail, your key-pair file would be <server_root>/alias/mail-key.db.

3. Type any random keys at different speeds until the progress meter is full. The time between each of your keystrokes will be used to generate a random number for the unique key-pair file. Continue typing until a message appears.
   
4. When prompted, type a password of eight characters or more for your key-pair file. The password must have at least one nonalphabetical character (a number or punctuation mark). Make sure you memorize this password. The security of your server is only as good as the security of the key-pair file and its password. After you enable SSL for a server (either the administration server or another Netscape server), you must type the key-pair file password when you start the server.
   
5. Retype the password and click OK. The file is created and stored.
   
6. Return to General Administration | Keys & Certificates | Request Certificate. After you receive and install the certificate, you can turn on encryption.
   

Generating a key-pair file on Windows NT platforms

1. Go to the <mapped drive>:\novonyx\suitespot directory.
   
2. Run the sec-key.exe application by typing bin\admin\admin\bin\sec-key. The key-pair file generation program appears.
   
3. When prompted, type an alias for the new key-pair file. You might choose an alias that matches your server, for example, web or mail. The alias cannot contain spaces, but it can use symbols that your operating system allows in filenames, such as hyphens and underscores. By default, the key-pair file is stored in the directory <server>/sys:/<server_root>/alias/<alias>-key.db, where <alias> is the alias you typed. If you used the alias mail, your key-pair file would be <server>/sys:/<server_root>/alias/mail-key.db.
   
4. A screen with a progress meter appears. Move your mouse in random motions at random speeds. These random movements are used to generate a random number for the unique key-pair file.
   
5. When prompted, type a password of eight characters or more for your key-pair file. The password must have at least one nonalphabetical character (a number or punctuation mark). Make sure you memorize this password. The security of your server is only as good as the security of the key-pair file and its password.
   

After you turn on SSL for a server (either the administration server or another Netscape server), you must type the key-pair file password when you start the server.

1. Retype the password and click OK. The file is created and stored.
   
2. Return to General Administration | Keys & Certificates | Request Certificate. After you receive and install the certificate, you can turn on encryption.
   

Changing your key-pair file password

Don't change your key-pair file password if you are administering your server over a non-SSL connection. Anyone can intercept the information and activate or disable your SSL. See "Activating SSL encryption" for more information.

To change your key-pair file password, perform the following:

1. Under General Administration, click Keys & Certificates | Change Key Password.
   
2. From the Alias drop-down list, select the alias for the key-pair file.
   
3. In the Old Password field, type the old password.
   
4. In the New Password field, type the new password.
   
5. In the Password (Again) field, retype the new password.
   
6. Click OK.
   

Requesting a certificate

If your company has its own internal CA for issuing certificates, you should request your certificate from them. If you plan to purchase your certificate from a commercial CA, choose a CA and ask for the specific format of the information they require. For more information on what some CAs require, see Information CAs need.

Not everyone who requests a certificate from a commercial CA is given one. Many CAs require you to prove your identity before issuing you a certificate. Also it can take anywhere from one day to two or more months to approve a certificate. You are responsible for promptly providing all the necessary information to the CA.

To request a certificate, make sure you know what information your CA requires and perform the following:

1. Under General Administration, click Keys & Certificates | Request Certificate.
   
2. Select new certificate or certificate renewal. Many certificates expire after a set period of time, such as six months or a year. Some CAs will automatically send you a renewal.
   
3. In the Submit to Certificate Authority via list, select how you want to submit the request for the certificate.
   
   • If the CA expects to receive the request in an e-mail message, select CA E-mail and type the e-mail address of the CA in the appropriate field.
   • If you are requesting the certificate from an internal CA that is using Netscape Certificate Server, select CA URL and type the URL for the Certificate Server in the appropriate field. This URL should point to the certificate server's program that handles certificate requests. A sample URL might be https://CA.mozilla.com:444/cms.
4. From the Alias drop-down list, select the alias for the key-pair file you want to use when requesting the certificate.
   
5. In the Key Pair File Password field, type the password for your key-pair file. The server uses the password to get your private key and encrypt a message to the CA. The server then sends both your public key and the encrypted message to the CA. The CA uses the public key to decrypt your message.
   
6. Type your identification information in the fields below the boxed paragraph. The format of this information varies by CA. For a general description of these fields, see Information CAs need. Most of this information usually isn't required for a renewal.
   
7. Double-check your work to ensure accuracy. The more accurate the information, the faster your certificate is likely to be approved.
   
8. Click OK. If your request is going to a certificate server, you'll be prompted to verify the form information before the request is submitted. You should re-read the information and then click OK to submit the request to the certificate server.
   

The server generates a certificate request that contains your information. The request has a digital signature created with your private key. The CA uses a digital signature to verify that the request wasn't tampered with during routing from your server machine to the CA. In the rare event that the request is tampered with, the CA will usually contact you by phone.

If you chose to e-mail the request, the server composes an e-mail message containing the request and sends the message to the CA. Typically, the certificate is sent to you via e-mail. If instead you specified a URL to a certificate server, your server uses the URL to submit the request to the Certificate Server. You might get a response via e-mail or other means depending on the CA.

If the CA agrees to issue you a certificate, the CA will notify you. In most cases, the CA will send your certificate via e-mail. If your organization is using a certificate server, you may be able to search for the certificate by using the certificate server's forms.

Once you receive the certificate, you can install it. In the meantime, you can still use your server without SSL.

Information CAs need

• Common Name: Usually the fully qualified hostname used in DNS lookups, for example, www.netscape.com. This is the hostname in the URL that a browser uses to connect to your site. It's important that these two names are the same, otherwise a client is notified that the certificate name doesn't match the site name, which will make people doubt the authenticity of your certificate. However, some CAs might require different information, so it's important to contact them.
  
• E-mail Address: Your business e-mail address. This is used for correspondence between you and the CA.
  
• Organization: The official, legal name of your company, educational institution, partnership, and so on. Most CAs require that you verify this information with legal documents, such as a copy of a business license.
  
• Organizational Unit is an optional field that describes an organization within your company. This can also be used to note a less formal company name (without the Inc., Corp., and so on).
  
• Locality: An optional field that usually describes the city, principality, or country for the organization.
  
• State or Province: Usually required, but can be optional for some CAs. Most CAs won't accept abbreviations, but you should check with them to be sure.
  
• Country: A required, two-character abbreviation of your country name in ISO format. The country code for the United States is US. In the certificate file, all the fields together are called the distinguished name. The distinguished name in a certificate aids programs in uniquely identifying certificates.
  

Some commercial CAs offer certificates that indicate a greater level of detail and veracity to vendors or individuals who provide greater proof of their identity. For example, you might be able to purchase a certificate stating that the CA has not only verified that you are the rightful administrator of the www.mozilla.com computer, but that you really are a company that has been in business for ten years and have no outstanding customer litigation against you. Generally, these certificates cost more than standard ones.

Installing the certificate

There are two types of certificates that you can install:

• your own certificate to present to clients
  
• a CA's own certificate for use in a certificate chain.
  

When you receive a certificate from the CA, it will be encrypted with your public key so that only you can decrypt it. The server will use the key-pair file password you specify to decrypt the certificate when you install it. You can either save the e-mail somewhere accessible to the server, or copy the text of the e-mail and be ready to paste the text into the Install Certificate form, as described here.

CAs' certificates for use in a certificate chain are installed using the same process as installing your own certificate. If your CA doesn't automatically send you their certificate,you should request it. However, many CAs include their certificate in the same e-mail that contains your certificate. In this case, your server installs both certificates at the same time when you install your certificate. For more information on certificate chaining, see Chaining certificates.

To install a certificate and associate it with an alias, perform the following:

1. Under General Administration, click Keys & Certificates | Install Certificate.
   
2. Select the type of certificate you are installing:
   
   • This Server: A single certificate associated only with your server.
   • Server Certificate Chain: A CA's certificate to include in a certificate chain.
   • Trusted Certificate Authority (CA): A certificate of a CA that you want to accept as a trusted CA for client authentication.
3. If the certificate is for a chain, in the Certificate Name field, type the certificate name. This name will appear in the Manage Certificates list. The name should be descriptive and can include spaces. For example, "United States Postal Service CA" is the name of the CA and "VeriSign Class 2 Primary CA" describes both the CA and the type of certificate. If the certificate is for "this server," the administration server uses the name Server-Cert.
   
4. Select Message is in this field or Message text (with headers).
   
5. For Message is in this field, type the full pathname to the saved e-mail.
   
6. For Message text (with headers) field, type the full pathname to the saved e-mail in the field. If you copy and paste the text, be sure to include the headers "Begin Certificate" and "End Certificate."
   
7. From the Alias drop-down list, select the alias you used when you requested the certificate. If you choose the incorrect alias, the certificate won't install.
   
8. Click OK. Another form appears, asking if you want to add the certificate. Click Add. The certificate is stored in the directory <server_root>/alias. The filename will be <alias>-cert.db. For example, if your alias is mail, the file will be mail-cert.db.
   

If you have just installed your own certificate, you can now activate SSL for your server.

Managing server certificates

To manage this list of certificates, perform the following:

1. Under General Administration, click Keys & Certificates | Manage Certificates.
   
2. From the Alias drop-down list, select a certificate file alias.
   
3. Click OK. All of the installed certificates associated with the alias appear with their type and expiration date. The link text is the name given to the certificate when it was installed. The administration server comes with several default certificates, which are listed above the certificates you installed. All certificates are stored in the directory <server_root>/alias.
   
4. To view more information about a certificate, click the link for the certificate. A window appears, containing information about that certificate. Figure 5.3 shows a sample. Certificate information includes the owner and who issued it.
   

To accept the certificate, perform the following:

1. To trust the CA, click Trust. If the CA is already trusted, you can click Do Not Trust. By default, all CAs are not trusted.
   
2. To delete the certificate, click Delete Certificate.
   
3. To close the window, click Quit.
   

Activating SSL encryption

1. Click Server Manager | Server Preferences | Encryption On/Off.
   
2. Select On.
   
3. In the Port Number field, type the portnumber.
   
4. In the Alias drop-down list, choose the alias for the key-pair file and certificate file you want to use. You must know the password for the key-pair file referenced by this alias--it's the password you must enter before starting or stopping a server that uses SSL encryption.
   
5. Set any security preferences you want.
   
6. Click OK.
   
7. Click Save and Apply.
   
8. Stop your server and then start it from the command line or NT control panel. You'll be prompted to enter the password for the key-pair alias you used.
   

URLs to an SSL-enabled administration server are constructed using https instead of simply http. URLs that point to documents on an SSL-enabled server have this format: https://<servername.[domain.[dom]]:[port#]>

An example is https://admin.mozilla.com:443. If you use the default secure http portnumber (443), you don't have to use the portnumber in the URL.

Setting security (SSL) preferences

To set preferences for using SSL encryption on the administration server, complete the following.

1. Click Server Manager | Server Preferences | Encryption Preferences.
   
2. Select the SSL versions you want your server to communicate with. The latest and most secure version is SSL version 3, but many older clients use only SSL version 2. You will probably want to enable your server to use both versions.
   
3. Select Yes or No to require client certificates.
   
4. Check the ciphers you want your server to use. The ciphers are listed for each version of SSL. A cipher is the algorithm used in encryption. Some ciphers are more secure, or stronger, than others. Generally speaking, the more bits a cipher uses during encryption, the harder it is to decrypt the data. Ciphers are described after this list.
   
5. Click OK.
   
6. Click Save and Apply.
   
7. Restart your server to apply your changes.
   

When a navigator initiates an SSL connection with a server, it notifies the server what ciphers it prefers to use to encrypt information. In any two-way encryption process, both parties must use the same ciphers. Because there are a number of ciphers available, you should consider enabling all ciphers.

You can choose ciphers from both the SSL 2 and SSL 3 protocols. Unless you have a compelling reason why you don't want to use a specific cipher, you should check them all.

You might not want to check No Encryption, only MD5 message authentication, because if no other ciphers are available in the navigator, the server will use this protocol, and no encryption will occur. By checking this option, you allow your server to communicate without SSL encryption.

Another reason you might not want to enable all ciphers is to prevent SSL connections with less than optimal encryption. United States law prohibits the export of products with more than 40-bit encryption, so some clients might only be using 40-bit encryption, which is not as difficult to decipher as 128-bit. Unchecking all 40-bit ciphers effectively restricts access to network browsers available only in the United States. All ciphers that the administration server supports are listed here for your reference.

The SSL 2.0 ciphers are

• RC4 cipher with 128-bit encryption and MD5 message authentication. RC4 ciphers are the fastest ciphers. This cipher, because it has 128-bit encryption, is the second strongest cipher next to Triple DES (Data Encryption Standard) with 168-bit encryption. It has approximately 3.4 * 1038 possible keys, making it very difficult to crack. As added security, all SSL 2.0 ciphers use MD5 (Message Digest 5) message authentication. MD5 message authentication detects attempts to modify data while it is in transit.
  
• RC4 cipher with 40-bit encryption and MD5 message authentication. This cipher is also an RC4 cipher, making it one of the fastest available ciphers, and it is the strongest encryption that Netscape Communications is permitted to export under U.S. law. It has 40-bit encryption. 40-bit encryption has approximately 1.1 * 1012 (a trillion) possible keys, making it easier to crack than 128-bit encryption. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.
  
• RC2 cipher with 128-bit encryption and MD5 message authentication. The RC2 ciphers are slower than the RC4 ciphers. This RC2 cipher, because it has 128-bit encryption, is the second strongest cipher next to Triple DES with 168-bit. It has approximately 3.4 * 1038 possible keys, making it very difficult to crack. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.
  
• RC2 cipher with 40-bit encryption and MD5 message authentication. This cipher is also an RC2 cipher, making it is slower than the RC4 cipher. 40-bit encryption is not as strong as 128-bit encryption, and has approximately 1.1 * 1012 (a trillion) possible keys. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.
  
• DES with 56-bit encryption and MD5 message authentication. DES (Data Encryption Standard) is a U.S. government standard for data encryption. This cipher does not have as many possible keys as does 128-bit encryption, and therefore is not as strong. 56-bit encryption has approximately 7.2 * 1016 possible keys. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.
  
• Triple DES with 168-bit encryption and MD5 message authentication. Triple DES is the strongest cipher available, but it is not as fast as RC4. Triple DES uses a key three times as long as the key for standard DES. Because the key size is so large, there are more possible keys than for any other cipher approximately 3.7 * 1050. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.
  

The SSL 3.0 ciphers are

• RC4 with 128-bit encryption and MD5 message authentication. This cipher is the same as the SSL 2.0 version of RC4 with 128-bit encryption but uses a more secure implementation of MD5 message authentication to detect attempts to modify data in transit.
  
• RC4 with 40-bit encryption and MD5 message authentication. This cipher is the same as the SSL 2.0 version of RC4 with 40-bit encryption but uses a more secure implementation of MD5 message authentication to detect attempts to modify data in transit. It is the strongest encryption that Netscape Communications is permitted to export under U.S. law.
  
• Triple DES with 168-bit encryption and SHA message authentication. This cipher is the same as the SSL 2.0 version of Triple DES with 168-bit encryption, but uses SHA (Secure Hash Algorithm) message authentication instead of MD5 message authentication. SHA is a government-standardized algorithm that is used to construct a message authentication code that detects attempts to modify data while it is in transit. SHA is slower than MD5, but it is stronger.
  
• DES with 56-bit encryption and SHA message authentication. This cipher is the same as the SSL 2.0 version of DES with 56-bit encryption but uses SHA message authentication instead of MD5 message authentication. It has 40-bit encryption, which is the strongest encryption that Netscape Communications is permitted to export under U.S. law.
  
• RC2 with 40-bit encryption and MD5 message authentication. This cipher is the same as the SSL 2.0 version of RC2 with 40-bit encryption but uses a more secure implementation of MD5 message authentication to detect attempts to modify data in transit. It is the strongest encryption that NetscapeCommunications is permitted to export under U.S. law.
  
• No encryption, only MD5 message authentication. This cipher uses only MD5 message authentication to secure data. Any data sent using this cipher is not encrypted. The data may be protected from modification, but it can be viewed by eavesdroppers.
  

Changes to the ns-admin.conf file

With an SSL-enabled server installed, there are several changes to the file <server_root>/admin-serv/config/ns-admin.conf (the administration server's configuration file). These new directives are briefly described in the following sections.

Security

Syntax

Security [on|off]

value is on when SSL is enabled, or off when disabled.

SSL2

The SSL2 directive tells the server that SSL2 is enabled or disabled.

Syntax

SSL2 [on|off]

value is on when SSL2 is enabled, or off when disabled.

SSL3

The SSL3 directive tells the server that SSL3 is enabled or disabled.

Syntax

SSL3 [on|off]

on when SSL3 is enabled, or off when disabled.

Keyfile

The Keyfile directive tells the server where the key file is located.

Syntax

Keyfile <alias>-key.db

<alias>-key.db is the server's key-pair file, specified as an absolute path.

Certfile

The Certfile directive specifies where the certificate file is located.

Syntax

Certfile <alias>-cert.db

<alias>-cert.db is the server's certificate file, specified as an absolute path.

Ciphers

The Ciphers directive specifies the ciphers enabled for your server. For a discussion of these ciphers, refer to Setting security (SSL) preferences.

Syntax

Ciphers +rc4 +rc4export -rc2 -rc2export +idea +des +desede3

A + means the cipher is active, and a - means the cipher is inactive. Any cipher with export as part of its name is not stronger than 40 bits.

SSL3Ciphers

The SSL3Ciphers directive specifies the SSL 3 ciphers enabled for your server.

Syntax

SSL3Ciphers +rsa_rc4_128_md5 +rsa_3des_sha +rsa_des_sha +rsa_rc4_40_md5

+rsa_rc2_40_md5 -rsa_null_md5

A + means the cipher is active, and a - means the cipher is inactive. Any cipher with 40 as part of its name is 40 bits.