Previous     Contents     Index     DocHome     Next     
iPlanet Web Server, Enterprise Edition Administrator's Guide



Chapter 5   Securing Your Web 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. iPlanet Web Server 6.0 incorporates the security architecture of all iPlanet 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. For more information, see Introduction to SSL located at:

http://docs.iplanet.com/docs/manuals/security/sslin/index.htm

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



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. For more information regarding the content and format of a certificate, see Introduction to SSL.

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 instance 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 iPlanet Web 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 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:

  1. 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.

  2. Click on the Create Database link.

  3. Enter a password for the database.

  4. Repeat.

  5. Click OK.

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


Using password.conf

By default, the web server prompts the administrator for the key database password before starting up. If you want to be able to restart an unattended web server, you need to save the password in a password.conf file. Only do this if your system is adequately protected so that this file and the key databases are not compromised.

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. Although you can start an SSL-enabled server automatically if you keep the password in plain text in a file, this is not recommended. The server's password.conf file should be owned by root or the user who installed the server, with only the owner having read and write access to them.

On Unix, leaving the SSL-enabled server's password in the password.conf file is a large 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 NT, 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:

  1. Make sure SSL is on.

  2. 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

  3. 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 iPlanet Web 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.

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.


Requesting a VeriSign Certificate

To request a VeriSign Certificate, perform the following steps:

  1. 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.

  2. Click the Request VeriSign Certificate link.

  3. Review the steps required.

  4. Click Get Certificate.

  5. 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:

  1. 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.

  2. Click the Install VeriSign Certificate link.

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

  4. Enter your Key Pair File Password or PIN.

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

    You will usually want the last one.

  6. Click Install.

  7. 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.iplanet.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.iplanet.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:

  1. 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.

  2. Click the Request a Certificate link.

  3. 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.

  4. 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.mozilla.com:444/cms.

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

  6. 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.

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

  8. 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.

  9. Click OK.

  10. 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.


When you receive a certificate from the CA, it will be encrypted with your public key so that only you can decrypt it. The server will use the key-pair file password you specify to decrypt the certificate when you install it. You can either save the 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:

  1. 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.

  2. Click the Install Certificate link.

  3. 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.

  4. Select the Cryptographic Module from the drop-down list.

  5. Enter the Key-Pair File Password.

  6. 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.

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

  8. Click OK.

  9. Select either:

    • Add Certificate if you are installing a new certificate.

    • Replace Certificate if you are installing a certificate renewal.

  10. 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

If you are upgrading from iPlanet Web Server 4.x, your files, including your trust and certificate databases, will be updated automatically.

If you are upgrading from an Enterprise Server 3.x, you will need to migrate your trust and certificate databases. Make sure that iPlanet Web Server 6.0 Administration Server user has read and write permissions on the old 3.x database files. The files are <alias>-cert.db and <alias>-key.db, located in the <3.x_server_root>/alias directory.

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 Administration Server page and the Server Manager page.

In previous versions, a certificate and key-pair file was referred to by an alias which could be used by multiple server instances. The Administration Server managed all the aliases and their constituent certificates. In iPlanet Web Server 6.0, the 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 Administration Server for its self, 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 iPlanet Web Server 6.0 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:

  1. 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.

  2. Choose:

    • Migrate 3.X Certificates link from the Administration Server

    • Migrate Certificate link from the Server Manager.

  3. Enter the 3.6 Server Root.

  4. Enter the Alias.

  5. Enter the Password.

  6. Click OK.

  7. 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 iPlanet Web Server 6.0 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 iPlanet Web 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 file:

  • libnssckbi.so (on most Unix platforms)

  • libnssckbi.sl (on HP-UX)

  • nssckbi.dll (on NT)

If you later wish to restore the root certificate module, you can copy the extension from bin/https/lib (Unix and HP) or bin\https\bin (NT) 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:

  1. 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.

  2. 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.

  3. 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.

Figure 5-1    Edit Sever Certificate

  1. 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

  2. Click OK.

  3. 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 CRL or CKL

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

  1. Obtain the CA's URL for downloading CRLs or CKLs.

  2. Enter the URL in your browser to access the site.

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

  4. 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.

  5. Click the Install CRL/CKLs link.

  6. Select either:

    • Certificate Revocation List

    • Compromised Key List

  7. Enter the full path name to the associated file.

  8. 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 will appear.


  9. Click Add.

  10. Click OK.

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


Managing CRLs and CKLs

To manage CRLs and CKLs, perform the following steps:

  1. 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.

  2. Click the Manage 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.

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

  4. Choose:

    • Delete CRL

    • Delete CKL

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



Setting Security Preferences

Once you have a certificate, you can begin securing your server. Several security elements are provided by iPlanet Web 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. iPlanet Web Server 6.0 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.

For description of the various cipher suites, and more information about keys and certificates, see Introduction to SSL.

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

iPlanet Web Server 6.0 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:

  1. Access the Administration Server and choose the Global Settings tab.

  2. Click the Configure Directory Service link.

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

  4. Click Save Changes.

  5. 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:

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

  2. Select the Preferences tab, if not already displayed.

  3. Choose the Add Listen Socket link.

    The Create a Listen Socket page is displayed.

  4. Enter the required information and select a default virtual server.

  5. Turn Security on using the drop-down list.

  6. Click OK

  7. 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:

  1. 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.

  2. Select the Preferences tab, if not already displayed.

  3. Choose the Edit Listen Sockets link.

    The Listen Sockets Table page is displayed.

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

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

  6. Click OK.

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

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


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

  1. 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.

  2. Click the Edit Listen Sockets link.

    The Listen Socket Table page appears.

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

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

  5. 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.


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

    The list contains all internal and external certificates installed.

  7. Click OK

  8. 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. For more information regarding specific ciphers, see Introduction to SSL

Note You must have a certificate is installed.


To enable SSL and TLS, perform the following steps:

  1. 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.

  2. Click the Edit Listen Sockets link.

    The Listen Socket Table page appears.

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

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

  5. Click OK.

    The Attributes link now appears.

  6. 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.


  7. Select either:

    • Cipher Default

    • SSL2

    • SSL3 /TLS

  8. (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 Navigator 6.0. 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.


  9. Click OK to close the Security Features window.

  10. Click OK

  11. 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.iplanet.com:443.

If you use the default secure http port number (443), you don't have to enter 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:

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

  2. Select the Preferences tab, if not already selected.

  3. Choose the Edit Listen Sockets link.

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

  5. Click OK.

  6. Go to the Magnus Editor link.

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

  8. Enter the values for:

    • SSLSessionTimeout

    • SSLCacheEntires

    • SSL3SessionTimeout

  9. Click OK

  10. 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.

Note A single connection group on a listen socket must have the same SSLPARAMS; multiple groups can have different SSLPARAMS.




Using External Encryption Modules


iPlanet Web Server 6.0 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#11Module

iPlanet Web 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:

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

  2. Go to the server_root/alias directory containing the databases.

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

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

  5. Set the environment. For example:

    • On Unix: setenv

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

    • On IBM-AIX: LIBPATH

    • On HP-UX: SHLIB_PATH

    • On NT, 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.

  6. Enter the command: modutil.

    The options will be listed.

  7. Perform the actions required.

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

    modutil -add (the name of PCKS#11 file) -libfile (your libfile for PCKS#11) -nocertdb -dbdir . (your 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:

  1. Go to the server_root/alias directory containing the databases.

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

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

  4. Set the environment. For example:

    • On Unix: setenv

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

    • On IBM-AIX: LIBPATH

    • On HP-UX: SHLIB_PATH

    • On NT, 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.

  5. Enter the command: pk12util.

    The options will be listed.

  6. Perform the actions required.

    For example, in Unix you would enter:

    pk12util -o certpk12 -n Server-Cert [-d /server/alias] [-P https-test-host]

  7. Enter the database password.

  8. Enter pkcs12 password.


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

  1. Go to the server_root/alias directory containing the databases.

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

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

  4. Set the environment. For example:

    • On Unix: setenv

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

    • On IBM-AIX: LIBPATH

    • On HP-UX: SHLIB_PATH

    • On NT, 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.

  5. Enter the command: pk12util.

    The options will be listed.

  6. Perform the actions required.

    For example, in Unix you would enter:

    pk12util -i pk12_sunspot [-d certdir][-h "nCipher"][-P https-jones.redplanet.com-jones-]

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

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

  7. Enter the database password.

  8. 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:

  1. 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.

  2. Select the Preferences tab, if not already selected.

  3. Click the Edit Listen Sockets link.

    The Listen Socket Table page appears.

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

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

  6. Click OK.

    The Attributes link now appears.

  7. Click the Attributes link.

    The Security Settings of Listen Socket page appears.

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

  9. Click OK

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

You could also tell the server to start with that server certificate instead, by manually editing the server.xml file. Change the servercertnickname attribute in the SSLPARAMS 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 $TOKENNAME:$NICKNAME form.
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 iPlanet Web 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:

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

  2. 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.

  3. Click the Edit Listen Sockets link.

    The Listen Socket Table page appears.

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

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

  6. Click OK.

    The Attributes link now appears.

  7. Click the Attributes link.

  8. The Security Settings of Listen Socket page appears.

  9. Click the SSL3/TLS link.

    The Security Feature window appears.

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

  11. 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

  12. Click OK to close the Security Features window.

  13. Click OK

  14. 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.

iPlanet Web 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.

iPlanet Web 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 NSAPI Programmer's Guide.


To Require Client Authentication

To require client authentication, perform the following steps:

  1. 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.

  2. Click the Edit Listen Sockets link.

    The Listen Socket Table page appears.

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

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

  5. Click the Attributes link.

    The Security Settings of Listen Socket page appears.

  6. Click Off for Client Auth to turn it on.

  7. Click OK.

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

    Currently, 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 iPlanet Web 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 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, iPlanet Web Server ends the connection. If there is a match, the server continues processing the request.

After the 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 iPlanet Web Server accepts only 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