Previous     Contents     Index          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. 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 Server 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 at least one certificate 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


      Note If you select Cipher Default, be aware that this option restores default cipher settings on your server, overriding any changes you might have made to the security settings of the Listen Socket.


  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 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/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 iplanet1 ou=iPlanet Certificate Authority,o=iPlanet,c=US
certmap iplanet2 ou=iPlanet Certificate Authority,o=iPlanet, c=US
Tip

If you are using iPlanet 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  

    Unix/Linux userid  

    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 Introduction to SSL.

    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 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 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 text in <> is 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=My Company Inc, o=myco, c=US
myco:CmapLdapAttr certSubjectDN
myco:DNComps o, c
myco:FilterComps mail, uid
myco:verifycert on

If the client certificate subject is:

uid=Walt Whitman, o=LeavesOfGrass Inc, c=US

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

certSubjectDN=uid=Walt Whitman, o=LeavesOfGrass Inc, c=US

If one or more matching entries are found, the server proceeds to verify the entries. If no matching entries are found, the server will use DNComps and FilterComps to search for matching entries. In this example, the server would search for uid=Walt Whitman in all entries under o=LeavesOfGrass Inc, 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, iPlanet Web 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, iPlanet Web 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:

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

  2. Click the Virtual Server Class tab.

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

    The Class Manger page appears.

  4. Choose the Content Mgmt tab.

  5. Select Stronger Ciphers.

  6. Choose to edit:

    • from the drop down list

    • by clicking Browse

    • by clicking Wildcard

  7. Select the secret key size restriction:

    • 168 bit or larger

    • 128 bit or larger

    • 56 bit or larger

    • No restrictions

  8. Enter the file location of the message to reject access.

  9. Click OK.

  10. Click Apply.

  11. Select hard start /restart or dynamically apply

For more information, see Introduction to SSL.



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.

So 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 Solid 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 Solid 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. (Mac passwords cannot be longer than 8 characters)

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

  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 Change Password link.

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

  4. Enter your current password.

  5. Enter your new password

  6. Enter it again.

  7. Click OK.

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

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 iPlanet Web Server under the alternative root directory, as shown in the following illustration:

Figure 5-2    Example of chroot Directory Structure


Specifying chroot for a Virtual Server Class

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

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

  2. Select the Virtual Server Class tab.

  3. Click the Edit Classes link.

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

  5. Click the Advanced button for that class.

    The Virtual Servers CGI Settings page appears.

  6. Enter the full pathname in the Chroot field.

  7. Click OK.

  8. Click Apply.

  9. Choose Load Configuration Files to dynamically apply.


Specifying chroot for a Virtual Server

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

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

  2. Select the Virtual Server Class tab.

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

  4. Select the Settings tab.

    The Settings page appears.

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

  6. Click OK.

  7. Click Apply.

  8. 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 Programmer's Guide for iPlanet Web Server.


Previous     Contents     Index          Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated May 09, 2002