Netscape Enterprise Server Administrator's Guide: Chapter 5Securing Your Enterprise Server

Administrator's Guide
Netscape Enterprise Server

Chapter 5 Securing Your Enterprise Server

This chapter describes how to activate the various security features designed to safeguard your data, deny intruders access, and allow access to those you want. Netscape Enterprise Server 6.1 incorporates the security architecture of all Netscape servers: it's built on industry standards and public protocols for maximum interoperability and consistency.

Before reading this chapter you should be familiar with the basic concepts of public-key cryptography. These concepts include encryption and decryption; public and private keys; digital certificates; and the encryption protocols.

The process of securing your web server will be explained in detail in the following sections:

Requiring Authentication

Creating a Trust Database

Requesting and Installing a VeriSign Certificate

Requesting and Installing Other Server Certificates

Migrating Certificates When You Upgrade

Managing Certificates

Installing and Managing CRLs and CKLs

Configuring Remote CRLs

Setting Security Preferences

Using External Encryption Modules

Setting Client Security Requirements

Setting Stronger Ciphers

Considering Additional Security Issues

Requiring Authentication

Authentication is the process of confirming an identity. In the context of network interactions, authentication is the confident identification of one party by another party. Certificates are one way of supporting authentication.

Using Certificates for Authentication

A certificate consists of digital data that specifies the name of an individual, company, or other entity, and certifies that the public key, included in the certificate, belongs to that entity. Both clients and servers can have certificates.

A certificate is issued and digitally signed by a Certificate Authority, or CA. The 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 or extranet. You decide which CAs you trust enough to serve as verifiers of other people's identities.

In addition to a public key and the name of the entity identified by the certificate, a certificate also includes an expiration date, the name of the CA that issued the certificate, and the "digital signature" of the issuing CA.

Note

A server certificate must be installed before encryption can be activated.

Server Authentication

Server authentication refers to the confident identification of a server by a client; that is, identification of the organization assumed to be responsible for the server at a particular network address.

Client Authentication

Client authentication refers to the confident identification of a client by a server; that is, identification of the person assumed to be using the client software. Clients can have multiple certificates, much like a person might have several different pieces of identification.

Virtual Server Certificates

You can have a different certificate database per virtual server. Each virtual server database can contain multiple certificates. Virtual servers can also have different certificates within each instance.

Creating a Trust Database

Before requesting a server certificate, you must create a trust database. In Enterprise Server the Administration Server and each server instance can have its own trust database. The trust database should only be created on your local machine.

When you create the trust database, you specify a password that will be used for a key-pair file. You will also need this password to start a server using encrypted communications. For a list of guidelines to consider when changing a password, see "Changing Passwords or PINs".

In the trust database you create and store the public and private keys, referred to as your key-pair file. The key-pair file is used for SSL encryption. You will use the key-pair file when you request and install your server certificate. The certificate is stored in the trust database after installation. The key-pair file is stored encrypted in the following directory:

server_root/alias/<serverid-hostname>-key3.db.

The Enterprise Server Administration Server can only have one trust database. Each server instance can have its own trust database. Virtual servers are covered by the trust database created for their server instance.

Creating a Trust Database

To create a trust database, perform the following steps:

Access either the Enterprise Server Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click on the Create Database link.

Enter a password for the database.

Repeat.

Click OK.

For the Server Manager, click Apply, and then Restart for changes to take effect.

After creating a certificate trust database for your server, you can request a certificate and submit it to a Certificate Authority (CA). If your company has its own internal CA, 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. A list of available certificate authorities including links to their sites, is available on the Request a Certificate page. For more information on what CAs may require, a list of Certificate Authorities is available through both Server Administrator, and Server Manager Security Pages under Request a Certificate.

The Administration Server can have only one server certificate. Each server instance can have its own server certificate. You can select a server instance certificate for each virtual server.

Using password.conf

Normally, you cannot start an UNIX SSL-enabled server with the /etc/rc.local or the /etc/inittab files, because the server requires a password before starting. By default, the web server prompts the administrator for the key database password before starting up. If you must be able to start/restart an unattended web server, you can save the password in a password.conf file, but this is not recommended. Only do this if your system is adequately protected so that this file and the key databases are not compromised. The server's password.conf file should be owned by root or the user who installed the server, and only the owner should have read or write access.

On UNIX, leaving the SSL-enabled server's password in the password.conf file is a security risk. Anyone who can access the file has access to the SSL-enabled server's password. Consider the security risks before keeping the SSL-enabled server's password in the password.conf file.

On Windows NT/Windows 2000, if you have an NTFS file system, you should protect the directory that contains the password.conf file by restricting its access, even if you do not use the file. The directory should have read/write permissions for the administration server user and the web server user. Protecting the directory prevents others from creating a false password.conf file. You cannot protect directories or files on FAT file systems by restricting access to them.

Start an SSL-enabled Server Automatically

If security risks are not a concern for you, follow these steps to start your SSL-enabled server automatically:

Make sure SSL is on. See "Turning Security On".

Create a new password.conf file in the config subdirectory of the server instance.

If you are using the internal PKCS#11 software encryption module that comes with the server, enter the following information:

internal:your_password

If you are using a different PKCS#11 module (for hardware encryption or hardware accelerators), specify the name of the PKCS#11 module, followed with the password. For example:

nFast:your_password

Stop and restart your server for the new setting to take effect.

You will always be prompted to supply a password when starting the web server, even after the password.conf file has been created.

Requesting and Installing a VeriSign Certificate

VeriSign® is Enterprise Server's preferred certificate authority. VeriSign's VICE protocol simplifies the certificate request process. VeriSign has the advantage of being able to return their certificate directly to your server.

Requesting a VeriSign Certificate

To request a VeriSign Certificate, perform the following steps:

Access either the Enterprise Server Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Request VeriSign Certificate link.

Review the steps required.

Click Get Certificate.

Follow the VeriSign procedure.

Installing a VeriSign Certificate

If you request and receive approval for a VeriSign certificate, it should appear in the drop-down list of the Install VeriSign Certificate page in one to three days. To install a VeriSign Certificate, perform the following steps:

Access either the Enterprise Server Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Install VeriSign Certificate link.

Choose internal (software) from the drop-down list for cryptographic module, unless you will use an external encryption module.

Enter your Key Pair File Password or PIN.

Select the Transaction ID to Retrieve from the drop-down list.

You will usually want the last one.

Click Install.

For the Server Manager, click Apply, and then Restart for changes to take effect.

Requesting and Installing Other Server Certificates

Besides VeriSign, you can request and install certificates from other certificate authorities. A list of CAs is available through both Server Administrator, and Server Manager Security Pages under Request a Certificate. Your company or organization may provide its own internal certificates. This section describes how you would request and install these other types of server certificates.

Required CA Information

Before you begin the request process, make sure you know what information your CA requires. Whether you are requesting a server certificate from a commercial CA or an internal CA, you need to provide the following information:

Common Name must be the fully qualified hostname used in DNS lookups (for example, www.example.com). This is the hostname in the URL that a browser uses to connect to your site. If these two names don't match, a client is notified that the certificate name doesn't match the site name, creating doubt about the authenticity of your certificate. Some CAs might have different requirements, so it's important to check with them.

You can also enter wildcard and regular expressions in this field if you are requesting a certificate from an internal CA. Most vendors would not approve a certificate request with a wildcard or regular expression entered for common name.

Email Address is your business email address. This is used for correspondence between you and the CA.

Organization is 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 is an optional field that usually describes the city, principality, or country for the organization.

State or Province is usually required, but can be optional for some CAs. Note that most CAs won't accept abbreviations, but check with them to be sure.

Country is a required, two-character abbreviation of your country name (in ISO format). The country code for the United States is US.

All this information is combined as a series of attribute-value pairs called the distinguished name (DN), which uniquely identifies the subject of the certificate.

If you are purchasing your certificate from a commercial CA, you must contact the CA to find out what additional information they require before they issue a certificate. Most CAs require that you prove your identity. For example, they want to verify your company name and who is authorized by the company to administer the server, and they might ask whether you have the legal right to use the information you provide.

Some commercial CAs offer certificates with greater detail and veracity to organizations or individuals who provide more thorough identification. 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.example.com computer, but that you are a company that has been in business for three years, and have no outstanding customer litigation.

Requesting Other Server Certificates

To request a certificate, perform the following steps:

Access either the Enterprise Server Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Request a Certificate link.

Select if this is a new certificate or a 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.

Perform the following steps to specify how you want to submit the request for the certificate:

If the CA expects to receive the request in an email message, check CA Email and enter the email address of the CA. For a list of CAs, click List of available certificate authorities.

If you are requesting the certificate from an internal CA that is using Netscape Certificate Server, click CA URL and enter the URL for the Certificate Server. This URL should point to the certificate server's program that handles certificate requests. A sample URL might be: https://CA.example.com:444/cms.

Select the cryptographic module for the key-pair file you want to use when requesting the certificate from the drop-down list.

Select the cryptographic key size to be used with the certificate from the drop-down list. Choose a key size of 1024 or 2048 bits.

This key is used in RSA operations. Larger keys can provide improved security, but the computation time associated with this key is proportional to the square of the modulus. For example, a key size of 2048 bits takes four times longer to process than a 1024-bit key size.

Note

There are many factors that affect SSL performance, such as server load, operating system and SSL hardware accelerators. Also, older browsers might have problems with the larger key size. Do not change the key size without first determining if it is necessary for your environment.

Enter the password for your key-pair file.

This is the password you specified when you created the trust database, unless you selected a cryptographic module other than the internal module. 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.

Enter your identification information.

The format of this information varies by CA. For a general description of these fields, a list of Certificate Authorities is available through both Server Administrator, and Server Manager Security Pages under Request a Certificate. Note that most of this information usually isn't required for a certificate renewal.

Double-check your work to ensure accuracy.

The more accurate the information, the faster your certificate is likely to be approved. If your request is going to a certificate server, you'll be prompted to verify the form information before the request is submitted.

Click OK.

For the Server Manager, click Apply, and then Restart for changes to take effect.

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 choose to email the request, the server composes an email message containing the request and sends the message to the CA. Typically, the certificate is then returned to you via email. 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 email or other means depending on the CA.

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

Note

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 months to get approval. You are responsible for promptly providing all the necessary information to the CA.

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

Installing Other Server Certificates

When you receive your certificate back from the CA, it will be encrypted with your public key so that only you can decrypt it. Only by entering the correct password for your trust database can you decrypt and install your certificate.

There are three types of certificates:

Your own server's certificate to present to clients

A CA's own certificate for use in a certificate chain

A trusted CA's certificate

A certificate chain is a hierarchical series of certificates signed by successive certificate authorities. A CA certificate identifies a certificate authority (CA) and is used to sign certificates issued by that authority. A CA certificate can in turn be signed by the CA certificate of a parent CA, and so on, up to a root CA.

Note

If your CA doesn't automatically send you their certificate, you should request it. Many CAs include their certificate in the email with your certificate, and your server installs both certificates at the same time.

The server will use the key-pair file password you specify to decrypt the certificate when you install it. You can either save the email somewhere accessible to the server, or copy the text of the email and be ready to paste the text into the Install Certificate form, as described here.

Installing a Certificate

To install a certificate, perform the following steps:

Access either the Enterprise Server Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Install Certificate link.

Check the type of certificate you are installing:

This Server is for a single certificate associated only with your server.

Server Certificate Chain is for a CA's certificate to include in a certificate chain.

Trusted Certificate Authority (CA) is for a certificate of a CA that you want to accept as a trusted CA for client authentication.

Select the Cryptographic Module from the drop-down list.

Enter the Key-Pair File Password.

Leave the a name for the certificate field blank if it will be the only one used for this server instance, unless:

Multiple certificates will be used for virtual servers

Enter a certificate name unique within the server instance

Cryptographic modules other than internal are used

Enter a certificate name unique across all server instances within a single cryptographic module

If a name is entered, it will be displayed in the Manage Certificates list, and should be descriptive. For example, "United States Postal Service CA" is the name of a CA, and "VeriSign Class 2 Primary CA" describes both a CA and the type of certificate. When no certificate name is entered, the default value is applied.

Select either:

Message is in this file and enter the full pathname to the saved email

Message text (with headers) and paste the email text

If you copy and paste the text, be sure to include the headers -Begin Certificate- and -End Certificate-, including the beginning and ending hyphens.

Click OK.

Select either:

Add Certificate if you are installing a new certificate.

Replace Certificate if you are installing a certificate renewal.

For the Server Manager, click Apply, and then Restart for changes to take effect.

The certificate is stored in the server's certificate database. The filename will be <alias>-cert7.db. For example:

https-serverid-hostname-cert7.db

Migrating Certificates When You Upgrade

Key-pair files and certificates are migrated only if your server has security enabled. You can also migrate keys and certificates by themselves using the Security tabs in the Enterprise Server Administration Server page and the Server Manager page.

In Enterprise Server 6.1, the Enterprise Server Administration Server and each server instance has its own certificate and key-pair file, referred to as a trust database instead of an alias.

You manage the trust database and its constituent certificates, including the server certificate and all the included Certificate Authorities, from the Enterprise Server Administration Server for itself, and from the Server Manager for server instances. The certificate and key-pair database files are now named after the server instance that uses them. If in the previous version, multiple server instances shared the same alias, when migrated the certificate and key-pair file are renamed for the new server instance.

The entire trust database associated with the server instance is migrated. All the Certificate Authorities listed in your previous database are migrated to the Enterprise Server 6.1 database. If duplicate CAs occur, use the previous CA until it expires. Do not attempt to delete duplicate CAs.

Migrating a Certificate

To migrate a certificate, perform the following steps:

From your local machine, access either the Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Choose:

Migrate 3.X Certificates link from the Administration Server

Migrate Certificate link from the Server Manager.

Enter the 3.6 Server Root.

Enter the Alias.

Enter the Password.

Click OK.

For the Server Manager, click Apply, and then Restart for changes to take effect.

Using the Built-in Root Certificate Module

The dynamically loadable root certificate module included with Enterprise Server 6.1 contains the root certificates for many CAs, including VeriSign. The root certificate module allows you to upgrade your root certificates to newer versions in a much easier way than before. In the past, you were required to delete the old root certificates one at a time, then install the new ones one at a time. To install well-known CA certificates, you can now simply update the root certificate module file to a newer version as it becomes available through future versions of Enterprise Server or in Service Packs.

Because the root certificate is implemented as a PKCS#11 cryptographic module, you can never delete the root certificates it contains, and the option to delete will not be offered when managing these certificates. To remove the root certificates from your server instances, you can disable the root certificate module by deleting the following in the server's alias subdirectory:

libnssckbi.so (on most UNIX platforms)

libnssckbi.sl (on HP-UX)

nssckbi.dll (on Windows NT/Windows 2000)

If you later wish to restore the root certificate module, you can copy the extension from bin/https/lib (UNIX and HP-UX) or bin\https\bin (Windows NT/Windows 2000) back into the alias subdirectory.

You can modify the trust information of the root certificates. The trust information is written to the certificate database for the server instance being edited, not back to the root certificate module itself.

Managing Certificates

You can view, delete, or edit the trust settings of the various certificates installed on your server. This includes your own certificate and certificates from CAs.

To manage certificate lists, perform the following steps:

Access either the Enterprise Server Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Manage Certificates link.

If you are managing a certificate for a default configuration using the internal cryptographic module, a list of all installed certificates with their type and expiration date is displayed. All certificates are stored in the directory server_root/alias.

If you are using an external cryptographic module, such as a hardware accelerator, you will first need to enter your password for each specific module and click OK. The certificate list will update to include certificates in the module.

Click the Certificate Name you wish to manage.

An Edit Server Certificate page appears with management options for that type of certificate. Only CA certificates will allow you to set or unset client trust. Some external cryptographic modules will not allow certificates to be deleted.

In the Edit Server Certificate window you may select:

Delete Certificate or Quit for certificates obtained internally

Set client trust, Unset server trust, or Quit for CA certificates

Click OK.

For the Server Manager, click Apply, and then Restart for changes to take effect.

Certificate information includes the owner and who issued it.

Trust settings allow you to set client trust or unset server trust. For LDAP server certificates the server must be trusted.

Installing and Managing CRLs and CKLs

Certificate revocation lists (CRLs) and compromised key lists (CKLs) 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.

Installing a Local CRL or CKL

To install a local CRL or CKL from a CA, perform the following steps:

Obtain the URL provided by the CA for downloading CRLs or CKLs.

Enter the URL in your browser to access the site.

Follow the instructions provided by the CA for downloading the CRL or CKL to a local directory.

Access either the Enterprise Server Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Install Local CRL/CKLs link.

Select either:

Certificate Revocation List

Compromised Key List

Enter the full path name to the associated file.

Click OK.

If you selected Certificate Revocation List, the Add Certificate Revocation List page will appear listing CRL information.

If you selected Compromised Key List, the Add Compromised Key List page will appear listing CKL information.

Note

If a CRL or CKL list already exists in the database, a Replace Certificate Revocation List or Replace Compromised Key List page appears.

Click Add.

Click OK.

For the Server Manager, click Apply, and then Restart for changes to take effect.

Managing Local CRLs and CKLs

To manage local CRLs and CKLs, perform the following steps:

Access either the Enterprise Server Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Manage Local CRL/CKLs link.

The Manage Certificate Revocation Lists /Compromised Key Lists page appears with all installed Server CRLs and CKLs listed along with their expiration dates.

Select a Certificate Name from either the Server CRLs or Server CKLs list.

Choose:

Delete CRL

Delete CKL

For the Server Manager, click Apply, and then Restart for changes to take effect.

Configuring Remote CRLs

Configure automatic CRL downloads to help ensure that your CRLs are kept up to date with minimal inconvenience. Enterprise Server supports CRL downloads over HTTP, HTTP over SSL, LDAP, and LDAP over SSL. Once a CRL is downloaded, Enterprise Server stores the information in memory. Enterprise Server will not communicate with a client or server with a certificate listed on a CRL.

Enterprise Server provides two optional features you can enable for additional confidence using the automated CRL download process:

Shut down server if CRL updates fail

Shuts down Enterprise Server when a CRL update fails for any reason. Before Enterprise Server shuts down, an error message is written to the log for later analysis.

Shut down server if CRLs are too old

Shuts down Enterprise Server if the age of a downloaded CRL exceeds the time specified in its Next Update field. This condition indicates that the CRL may not contain the most recent information available. To avoid the possibility of users authenticating with compromised certificates that would have been added to an up-to-date CRL, you can choose to have Enterprise Server shut down automatically when a CRL is considered too old.

This check is performed when the CRL is downloaded. Therefore, an already downloaded CRL can become older than its Next Update time in the interval between updates and still be considered valid.

This feature does not apply to CRLs that do not have a Next Update field.

Note

For any CRL you use, be sure that the certificate for the corresponding CA is installed in the certificate database for the Enterprise Server instance. If you have enabled automatic/remote CRL downloads, Enterprise Server will fail to start if the certificate for the CA is not installed. See "Installing a Certificate".

Configuring Automatic/Remote CRL Downloads

To configure automatic/remote CRL downloads, perform the following steps:

Contact the CA for each CRL and get the following information:

the URL for downloading updated CRLs

how often the CRL is updated

the system time for the CRL download server

whether the CRL has a Next Update field

Access either the Enterprise Server Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Configure Remote CRLs link.

The Automatic/Remote Certificate Revocation List (CRL) Settings page appears.

Select the checkbox Enable automatic download of CRLs.

If you want Enterprise Server to shut down when a CRL is too old or when an update fails, select the corresponding checkbox.

In the first row of the table, specify an URL in the CRL Download URL field.

Enterprise Server supports CRL downloads over HTTP, HTTP over SSL, LDAP, and LDAP over SSL. Valid URL formats are:

ldap[s]://hostname:port/base_dn?attributes?scope?filter

For example:

ldap://ldap.example.com:5000/o=example.net?cn,mail, telephoneNumber?sub?(sn=Jensen)

http[s]://[username:password@]hostname[:port]/path[?query_string]

For example:

https://ca.example.com:1025/getCRL?op=getCRL&issuepoint=MasterCRL

Note

If a CRL download URL uses the HTTPS or the LDAPS protocol, verify with the CA that the certificate for the CRL server has not been revoked. Enterprise Server will not communicate with a client or server with a revoked certificate.

At startup, Enterprise Server does not yet have any CRLs stored in memory, so if the certificate has been revoked, the initial CRL update succeeds. However, once the CRL that lists the revoked certificate is stored in memory, subsequent update attempts will fail. If you have enabled the option Shut down server if CRL updates fail, Enterprise Server shuts down after the first failed update attempt. If not, Enterprise Server continues to run, but it cannot update the CRL.

In the Update Interval field, specify the maximum amount of time in minutes to allow between CRL downloads.

At startup, Enterprise Server downloads all CRLs configured for automatic downloading. To determine the time of the next download, Enterprise Server uses this value or the time specified in the Next Update field of the CRL, whichever is sooner. Not all CRLs have a Next Update field, however, so you must specify an update interval for each CRL.

To determine an appropriate update interval, consider the network connectivity and available bandwidth at your site and how often the CRL is updated.

In the Maximum Age field, specify the time in minutes you want Enterprise Server to wait past the time indicated in the CRL's Next Update field before determining that the CRL is too old to be valid.

To avoid unnecessary shutdowns, Netscape recommends that you set this value no lower than 5 (minutes) and take into account possible system time differences between the Enterprise Server host and the CA's CRL download server. Clocks on different servers can be out of sync, and the CA can still be generating a new CRL at Next Update time.

If you have not enabled the option Shut down server if CRLs are too old or if the CRL does not have a Next Update field, the value specified in this field has no impact. Accept the default value of 60 minutes.

When you are ready to save your configuration settings, click OK.

A popup message tells you your Automatic/Remote Certificate Revocation List (CRL) Settings have been updated.

Click OK to dismiss the popup.

The page reloads with your updated settings.

Repeat Step 6 through Step 10 as needed for all the CRLs you want to configure for automatic downloading.

To edit the automatic download settings for a CRL, select Edit from the pulldown menu in the left column of the row, edit the settings, then click OK.

To delete the automatic download settings for a CRL, select Delete from the pulldown menu in the left column of the row, then click OK.

For the Server Manager, click Apply and then Restart for changes to take effect.

Note

To tune your CRL download settings, temporarily enable the magnus.conf directive LogVerbose. Each time Enterprise Server attempts to download a CRL, a message will be written to the log with information that can help you determine if your settings are appropriate.

Reducing the SSL3/TLS Session Cache Timeout

By default, SSL3/TLS sessions do not expire for 24 hours. During this time, if a CRL is updated to revoke a certificate, users who previously authenticated with the revoked certificate can still access a site unless they close their browser. Only users who attempt to log in with the revoked certificate after the CRL is updated will be blocked.

To avoid this problem, reduce the timeout interval for the SSL3/TLS session cache. This interval is set with the SSL3SessionTimeout directive. Ideally, the timeout interval should be set as close as possible to the automatic update interval set for CRLs. (Note that the automatic update interval is specified in minutes, but the SSL session cache timeout interval is specified in seconds.) However, SSL3SessionTimeout is a global setting, so consider carefully before changing the interval.

See "SSL3SessionTimeout" for more information.

Setting Security Preferences

Once you have a certificate, you can begin securing your server. Several security elements are provided by Enterprise Server.

Encryption is the process of transforming information so it is unintelligible to anyone but the intended recipient. Decryption is the process of transforming encrypted information so that it is intelligible again. Enterprise Server 6.1 includes supports SSL and TLS encryption protocols.

A cipher is a cryptographic algorithm (a mathematical function), used for encryption or decryption. SSL and TLS protocols contain numerous cipher suites. Some ciphers are stronger and more secure than others. Generally speaking, the more bits a cipher uses, the harder it is to decrypt the data.

In any two-way encryption process, both parties must use the same ciphers. Because a number of ciphers are available, you need to enable your server for those most commonly used.

During a secure connection, the client and the server agree to use the strongest cipher they can both have for communication. You can choose ciphers from the SSL2, SSL3, and TLS protocols.

Note

Improvements to security and performance were made after SSL version 2.0; you should not use SSL 2 unless you have clients that are not capable of using SSL 3. Client certificates are not guaranteed to work with SSL 2 ciphers.

The encryption process alone isn't enough to secure your server's confidential information. A key must be used with the encrypting cipher to produce the actual encrypted result, or to decrypt previously encrypted information. The encryption process uses two keys to achieve this result: a public key and a private key. Information encrypted with a public key can be decrypted only with the associated private key. The public key is published as part of a certificate; only the associated private key is safeguarded.

To specify which ciphers your server can use, check them in the list. Unless you have a compelling reason not to use a specific cipher, you should check them all. However, you may not wish to enabling ciphers with less than optimal encryption.

Caution

Do not select No Encryption, only MD5 message authentication. If no other ciphers are available on the client side, the server will default to this setting and no encryption will occur.

SSL and TLS Protocols

Enterprise Server 6.1 supports the Secure Sockets Layer (SSL) and the Transport Layer Security (TLS) protocols for encrypted communication. SSL and TLS are application independent, and higher level protocols can be layered transparently on them.

SSL and TLS protocols support a variety of ciphers used to authenticate the server and client to each other, transmit certificates, and establish session keys. Clients and servers may support different cipher suites, or sets of ciphers, depending on factors such as which protocol they support, company policies on encryption strength, and government restrictions on export of encrypted software. Among other functions, the SSL and TLS handshake protocols determine how the server and client negotiate which cipher suites they will use to communicate.

Using SSL to Communicate with LDAP

You should require your Administration Server to communicate with LDAP using SSL. To enable SSL on your Administration Server, perform the following steps:

Access the Administration Server and choose the Global Settings tab.

Click the Configure Directory Service link.

Select Yes to use Secure Sockets Layer (SSL) for connections.

Click Save Changes.

Click OK to change your port to the standard port for LDAP over SSL.

Enabling Security for Connection Groups

You can secure your server's connection groups by:

Turning the security on

Selecting a server certificate for a connection group

Selecting ciphers

Turning Security On

You must turn security on before you can configure the other security settings for your connection group. You can turn security on when you create a new listen socket, or when you edit an existing listen socket.

Turning Security On When Creating a Listen Socket

To turn security on when creating a new listen socket, perform the following steps:

Access the Server Manager and select the server instance the listen socket will be created in from the drop-down list.

Select the Preferences tab, if not already displayed.

Choose the Add Listen Socket link.

The Create a Listen Socket page is displayed.

Enter the required information and select a default virtual server.

Turn Security on using the drop-down list.

Click OK

Click Apply, and then Restart for changes to take effect.

Note

You will need to use the Edit Listen Sockets link to configure the security settings after a listen socket is created.

Turning Security On When Editing a Listen Socket

You can also turn security on when editing a listen socket from either the Administration Server or the Server Manager. To turn security on when editing a listen socket, perform the following steps:

Access either the Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Select the Preferences tab, if not already displayed.

Choose the Edit Listen Sockets link.

The Listen Sockets Table page is displayed.

Use the drop-down Action list to select Edit, if not already displayed, for the connection group you want to secure.

Use the drop-down list in the Security column to turn security on for the connection group.

Click OK.

The Attributes link will now be displayed in the Security column.

For the Server Manager, click Apply, and then Restart for changes to take effect.

Selecting a Server Certificate for a Connection Group

You can configure connection groups in either the Administration Server or the Server Manager to use server certificates you have requested and installed.

Note

You must have at least one certificate installed.

To select a server certificate for your connection group to use, perform the following steps:

Access either the Administration Server or the Server Manager and choose the Preferences tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Edit Listen Sockets link.

The Listen Socket Table page appears.

Use the drop-down Action list to select Edit, if not already displayed, for the connection group you are selecting a certificate for.

Use the drop-down list to turn Security on for that connection group, if it is off.

Click the Attributes link.

The Security Settings of Listen Socket page appears.

Note

If you have an external module installed, the Manage Server Certificates page will appear requiring the external module's password before you can continue.

Select a server certificate from the drop-down CertificateName list for the connection group.

The list contains all internal and external certificates installed.

Click OK

For the Server Manager, click Apply, and then Restart for changes to take effect.

Selecting Ciphers

To protect the security of your web server, you should enable SSL. You can enable the SSL 2.0, SSL 3.0, and TLS encryption protocols and select the various cipher suites. SSL and TLS can be enabled on the connection group for the Administration Server. Enabling SSL and TLS on a connection group for the Server Manager will set those security preferences for all virtual servers associated with that connection group.

If you wish to have unsecured virtual servers, they must all be configured to the same connection group with security turned off.

The default settings allow the most commonly used ciphers. Unless you have a compelling reason why you don't want to use a specific cipher suite, you should allow them all.

Note

You must have at least one certificate installed.

To enable SSL and TLS, perform the following steps:

Access either the Administration Server or the Server Manager and choose the Preferences tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Edit Listen Sockets link.

The Listen Socket Table page appears.

Use the drop-down Action list to select Edit, if not already displayed, for the connection group you are enabling security for.

Use the drop-down list to turn Security on for that connection group, if it is off.

Click OK.

The Attributes link now appears.

Click the Attributes link.

The Security Settings of Listen Socket page appears.

Note

If you have an external module installed, the Manage Server Certificates page will appear requiring the external module's password before you can continue.

Select either:

Cipher Default

SSL2

SSL3 /TLS

(Optional) If you selected SSL2 or SSL3/TLS, in the Security Features window either:

Accept Allow and the default ciphers

Accept Allow and check only desired ciphers, or uncheck unwanted ciphers

Uncheck Allow to disable this protocol and all its ciphers

Note

Check both TLS and SSL3 for Netscape 6.0 or greater. Use the TLS Rollback option for Microsoft Internet Explorer 5.0 and 5.5. TLS must also be enabled on the browser seeking access to your server. For TLS Rollback also check TLS, and make sure both SSL3 and SSL2 are disabled.

Click OK to close the Security Features window.

Click OK

For the Server Manager, click Apply, and then Restart for changes to take effect.

Note

When you apply changes after turning on security for a connection group, the magnus.conf file is automatically modified to show security on, and all virtual servers associated with the connection group are automatically assigned the default security parameters.

Once you have enabled SSL on a server, its URLs use https instead of http. URLs that point to documents on an SSL-enabled server have this format:

https://servername[.domain.dom][:port]/

For example:

https://admin.example.com:443/

If you use the default secure HTTP port number (443), you don't have to specify the port number in the URL.

Configuring Security Globally

Installing an SSL-enabled server creates directive entries in the magnus.conf file (the server's main configuration file) for global security parameters. Security must be set to `on' for virtual server security settings to work. SSL properties for virtual servers can be found on a per-server basis in the SSLPARAMS element of the server.xml file.

To set values for your SSL configuration file directives, perform the following steps:

Access the Server Manager and select the server instance of the virtual server from the drop-down list.

Select the Preferences tab, if not already selected.

Choose the Edit Listen Sockets link.

Turn Security On for the listen socket you will set values for, if it isn't already on.

Click OK.

Go to the Magnus Editor link.

Select SSL Settings from the drop-down list and click Manage.

Enter the values for:

SSLSessionTimeout

SSLCacheEntires

SSL3SessionTimeout

Click OK

Click Apply, and then Restart for changes to take effect.

These SSL Configuration File Directives are described below:

SSLSessionTimeout

The SSLSessionTimeout directive controls SSL2 session caching.

Syntax

SSLSessionTimeout seconds

seconds is the number of seconds until a cached SSL session becomes invalid. The default value is 100. If the SSLSessionTimeout directive is specified, the value of seconds is silently constrained to be between 5 and 100 seconds.

SSLCacheEntries

Specifies the number of SSL sessions that can be cached.

SSL3SessionTimeout

The SSL3SessionTimeout directive controls SSL3 and TLS session caching.

Syntax

SSL3SessionTimeout seconds

seconds is the number of seconds until a cached SSL3 session becomes invalid. The default value is 86400 (24 hours). If the SSL3SessionTimeout directive is specified, the value of seconds is silently constrained to be between 5 and 86400 seconds.

Using External Encryption Modules

Enterprise Server 6.1 supports the following methods of using external cryptographic modules such as smart cards or token rings:

PKCS#11

FIPS-140

You will need to add the PKCS #11 module before activating the FIPS-140 encryption standard.

Installing the PKCS#11 Module

Enterprise Server supports Public Key Cryptography Standard (PKCS) #11, which defines the interface used for communication between SSL and PKCS#11 modules. PKCS#11 modules are used for standards-based connectivity to SSL hardware accelerators. Imported certificates and keys for external hardware accelerators are stored in the secmod.db file, which is generated when the PKCs#11 module is installed.

Using modutil to Install a PKCS#11 Module

You can install PKCS#11 modules in the form of .jar files or object files using the modutil tool.

To install the PKCS#11 module using modutil, perform the following steps:

Make sure all servers, including the Administration server, are turned off.

Go to the server_root/alias directory containing the databases.

Add server_root/bin/https/admin/bin to your PATH.

Locate modutil in server_root/bin/https/admin/bin.

Set the environment. For example:

On UNIX: setenv

LD_LIBRARY_PATH server_root/bin/https/lib:${LD_LIBRARY_PATH}

On HP-UX: SHLIB_PATH

On Windows NT/Windows 2000, add it to the PATH

LD_LIBRARY_PATH server_root/bin/https/bin

You can find the PATH for your machine listed under: server_root/https-admin/start.

Enter the command: modutil.

The options will be listed.

Perform the actions required.

For example, to add the PCKS#11 module in UNIX you would enter:

modutil -add PCKS#11_file_name -libfile PCKS#11_libfile -nocertdb -dbdir . db_directory

Using pk12util

The pk12util allows you to export certificates and keys from your internal database and to import them into an internal or external PKCS#11 module. You can always export certificates and keys to your internal database, but most external tokens will not allow you to export certificates and keys. By default, pk12util uses certificate and key databases named cert7.db and key3.db.

Exporting with pk12util

To export a certificate and key from an internal database, perform the following steps:

Go to the server_root/alias directory containing the databases.

Add server_root/bin/https/admin/bin to your PATH.

Locate pk12util in server_root/bin/https/admin/bin.

Set the environment. For example:

On UNIX: setenv

LD_LIBRARY_PATH/server_root/bin/https/lib:${LD_LIBRARY_PATH}

On HP-UX: SHLIB_PATH

On Windows NT/Windows 2000, add it to the PATH

LD_LIBRARY_PATH server_root/bin/https/bin

You can find the PATH for your machine listed under: server_root/https-admin/start.

Enter the command: pk12util.

The options will be listed.

Perform the actions required.

For example, on UNIX you would enter:

pk12util -o export_file -n server_cert [-d cert_dir] [-P db_prefix]

Enter the database password.

Enter pkcs12 password.

Importing with pk12util

To import a certificate and key into an internal or external PKCS#11 module, perform the following steps:

Go to the server_root/alias directory containing the databases.

Add server_root/bin/https/admin/bin to your PATH.

Locate pk12util in server_root/bin/https/admin/bin.

Set the environment. For example:

On UNIX: setenv

LD_LIBRARY_PATH/server_root/bin/https/lib:${LD_LIBRARY_PATH}

On HP-UX: SHLIB_PATH

On Windows NT/Windows 2000, add it to the PATH

LD_LIBRARY_PATH server_root/bin/https/bin

You can find the PATH for your machine listed under: server_root/https-admin/start.

Enter the command: pk12util.

The options will be listed.

Perform the actions required.

For example, in UNIX you would enter:

pk12util -i import_file [-d cert_dir] [-h "token_name"] [-P db_prefix]

-P must follow the -h and be the last argument.

Enter the exact token name including capital letters and spaces between quote marks.

Enter the database password.

Enter pkcs12 password.

Starting the Server with an External Certificate

If you install a certificate for your server into an external PKCS#11 module (for example, a hardware accelerator), the server will not be able to start using that certificate until you edit the server.xml, or specify the certificate name as described below.

The server always tries to start with the certificate named "Server-Cert." However, certificates in external PKCS#11 modules include one of the module's token names in their identifier. For example, a server certificate installed on an external smartcard reader called "smartcard0" would be named "smartcard0:Server-Cert."

To start a server with a certificate installed in an external module, you'll need to specify the certificate name for the connection group it runs on.

Selecting the Certificate Name for a Connection Group

To select the certificate name for the connection group, perform the following steps:

Access either the Administration Server or the Server Manager and choose the Preferences tab.

For the Server Manager you must first select the server instance from the drop-down list.

Select the Preferences tab, if not already selected.

Click the Edit Listen Sockets link.

The Listen Socket Table page appears.

Use the drop-down Action list to select Edit, if not already displayed, for the connection group you are enabling security for.

Use the drop-down list to turn Security on for that connection group, if it is off.

Click OK.

The Attributes link now appears.

Click the Attributes link.

The Security Settings of Listen Socket page appears.

Use the drop-down CertificateName list to select the external server certificate.

Click OK

For the Server Manager, click Apply, and then Restart for changes to take effect.

You can also tell the server to start with that server certificate instead by manually editing the server.xml file. Change the servercertnickname attribute of the SSLPARAMS subelement to:

$TOKENNAME:Server-Cert

To find what value to use for $TOKENNAME, go to the server's Security tab and select the Manage Certificates link. When you log in to the external module where Server-Cert is stored, its certificates are displayed in the list in the form token_name:nickname.

Note

If you did not create a trust database, one will be created for you when you request or install a certificate for an external PKCS#11 module. The default database created has no password and cannot be accessed. Your external module will work, but you will not be able to request and install server certificates. If a default database has been created without a password, use the Security tab Create Database page to set the password.

FIPS-140 Standard

PKCS#11 APIs enable communication with software or hardware modules that perform cryptographic operations. Once PKCS#11 is installed on your server, you can configure Enterprise Server to be Federal Information Processing Standards (FIPS)-140 compliant. These libraries are included only in SSL version 3.0.

To enable FIPS-140, perform the following steps:

Install the plug-in following the FIPS-140 instructions.

Access either the Administration Server or the Server Manager and choose the Preferences tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Edit Listen Sockets link.

The Listen Socket Table page appears.

Use the drop-down Action list to select Edit, if not already displayed, for the connection group you are enabling FIPS-140 on.

Use the drop-down list to turn Security on for that connection group, if it is off.

Click OK.

The Attributes link now appears.

Click the Attributes link.

The Security Settings of Listen Socket page appears.

Click the SSL3/TLS link.

The Security Feature window appears.

Check Allow: SSL version 3, if it is not already checked.

Select the appropriate FIPS-140 cipher suite:

(FIPS) DES with 56 bit encryption and SHA message authentication

(FIPS) Triple DES with 168 bit encryption and SHA message authentication

Click OK to close the Security Features window.

Click OK

For the Server Manager, click Apply, and then Restart for changes to take effect.

Setting Client Security Requirements

After you have performed all of the steps to secure your servers, you can set additional security requirements for your clients.

Requiring Client Authentication

You can enable the connection groups for your Administration Server and each server instance to require client authentication. When client authentication is enabled, the client's certificate is required before the server will send a response to a query.

Enterprise Server supports authenticating client certificates by matching the CA in the client certificate with a CA trusted for signing client certificates. You can view a list of CAs trusted for signing client certificates in the Manage Certificates page under Security in the Administration Server. There are four types of CAs:

Untrusted CA (will not be matched)

Trusted Server CA (will not be matched)

Trusted Client CA (will be matched)

Trusted Client/Server CA (will be matched)

You can configure the web server to refuse any client that doesn't have a client certificate from a trusted CA. To accept or reject trusted CAs, you must have set client trust for the CA. For more information, see "Managing Certificates".

Enterprise Server will log an error, reject the certificate, and return a message to the client if the certificate has expired. You can also view which certificates have expired in the Administration Servers Manage Certificates page.

You can configure your server to gather information from the client certificate and match it with a user entry in an LDAP directory. This ensures that the client has a valid certificate and an entry in the LDAP directory. It can also ensure that the client certificate matches the one in the LDAP directory. To learn how to do this, see "Mapping Client Certificates to LDAP".

You can combine client certificates with access control, so that in addition to being from a trusted CA, the user associated with the certificate must match the access control rules (ACLs). For more information, see "Using Access Control Files".

You can also process information from client certificates. For more information, see the Netscape Enterprise Server NSAPI Programmer's Guide.

To Require Client Authentication

To require client authentication, perform the following steps:

Access either the Administration Server or the Server Manager and choose the Preferences tab.

For the Server Manager you must first select the server instance from the drop-down list.

Click the Edit Listen Sockets link.

The Listen Socket Table page appears.

Use the drop-down Action list to select Edit, if not already displayed, for the connection group you are requiring client authentication for.

Use the drop-down list to turn Security on for that connection group, if it is off.

Click the Attributes link.

The Security Settings of Listen Socket page appears.

Toggle on client authentication by clicking On.

Click OK.

For the Server Manager, click Apply, and then Restart for changes to take effect.

Note

There is a single certificate trust database per web server instance. All the secure virtual servers running under that server instance share the same list of trusted client CAs. If two virtual servers require different trusted CAs, then these virtual servers should be run in different server instances with separate trust databases.

Mapping Client Certificates to LDAP

This section describes the process Enterprise Server uses to map a client certificate to an entry in an LDAP directory.

When the server gets a request from a client, it asks for the client's certificate before proceeding. Some clients send the client certificate to the server along with the request.

Note

Before mapping client certificates to LDAP, you also need to set up the required ACLs; for more information, see Chapter 8 "Controlling Access to Your Server."

The server tries to match the CA to the list of trusted CAs in the Administration Server. If there isn't a match, Enterprise Server ends the connection. If there is a match, the server continues processing the request.

After verifying the certificate is from a trusted CA, the server maps the certificate to an LDAP entry by:

Mapping the issuer and subject DN from the client certificate to a branch point in the LDAP directory.

Searching the LDAP directory for an entry that matches the information about the subject (end-user) of the client certificate.

(Optional) Verifying the client certificate with one in the LDAP entry that corresponds to the DN.

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, email 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 no matching entry or more than one matching entry, and the mapping is not set to verify the certificate, the search fails. For a complete list of the expected search result behavior, see the following Table 5-1 table. Note that you can specify the expected behavior in the ACL; for example, you can specify that Enterprise Server accepts you if the certificate match fails. For more information regarding how to set the ACL preferences, see "Using Access Control Files".

Table 5-1    LDAP Search Results

LDAP Search Result

Certificate Verification ON

Certificate Verification OFF

No entry found

Authentication fails

Authentication fails

Exactly one entry found

Authentication fails

Authentication succeeds

More than one entry found

Authentication fails

Authorization fails

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.

Using the certmap.conf File

Certificate mapping determines how a server looks up a user entry in the LDAP directory. You can use certmap.conf to configure how a certificate, designated by name, is mapped to an LDAP entry. You edit this file and add entries to match the organization of your LDAP directory and to list the certificates you want your users to have. Users can be authenticated based on userid, email, or any other value used in the subjectDN. Specifically, the mapping file defines the following information:

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 certificate mapping file is located in the following location:

server_root/userdb/certmap.conf

The 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 attributes that form the distinguished name found in the CA certificate. The name is arbitrary; you can define it to be whatever you want. However, issuerDN must exactly match the issuer DN of the CA who issued the client certificate. For example, the following two issuerDN lines differ only in the spaces separating the attributes, but the server treats these two entries as different:

certmap example1 ou=Example Certificate Authority,o=example,c=US certmap example2 ou=Example Certificate Authority,o=example, c=US

Tip

If you are using Directory Server and experiencing problems in matching the issuerDN, check the Directory Server error logs for useful information.

The second and subsequent lines in the named mapping match properties with values. The certmap.conf file has six default properties (you can use the certificate API to customize your own properties):

DNComps is 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 (that is, 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 c 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.

Note the following situations:

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 (that is, 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 is 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 email and userid attributes (FilterComps=e,uid), the server searches the directory for an entry whose values for email and userid match the end user's information gathered from the client certificate. Email addresses and userids 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.

For a list of the x509v3 certificate attributes, see the following table:

Table 5-2    Attributes for x509v3 Certificates

Attribute

Description

c

Country

o

Organization

cn

Common name

l

Location

st

State

ou

Organizational unit

uid

User ID

email

Email address

The attribute names for the filters need to be attribute names from the certificate, not from the LDAP directory. For example, some certificates have an e attribute for the user's email address; whereas LDAP calls that attribute mail.

verifycert 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 is a name for the attribute in the LDAP directory that contains subject DNs from all certificates belonging to the user. The default for this property is certSubjectDN. This attribute isn't a standard LDAP attribute, so to use this property, you have to extend the LDAP schema. For more information, see Managing Servers with Netscape Console.

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 is 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, see the Netscape Enterprise Server NSAPI Programmer's Guide.

InitFn is 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.

For more information on these properties, refer to the examples described in "Sample Mappings".

Creating Custom Properties

You can use the client certificate API to create your own properties. For information on programming and using the client certificate API, see the Netscape Enterprise Server NSAPI Programmer's Guide.

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/enterprise/userdb/plugin.so default1:InitFn plugin_init_fn default1:DNComps ou o c default1:FilterComps l default1:verifycert on

Sample Mappings

The certmap.conf file should have at least one entry. The following examples illustrate the different ways you can use the certmap.conf file.

Example #1

This example represents a 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 variables are replaced with the values from the subject's DN in the client certificate.

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

Example #2

The following example file has two mappings: one for default and another for the US Postal Service:

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

When the server gets a certificate from anyone other than the US Postal Service, it uses the default mapping, which starts at the top of the LDAP tree and searches for an entry matching the client's email and userid. If the certificate is from the US Postal Service, 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 the USPS, the server verifies the certificate; other certificates are not verified.

Caution

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. In the previous example, a certificate from an issuer DN that is o=United States Postal Service,c=US won't match because there isn't a space between the o and the c attributes.

Example #3

The following 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=Example Corporation, o=example, c=US example:CmapLdapAttr certSubjectDN example:DNComps o, c example:FilterComps mail, uid example:verifycert on

If the client certificate subject is:

uid=Babs Jensen, o=Example Corporation, c=US

the server first searches for entries that contain the following information:

certSubjectDN=uid=Babs Jensen, o=Example Corporation, 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=Babs Jensen in all entries under o=Example Corporation, c=US.

Note

This example assumes the LDAP directory contains entries with the attribute certSubjectDN.

Setting Stronger Ciphers

The Stronger Ciphers option presents a choice of 168, 128, or 56-bit secret key size for access, or no restriction. You can specify a file to be served when the restriction is not met. If no file is specified, Enterprise Server returns a "Forbidden" status.

If you select a key size for access that is not consistent with the current cipher settings under Security Preferences, Enterprise Server displays a popup dialog warning that you need to enable ciphers with larger secret key sizes.

The implementation of the key size restriction is now based on an NSAPI PathCheck directive in obj.conf, rather than Service fn=key-toosmall. This directive is:

PathCheck fn="ssl-check" [secret-keysize=<nbits>] [bong-file=<filename>]

where <nbits> is the minimum number of bits required in the secret key, and <filename> is the name of a file (not a URI) to be served if the restriction is not met.

PathCheck returns REQ_NOACTION if SSL is not enabled, or if the secret-keysize parameter is not specified. If the secret key size for the current session is less than the specified secret-keysize, the function returns REQ_ABORTED with a status of PROTOCOL_FORBIDDEN if bong-file is not specified, or else REQ_PROCEED, and the "path" variable is set to the bong-file <filename>. Also, when a key size restriction is not met, the SSL session cache entry for the current session is invalidated, so that a full SSL handshake will occur the next time the same client connects to the server.

Note

The Stronger Ciphers form removes any Service fn=key-toosmall directives that it finds in an object when it adds a PathCheck fn=ssl-check.

To set Stronger Ciphers, perform the following steps:

Access the Server Manager and select the server instance from the drop-down list.

Click the Virtual Server Class tab.

Select a class from the drop-down list and click Manage.

The Class Manger page appears.

Choose the Content Mgmt tab.

Select Stronger Ciphers.

Choose to edit:

from the drop down list

by clicking Browse

by clicking Wildcard

Select the secret key size restriction:

168 bit or larger

128 bit or larger

56 bit or larger

No restrictions

Enter the file location of the message to reject access.

Click OK.

Click Apply.

Select hard start /restart or dynamically apply

Considering Additional Security Issues

There are other security risks besides someone trying to break your encryption. Networks face risks from external and internal hackers, using a variety of tactics to gain access to your server and the information on it.

In addition to enabling encryption on your server, you should take extra security precautions. For example, put the server machine into a secure room, and don't allow individuals you don't trust to upload programs to your server.

The following sections describe the most important things you can do to make your server more secure:

Limit Physical Access

Limit Administration Access

Choosing Passwords

Changing Passwords or PINs

Limiting Other Applications on the Server

Preventing Clients from Caching SSL Files

Limiting Ports

Knowing Your Server's Limits

Making Additional Changes to Protect Servers

Limit Physical Access

This simple security measure is often forgotten. Keep the server machine in a locked room that only authorized people can enter. This prevents anyone from hacking the server machine itself.

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

Limit Administration Access

If you use remote configuration, be sure to set access control to allow administration from only a few users and computers. If you want your Administration Server to provide end-user access to the LDAP server or local directory information, consider maintaining two Administration Servers and using cluster management, so that the SSL-enabled Administration Server acts as the master server, and the other Administration Server is available for end-users' access.

For more information regarding clusters, see "About Clusters".

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.

Choosing Passwords

You use a number of passwords with your server: the administrative password, the private key password, database passwords, and so on. Your administrative password is the most important password of all, since anyone with that password can configure any and all servers on your computer. Your private key password is next most important. 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 MCi12!mo as "My Child is 12 months old!" A bad password is your child's name or birthdate.

Creating Hard-to-Crack Passwords

There are some simple guidelines that will help you create a stronger password.

It is not necessary to incorporate all of the following rules in one password, but the more of the rules you use, the better your chances of making your password hard to crack:

Passwords should be 6-14 characters long.

Do not use the "illegal" characters: *, ", or spaces

Do not use dictionary words (any language)

Do not make common letter substitutions, like replacing E with 3, or L with 1

Include characters from as many of these classes as possible:

Uppercase letters

Lowercase letters

Numbers

Symbols

Changing Passwords or PINs

It's a good practice to change your trust database/key pair file password or PIN periodically. If your Administration Server is SSL enabled, this password is required when starting the server. Changing your password periodically adds an extra level of server protection.

You should only change this password on your local machine. For a list of guidelines to consider when changing a password, see "Creating Hard-to-Crack Passwords".

Changing Passwords

To change your trust database/key-pair file password for the Administration Server or an server instance, perform the following steps:

Access either the Administration Server or the Server Manager and choose the Security tab.

For the Server Manager you must first select the server instance from the drop-down list.

Select the Change Password link.

Select the security token on which you want to change the password from the drop-down list.

By default this is `internal' for the internal key database. If you have PKCS#11 modules installed, you will see all the tokens listed. Click the Change Password link.

Enter your current password.

Enter your new password

Enter it again.

Click OK.

For the Server Manager, click Apply, and then Restart for changes to take effect

Make sure your key-pair file is protected. The Administration Server stores key-pair files in the directory server_root/alias. Consider making the files and directory readable only to Netscape servers installed on your computer.

It's also important to know if the file is stored on backup tapes or is otherwise available for someone to intercept. If so, you must protect your backups as completely as your server.

Limiting Other Applications on the Server

Carefully consider all applications that run on the same machine as the server. It's possible to circumvent your server's security by exploiting holes in other programs running on your server. Disable all unnecessary programs and services. For example, the UNIX sendmail daemon is difficult to configure securely and it can be programmed to run other possibly detrimental programs on the server machine.

UNIX/Linux

Carefully choose the processes started from inittab and rc scripts. Don't run telnet or rlogin from the server machine. You also shouldn't have rdist on the server machine (this can distribute files but it can also be used to update files on the server machine).

Windows NT/Windows 2000

Carefully consider which drives and directories you share with other machines. Also, consider which users have accounts or Guest privileges.

Similarly, be careful about what programs you put on your server, or allow other people to install on your server. Other people's programs might have security holes. Worst of all, someone might upload a malicious program designed specifically to subvert your security. Always examine programs carefully before you allow them on your server.

Preventing Clients from Caching SSL Files

You can prevent pre-encrypted files from being cached by a client by adding the following line inside the <HEAD> section of a file in HTML:

<meta http-equiv="pragma" content="no-cache">

Limiting Ports

Disable any ports not used on the machine. Use routers or firewall configurations to prevent incoming connections to anything other than the absolute minimum set of ports. This means that the only way to get a shell on the machine is to physically use the server's machine, which should be in a restricted area already.

Knowing Your Server's Limits

The server offers secure connections between the server and the client. It can't control the security of information once the client has it, nor can it control access to the server machine itself and its directories and files.

Being aware of these limitations helps you understand 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.

Making Additional Changes to Protect Servers

If you want to have both protected and unprotected servers, you should operate the unprotected server on a different machine from the protected one. If your resources are limited and you must run an unprotected server on the same machine as your protected server, do the following.

Assign proper port numbers. Make sure that the protected server and the unprotected server are assigned different port numbers. The registered default port numbers are:

443 for the protected server

80 for the unprotected server

For UNIX or Linux, enable the chroot feature for the document root directory. The unprotected server should have references to its document root redirected using chroot.

chroot allows you to create a second root directory to limit the server to specific directories. You'd use this feature to safeguard an unprotected server. For example, you could say that the root directory is /d1/ms. Then any time the web server tries to access the root directory, it really gets /d1/ms. If it tries to access /dev, it gets /d1/ms/dev and so on. This allows you to run the web server on your UNIX/Linux system, without giving it access to all the files under the actual root directory.

However, if you use chroot, you need to set up the full directory structure required by Enterprise Server under the alternative root directory, as shown in the following illustration:

Figure 5-1    Example of chroot Directory Structure

Specifying chroot for a Virtual Server Class CGIs (UNIX/Linux Only)

You can specify the chroot directory for virtual server class CGIs by performing the following steps:

Access the Server Manager and select the server instance from the drop-down list.

Select the Virtual Server Class tab.

Click the Edit Classes link.

Make sure the Option is set to Edit for the class in which you wish to specify chroot.

Click the Advanced button for that class.

The Virtual Servers CGI Settings page appears.

Enter the full pathname in the Chroot field.

Click OK.

Click Apply.

Choose Load Configuration Files to dynamically apply.

Specifying chroot for a Virtual Server CGIs (UNIX/Linux only)

You can specify the chroot directory for a specific virtual server's CGIs by performing the following steps:

Access the Server Manager and select the server instance from the drop-down list.

Select the Virtual Server Class tab.

Click on the link for the virtual server you wish to specify the chroot directory for from the Tree View of the Server.

Select the Settings tab.

The Settings page appears.

Enter the full pathname in the Set to field next to Chroot Directory.

Click OK.

Click Apply.

Choose Load Configuration Files to dynamically apply.

You can also specify the chroot directory for a virtual server using the Class Manager Virtual Servers tab and the CGI Settings link.

For more information regarding how to specify a chroot directory for a virtual server, see the Netscape Enterprise Server Programmer's Guide.

LDAP Search Result	Certificate Verification ON	Certificate Verification OFF
No entry found	Authentication fails	Authentication fails
Exactly one entry found	Authentication fails	Authentication succeeds
More than one entry found	Authentication fails	Authorization fails

Attribute	Description
`c`	Country
`o`	Organization
`cn`	Common name
`l`	Location
`st`	State
`ou`	Organizational unit
`uid`	User ID
`email`	Email address

Last Updated August 02, 2002


Note	A server certificate must be installed before encryption can be activated.


Note	There are many factors that affect SSL performance, such as server load, operating system and SSL hardware accelerators. Also, older browsers might have problems with the larger key size. Do not change the key size without first determining if it is necessary for your environment.


Note	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 months to get approval. You are responsible for promptly providing all the necessary information to the CA.


Note	If your CA doesn't automatically send you their certificate, you should request it. Many CAs include their certificate in the email with your certificate, and your server installs both certificates at the same time.


Note	If a CRL or CKL list already exists in the database, a Replace Certificate Revocation List or Replace Compromised Key List page appears.


Note	For any CRL you use, be sure that the certificate for the corresponding CA is installed in the certificate database for the Enterprise Server instance. If you have enabled automatic/remote CRL downloads, Enterprise Server will fail to start if the certificate for the CA is not installed. See "Installing a Certificate".


Note	If a CRL download URL uses the HTTPS or the LDAPS protocol, verify with the CA that the certificate for the CRL server has not been revoked. Enterprise Server will not communicate with a client or server with a revoked certificate. At startup, Enterprise Server does not yet have any CRLs stored in memory, so if the certificate has been revoked, the initial CRL update succeeds. However, once the CRL that lists the revoked certificate is stored in memory, subsequent update attempts will fail. If you have enabled the option Shut down server if CRL updates fail, Enterprise Server shuts down after the first failed update attempt. If not, Enterprise Server continues to run, but it cannot update the CRL.


Note	To tune your CRL download settings, temporarily enable the `magnus.conf` directive `LogVerbose`. Each time Enterprise Server attempts to download a CRL, a message will be written to the log with information that can help you determine if your settings are appropriate.


Note	Improvements to security and performance were made after SSL version 2.0; you should not use SSL 2 unless you have clients that are not capable of using SSL 3. Client certificates are not guaranteed to work with SSL 2 ciphers.


Caution	Do not select No Encryption, only MD5 message authentication. If no other ciphers are available on the client side, the server will default to this setting and no encryption will occur.


Note	You will need to use the Edit Listen Sockets link to configure the security settings after a listen socket is created.


Note	If you have an external module installed, the Manage Server Certificates page will appear requiring the external module's password before you can continue.


Note	Check both TLS and SSL3 for Netscape 6.0 or greater. Use the TLS Rollback option for Microsoft Internet Explorer 5.0 and 5.5. TLS must also be enabled on the browser seeking access to your server. For TLS Rollback also check TLS, and make sure both SSL3 and SSL2 are disabled.


Note	When you apply changes after turning on security for a connection group, the `magnus.conf` file is automatically modified to show security on, and all virtual servers associated with the connection group are automatically assigned the default security parameters.


Note	If you did not create a trust database, one will be created for you when you request or install a certificate for an external PKCS#11 module. The default database created has no password and cannot be accessed. Your external module will work, but you will not be able to request and install server certificates. If a default database has been created without a password, use the Security tab Create Database page to set the password.


Note	There is a single certificate trust database per web server instance. All the secure virtual servers running under that server instance share the same list of trusted client CAs. If two virtual servers require different trusted CAs, then these virtual servers should be run in different server instances with separate trust databases.


Note	Before mapping client certificates to LDAP, you also need to set up the required ACLs; for more information, see Chapter 8 "Controlling Access to Your Server."


Tip	If you are using Directory Server and experiencing problems in matching the `issuerDN`, check the Directory Server error logs for useful information.


Caution	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. In the previous example, a certificate from an issuer DN that is `o=United States Postal Service,c=US` won't match because there isn't a space between the `o` and the `c` attributes.


Note	This example assumes the LDAP directory contains entries with the attribute `certSubjectDN`.


Note	The Stronger Ciphers form removes any Service `fn=key-toosmall` directives that it finds in an object when it adds a `PathCheck` `fn=ssl-check`.