Managing Servers with Netscape Console: Using SSL


Backing Up Your Certificate Information
When the CA sends a response, you should back up all files in this directory: <serverroot>/alias/. This directory includes all the data for your Trust Database. You'll need the data when you install the certificate. You should also save in a text file the certificate data you receive from the CA. If your system ever loses the certificate data, you can reinstall the certificate using your backup file.

Obtaining a Server Certificate Chain
To obtain a Server Certificate Chain:

Go to the CA's website and manually copy the certificate information to your clipboard.

Use the Certificate Setup Wizard to install the certificate. See "Installing the Certificate" on page 76.

When you install a certificate into an existing Server Certificate Chain, the new certificate is not automatically trusted. To trust a new certificate, you must change its trust option. See "Changing the CA Trust Option" on page 82.

Installing the Certificate
To install a certificate:

In Netscape Console, in the navigation tree, select the server you used when you generated the certificate request.

Click Open to open the server.

In Tasks, click Certificate Setup Wizard.

Start the Certificate Setup Wizard, and indicate that you're now ready to install the certificate. When prompted, provide the following information:

Select a token (Cryptographic Device). Choose the same token you used when you generated the certificate request.

Is the server certificate already requested and ready to install?.
Choose Yes.

Certificate for:. Indicate which type of certificate you're installing:

If you're using a single certificate associated only with your server, choose This Server.

If you're using a CA's certificate that includes a certificate chain, choose Server Certificate Chain.

If you're using a certificate that you want to accept as a trusted CA for client authentication, choose Trusted Certificate Authority.

Password:. Enter the password you used when you set up the Trust Database.

Provide the certificate information you received from the CA, then click Next
.

The certificate is located in this file:. Choose this option if you stored the certificate information in a text file. Enter the absolute path to the certificate.

The certificate is located in the following text field:. Choose this option if you copied the certificate information directory from a CA's website to your system clipboard. Click Paste from Clipboard to insert the text in the input area.

Once the certificate is generated and you see this screen, click Add.

Once your certificate is successfully installed, you'll see this screen. Click Done.

Activating SSL

Once you've obtained and installed a certificate, use Netscape Console to activate SSL. The following procedure uses the Administration Server as an example. Other Netscape server interfaces may vary slightly, although the basic concept is the same.

To activate SSL on a 4.x Netscape server:

In Netscape Console, in the navigation tree, select the server you want to use SSL encryption with.

Click Open, then click Configuration.

In the Configuration window, click Encryption.

Enter information as appropriate:

Enable SSL. Choose this option if you want to secure your enterprise with Secure Sockets Layer (SSL) encryption. All other SSL encryption options listed here become available to you only when you enable SSL by checking this box.

Cipher Family. When you enable SSL Encryption, the cipher families available to you are listed here. Netscape currently supports two types of cipher families: RSA and FORTEZZA. The internal token supports only RSA. If you're using a FORTEZZA card, you'll see the FORTEZZA cipher family in this list. Select the cipher families you want to use.

Token to Use. Choose internal (software) if the key is stored in the local key database. All other choices available to you on this list are device-based. This means the key is stored on an external device such as a Smart Card.

Certificate to Use. Use the name of your server's certificate. If you're unsure which Certificate to use, view the Certificate Management dialog box for more information. To view the Certificate Management dialog box, from the Console menu, choose Certificate Management.

Cipher Preferences. A cipher is an encryption algorithm. This list displays the cipher preferences you've enabled.

Click OK or Save, as appropriate.

You won't be able to use Netscape Console to manage the now secured server until the changes saved, and you've restarted the server.Exit Netscape Console, then restart the server at the command line.

With changes in effect, you can start Netscape Console and log in as usual.

Managing Server Certificates

Once you've installed SSL certificates, you need to update information for them periodically. You can view, delete, or edit the trust settings of all the certificates installed on a server. This includes your own certificate and certificates from CAs.

Changing the CA Trust Option
You may need to reject a trusted CA temporarily. For example, you may be notified that a CA is experiencing technical difficulty that prevents certificate authentication. You can change the trust option to Reject until the CA notifies you that the problem has been resolved.

To change the key database trust option:

In Netscape Console, select a server and open it.

From the Console menu, choose Manage Certificate.

Select the certificate you want to update, then click Edit.

In the Certificate dialog box, make changes as necessary:

Detail. Displays detailed information about the selected certificate including serial number, dates the certificate is valid, the Certificate Fingerprint, and whether or not the certificate is currently trusted.

Delete. Deletes the selected certificate.

Trust/Reject. Allows the certificated to be trusted (or rejected).

Click OK.

Changing the Trust Database Password
It's a good practice to change your Trust Database password periodically. If your Administration Server is SSL enabled, your Trust Database password is required when starting the Administration Server. Changing your password periodically adds an extra level of server protection.

To change your Trust Database password:

In Netscape Console, select a server and open it.

From the Console menu, choose Change Key Password.

In the Change Key Password dialog box, enter password information:.

Old password. Enter the password used to install the certificate.

New Password. Enter a new password string.

Confirm. Enter the password again to confirm it.

Click OK.

Managing Certificate Lists
The purpose of certificate revocation lists (CRLs) and compromised key lists (CKLs) is to make known any certificates and keys that either client or server users should no longer trust. If data in a certificate changes (for example, a user changes offices or leaves the organization) before the certificate expires, the certificate is revoked and its data appears in a CRL. If a key is tampered with or otherwise compromised, the key and its data appear in a CKL. Both CRLs and CKLs are produced and periodically updated by a CA.

Obtaining a CRL or CKL
To obtain a CRL or CKL from a Certificate Authority (CA):

Use a browser to go to the CA's website. Contact your CA administrator for the exact URL to use.

Follow the CA's instructions for downloading the CRL or CKL to a local directory.

Once you've saved the CRL file or CKL file to a local directory, you can add information from it to the Trust Database.

Adding a CRL or CKL to the Trust Database
To add CRL or CKL to the trust database:

In Netscape Console, select a server and open it.

From the Console menu, choose Certificate Revocation. All installed CRLs and CKLs are listed along with their expiration dates.

Click Add.

In the Add CRL/CKL dialog box, type the full path name to file, and indicate whether the path leads to a CRL or CKL.

Click OK. If the list already exists in the database, the list you specify here will replace the existing list.

Viewing, Adding, or Deleting CRLs or CKLs
To view, add, or delete CRLs or CKLs:

In Netscape Console, select a server and open it.

From the Console menu, choose Certificate Revocation. All installed CRLs and CKLS are listed along with their expiration dates.

Click a CRL or CKL to select it.

To add CRL or CKL to the trust database, click Add.

To delete CRL or CKL from the trust database, click View. In the Certificate window, click Delete.

Using Client Certificates

Some Netscape Servers use client certificates to ensure authenticity when communicating with a client and to determine if a user has access to the server. Before you can use client certificates for authentication or access control, you must first fulfill these requirements:

The Netscape server must have SSL turned on. See "Activating SSL" on page 80.

The Administration Server must trust the CA who issued the certificate to the client. See "Managing Server Certificates" on page 82.

The certificate must be mapped appropriately to the user directory. See "Editing the certmap.conf file" on page 86.

How Client Certificates Work
When the server gets a request from a client, it asks for the client's certificate before proceeding. A Netscape client, such as Netscape Navigator or Netscape Communicator, sends the client certificate to the server. After checking that a client certificate chains up to a trusted CA, a Netscape server uses the certmap.conf file to look up the user's entry in the directory and check the certificate presented for authentication against the certificate listed in the user's entry. You edit one or more CA mappings in this file to determine how certificates issued by each CA should look up user entries. Specifically, certmap.conf provides three kinds of information for each CA:

It maps the distinguished name (DN) in the certificate to a branch point in the LDAP directory.

It tells the server what values to use from the DN in the certificate (such as the user's name, email address, and so on) for the purpose of searching the directory.

It specifies whether or not the server goes through an additional verification process. If the certmap.conf file is configured to support single sign-on, this process involves matching the certificate presented for authentication with the certificate stored in the user's LDAP directory entry. This step allows you to revoke a certificate by removing it from the user's entry in the directory. This prevents authentication even if the certificate is otherwise valid.

If it finds more than one matching entry, the server can 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 (and thus client authentication) fails.

After the server finds a matching entry and certificate in the LDAP directory, it can use that information to determine the appropriate kind of authorization for the client. For example, some servers use information from a user's entry to determine group membership, which in turn can be used during evaluation of ACLs to determine what resources the user is authorized to access.

Editing the certmap.conf file
The certificate mapping file is located at <server_root>/shared/config/certmap.conf. The file defines

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 or not the server goes through an additional verification process

The certmap.conf file contains one or more named mappings, each applying to a different CA. A mapping has the following syntax:

certmap name issuerDN

name:property [value]

The first line specifies a name for the entry and the DN of the issuer of the client certificate. The name is arbitrary; you can define it to be whatever you want.

Note. The issuerDN must exactly match the issuer DN of the CA that issued the client certificate. For example, the following two issuer DN lines differ only in the number of spaces separating the AVAs, but the server treats these two entries as different:

certmap moz ou=Mozilla Certificate Authority,o=Netscape,c=US

certmap moz ou=Mozilla Certificate Authority, o=Netscape, c=US

The second and subsequent lines in the named mapping match properties with values. The certmap.conf file has six default properties:

DNComps is a list of comma-separated DN attribute tags used to determine where in the LDAP directory the server should start searching for directory entries that match the user's information (that is, the owner of the client certificate). The server gathers values for these tags 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 c DN attribute tags, 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.

If the DNComps entry is present but has no value, the server searches the entire LDAP tree for entries matching the filter.

The following component tags are supported for DNComps: cn, ou, o, c, l, st, e, and mail. Case is ignored. You can use e or mail, but not both.

FilterComps is a list of comma-separated DN attribute tags used to create a filter by gathering information from the user's DN in the client certificate. The server uses the values for these tags to form the search criteria for matching 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 and uid attribute tags (FilterComps=e,uid), the server searches the directory for an entry whose values for e and uid match the user's information gathered from the client certificate. Email 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. The following component tags are supported for FilterComps: cn, ou, o, c, l, st, e, and mail. Case is ignored. You can use e or mail, but not both.

verifycert tells the server whether it should compare the client's certificate with the certificate found in the user's LDAP entry. It takes two values: on and off. Netscape recommends that you set this to on for a complete single sign-on solution. This ensures that the server will not authenticate the client unless the certificate presented exactly matches the certificate stored in the directory. To revoke a user's certificate, you can just remove it from the user's LDAP entry.

CmapLdapAttr is the name of the entry attribute in the LDAP directory that contains subject DNs from all certificates belonging to the user. Because this attribute isn't a standard LDAP attribute, you have to extend the LDAP schema to include it (see the Directory Server Administrator's Guide for details). If the CmapLdapAttr 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 yield any entries, the server retries the search using the DNComps and FilterComps mappings. The search will take place more quickly if CmapLdapAttr is an indexed LDAP attribute.

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

Library is the pathname to a shared library or DLL. You need to use this property only if you want to extend or replace the standard functions that perform the actual mapping on the basis of information in the certmap.conf file. (This is typically not necessary unless you have very specialized mapping requirements.)

InitFn is the name of an init function from a custom library. You need to use this property only if you want to extend or replace the standard functions that perform the actual mapping on the basis of information in the certmap.conf file. (This is typically not necessary unless you have very specialized mapping requirements.)

You can use the client certificate API to create your own properties. For information on programming and using the client certificate API, see your server's documentation or release notes.

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

<name>:library <path_to_shared_library>

<name>:InitFn <name_of_init_function>

For example:

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 mappings
The certmap.conf file should have at least one entry. The following examples illustrate two different ways you can use the certmap.conf file.

Configuration Example #1

Here is a simple certmap.conf file with only one default mapping:

certmap default default

default:DNComps ou, o, c

default:FilterComps e, uid

default:verifycert on

Using this example, the server starts its search at the LDAP branch point containing the entry ou=orgunit, o=org, c=country, where the italics represent values from the subject's DN in the client certificate.

The server then uses the values for email address and user ID from the certificate to search for a match in the LDAP directory before authenticating the user. When it finds an entry, the server verifies the certificate by comparing the one the client sent to the one stored in the directory.

Configuration Example #2

Here is another sample file:

certmap default default

default:DNComps

default:FilterComps e, uid

certmap MyCA ou=MySpecialTrust,o=MyOrg,c=US

MyCA:DNComps ou,o,c

MyCA:FilterComps e

MyCA:verifycert on

This file has two mappings: a default one and another for MyCA. When the server gets a certificate from anyone other than MyCA, the server uses the default mapping, which starts at the top of the LDAP tree and searches for an entry matching the client's email address and user ID. If the certificate is from MyCA, the server starts its search at the LDAP branch containing the organizational unit and searches for matching email addresses. Also note that if the certificate is from MyCA, the server verifies the certificate; other certificates are not verified.

Note. The issuer DN (that is, the CA's information) in the certificate must be identical to the issuer DN listed in the first line of the mapping. Even an extra space after a comma will cause a mismatch.

Configuration Example #3

This example uses the CmapLdapAttr property to search the LDAP database for an attribute called certSubjectDN whose value exactly matches the entire subject DN taken from the client certificate.

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

myco:CmapLdapAttr certSubjectDN

myco:DNComps o, c

myco:FilterComps mail, uid

myco:verifycert on

If the client certificate subject is

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

the server first searches for entries that have

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

If one or more matching entries are found, the server proceeds to verify the entries. If no matching entries are found, the server will use DNComps and FilterComps to search for matching entries. In this example, the server would search for uid=Henry Jones Junior in all entries under

o=Ark Inc, c=US.

Cipher Preferences

To specify which ciphers your server can use, check them in the list.

See Also

"Cipher Suites with RSA Key Exchange"

Ciphers Used with SSL

The SSL protocol supports the use of a variety of different cryptographic algorithms, or ciphers, for use in operations such as authenticating the server and client to each other, transmitting certificates, and establishing session keys. Clients and servers may support different cipher suites, or sets of ciphers, depending on factors such as the version of SSL they support, company policies regarding acceptable encryption strength, and government restrictions on export of SSL-enabled software. Among its other functions, the SSL handshake protocol determines how the server and client negotiate which cipher suites they will use to authenticate each other, to transmit certificates, and to establish session keys.

Key-exchange algorithms like KEA and RSA key exchange govern the way in which the server and client determine the symmetric keys they will both use during an SSL session. The most commonly used SSL cipher suites use RSA key exchange.

Decisions about which cipher suites a particular organization decides to enable depend on tradeoffs between the sensitivity of the data involved, the speed of the cipher, and the applicability of export rules.

To serve the largest possible range of users, it's a good idea for administrators to enable as broad a range of SSL cipher suites as possible. That way, when a domestic client or server is dealing with another domestic server or client, respectively, it will negotiate the use of the strongest ciphers available. And when a domestic client or server is dealing with an international server or client, it will negotiate the use of those ciphers that are permitted under US export regulations.

However, since 40-bit ciphers can be broken relatively quickly, administrators whose user communities can use stronger ciphers without vilating export restrictions should disable the 40-bit ciphers if they are concerned about access to data by eavesdroppers.

Note. Netscape Console does not support all of the cipher suites supported by Netscape clients and servers. To ensure that Netscape Conolse can control an SSL-enabled server, the server must enable at least one of the following cipher suites for SSL 3.0:

RC4 with 128-bit encryption and MD5 message authentication

RC4 with 40-bit encryption and MD5 message authentication

DES, which supports 56-bit encryption, with SHA-1 message authentication

Triple DES, which supports 168-bit encryption, with SHA-1 message authentication

No encryption, MD5 message authentication only

Cipher Suites with RSA Key Exchange
Table 5.1 lists the cipher suites supported by SSL that use the RSA key-exchange algorithm. Unless otherwise indicated, all ciphers listed in the table are supported by both SSL 2.0 and SSL 3.0. Cipher suites are listed from strongest to weakest. Table 5.1 Cipher suites supported by the SSL protocol that use the RSA key-exchange algorithm


Strength category and recommended use	Cipher suites
Strongest cipher suite. Permitted for deployments within the United States only. This cipher suite is appropriate for banks and other institutions that handle highly sensitive data. Netscape Console does not support this cipher suite.	Triple DES, which supports 168-bit encryption, with SHA-1 message authentication. Triple DES is the strongest cipher supported by SSL, 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 * 10⁵⁰. This cipher suite is FIPS-compliant. Both SSL 2.0 and SSL 3.0 support this cipher suite.
Strong cipher suites. Permitted for deployments within the United States only. These cipher suites support encryption that is strong enough for most business or government needs.	RC4 with 128-bit encryption and MD5 message authentication. Because the RC4 and RC2 ciphers have 128-bit encryption, they are the second strongest next to Triple DES (Data Encryption Standard), with 168-bit encryption. RC4 and RC2 128-bit encryption permits approximately 3.4 * 10³⁸ possible keys, making them very difficult to crack. RC4 ciphers are the fastest of the supported ciphers. Both SSL 2.0 and SSL 3.0 support this cipher suite. Netscape Console supports only the SSL 3.0 version of this cipher suite.
	RC2 with 128-bit encryption and MD5 message authentication. Because the RC4 and RC2 ciphers have 128-bit encryption, they are the second strongest next to Triple DES (Data Encryption Standard), with 168-bit encryption. RC4 and RC2 128-bit encryption permits approximately 3.4 * 10³⁸ possible keys, making them very difficult to crack. RC2 ciphers are slower than RC4 ciphers. This cipher suite is supported by SSL 2.0 but not by SSL 3.0. Netscape Console does not support his cipher suite.
	DES, which supports 56-bit encryption, with SHA-1 message authentication. DES is stronger than 40-bit encryption, but not as strong as 128-bit encryption. DES 56-bit encryption permits approximately 7.2 * 10¹⁶ possible keys. This cipher suite is FIPS-compliant. Both SSL 2.0 and SSL 3.0 support this cipher suite, except that SSL 2.0 uses MD5 rather than SHA-1 for message authentication. Netscape Console does not support this cipher suite.
Exportable cipher suites. These cipher suites are not as strong as those listed above, but may be exported to most countries (note that France permits them for SSL but not for S/MIME). They provide the strongest encryption available for exportable products.	RC4 with 40-bit encryption and MD5 message authentication. RC4 40-bit encryption permits approximately 1.1 * 10¹² (a trillion) possible keys. RC4 ciphers are the fastest of the supported ciphers. Both SSL 2.0 and SSL 3.0 support this cipher. Netscape Console supports only the SSL 3.0 version of this cipher suite.
	RC2 with 40-bit encryption and MD5 message authentication. RC2 40-bit encryption permits approximately 1.1 * 10¹² (a trillion) possible keys. RC2 ciphers are slower than the RC4 ciphers. Both SSL 2.0 and SSL 3.0 support this cipher. Netscape Console supports only the SSL 3.0 version of this cipher suite.
Weakest cipher suite. This cipher suite provides authentication and tamper detection but no encryption. Server administrators must be careful about enabling it, however, because data sent using this cipher suite is not encrypted and may be accessed by eavesdroppers.	No encryption, MD5 message authentication only. This cipher suite uses MD5 message authentication to detect tampering. It is typically supported in case a client and server have none of the other ciphers in common. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.

FORTEZZA Cipher Suites
Table 5.2 lists additional cipher suites supported by Netscape products with FORTEZZA for SSL 3.0. FORTEZZA is an encryption system used by US government agencies to manage sensitive but unclassified information. It provides a hardware implementation of two classified ciphers developed by the federal government: FORTEZZA KEA and SKIPJACK. FORTEZZA ciphers for SSL use the Key Exchange Algorithm (KEA) instead of the RSA key-exchange algorithm mentioned in the preceding section, and use FORTEZZA cards and DSA for client authentication. Table 5.2 FORTEZZA cipher suites supported by Netscape products with FORTEZZA for SSL 3.0


Strength category and recommended use	Cipher suites
Strong FORTEZZA cipher suites. Permitted for deployments within the United States only. These cipher suites support encryption that is strong enough for most business or government needs. Netscape Console does not support these cipher suites.	RC4 with 128-bit encryption and SHA-1 message authentication. Like RC4 with 128-bit encryption and MD5 message authentication, this cipher is one of the second strongest ciphers after Triple DES. It permits approximately 3.4 * 10³⁸ possible keys, making it very difficult to crack. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.
	RC4 with SKIPJACK 80-bit encryption and SHA-1 message authentication. The SKIPJACK cipher is a classified symmetric-key cryptographic algorithm implemented in FORTEZZA-compliant hardware. Some SKIPJACK implementations support key escrow using the Law Enforcement Access Field (LEAF). The most recent implementations do not. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.
Weakest FORTEZZA cipher suite. This cipher suite provides authentication and tamper detection but no encryption. Server administrators must be careful about enabling it, however, because data sent using this cipher suite is not encrypted and may be accessed by eavesdroppers. These cipher suites do not support Netscape Console.	No encryption, SHA-1 message authentication only. This cipher uses SHA-1 message authentication to detect tampering. This cipher suite is supported by SSL 3.0 but not by SSL 2.0. Netscape Console does not suppor this cipher suite.