Chapter 5 Working with Server Security

This chapter describes how to activate the Secure Sockets Layer (SSL) protocol and other features designed to safeguard your data, deny intruders access, and designate who has access to the server. iPlanet Web Server incorporates the security architecture of all Netscape/iPlanet servers: it's built on industry standards and public protocols for maximum interoperability and consistency.

• About iPlanet Web Server Security
• Creating a New Server Instance


• Creating a Certificate Trust Database


• Requesting a Certificate


• Installing and Managing Certificates and Certificate Lists


• Using Secure Sockets Layer (SSL)


• Using Client Certificates


• Changing the Trust Database/Key Pair File Password


• Migrating Enterprise Server 3.x Certificates


• Additional Server Security Considerations

• Encryption
• Certificates
• Configuring iPlanet Web Server for SSL

• use FORTEZZA ciphers for SSL connections
• use FORTEZZA card readers to store certificates and keys
• import and use FORTEZZA Compromised Key Lists (CKLs) and Certificate Revocation Lists (CRLs)
• serve files pre-encrypted with FORTEZZA ciphers

• FORTEZZA encryption standards. The FORTEZZA module allows the web server to use FORTEZZA encryption, authentication, and key validation.
• Secure Sockets Layer (SSL). FORTEZZA connections use SSL, version 3.
• The NSS libraries. Currently using NSS 2.72. The web server calls NSS functions which in turn, call the FORTEZZA library.
• The PKCS#11 web server infrastructure. FORTEZZA modules are added and configured using existing methods for managing PKCS#11 modules.
• NSAPI. The FORTEZZA module uses an NSAPI plugin to handle pre-encrypted files.
• Modutil: a utility for updating secmod.db, for adding and deleting PKCS#11 modules.

FIPS-140 Compliance
You can configure iPlanet Web Server to be Federal Information Processing Standards (FIPS)-140 compliant. To make your server FIPS-140 compliant, you need to turn on the following two ciphers in your encryption preferences:

• (FIPS) DES with 56 bit encryption and SHA-1 message authentication
• (FIPS) Triple DES with 168 bit encryption and SHA-1 message authentication

• The server matches the CA in the client certificate with a trusted CA listed in the Administration Server. This simply ensures that the client has a valid certificate from a CA the server trusts. (If the client is Netscape Navigator or Netscape Communicator and the certificate is expired, the client warns the user before sending the out-of-date certificate. Most Netscape/iPlanet servers will log an error, reject the certificate, and return a message to the client.)
• The server additionally gathers information from the client certificate and matches 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.

• Creating a New Server Instance
• Creating a Certificate Trust Database
• Requesting a Certificate
• Installing and Managing Certificates and Certificate Lists
• Using Secure Sockets Layer (SSL)

1. Access the Administration Server and choose the Servers tab.
2. Click the Add Server link.
3. Enter the desired information for the specified fields.
4. Click the radio button that corresponds to how you want the server to resolve IP addresses.
5. Click OK.

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

1. Access the Administration Server and choose the Security tab.
2. Type the password in Database Password.
3. Re-type the password in Password (again).
4. Click OK.

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

1. Access the Administration Server and choose the Security tab.
2. Click the Request Certificate link.
3. In the form that iPlanet Web Server displays, specify 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:

1. 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.
2. 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. From the drop-down list, select the cryptographic module for the key-pair file you want to use when requesting the certificate.

For information about installing additional cryptographic modules, see Adding a PKCS#11Module, or see The Install a New PKCS#11 Module Page.

6. Type the password for your key-pair file. This is the same password you specified when you created the trust database in Creating a Certificate Trust Database. 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. Type your identification information. The format of this information varies by CA. For a general description of these fields, see Required CA Information. 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.
9. Click OK once you've checked that the information is correct. If your request is going to a certificate server, you'll be prompted to verify the form information before the request is submitted. You should re-read the information and then click OK to submit the request to the certificate server.

• 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. It's important that these two names are the same, otherwise a client is notified that the certificate name doesn't match the site name, which will make people doubt the authenticity of your certificate. However, some CAs might require different information, so it's important to contact them. Note that you can not use wildcards in a 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.

• Installing Certificates
• Managing Certificates
• Managing Certificate Lists

• Your own server's certificate to present to clients.
• A CA's own certificate for use in a certificate chain.

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

1. Access the Administration Server and choose the Security tab.
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. If the certificate is for a chain, name the certificate. iPlanet Web Server displays this name in the Manage Certificates list. The name should be descriptive and can include spaces. For example, "United States Postal Service CA" is the name of the CA, and "VeriSign Class 2 Primary CA" describes both the CA and the type of certificate. If the certificate is for "this server," the Administration Server uses the name Server-Cert.
5. Either type the full pathname to the saved email or paste the email text in the field called Message text (with headers). If you copy and paste the text, be sure to include the headers "Begin Certificate" and "End Certificate"—including the beginning and ending hyphens. Make sure you check the corresponding radio button for either the file or the text.
6. Click OK.
7. Click Add.

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

https-<serverid>-<hostname>-cert7.db

For more information, see The Install a Server Certificate Page.

1. Access the Administration Server and choose the Security tab.
2. Click the Manage Certificates link.

iPlanet Web Server displays the Manage Server Certificates page.

3. Select a certificate file alias, and then click OK.

All of the installed certificates associated with the alias appear with their type and expiration date. The link text is the name given to the certificate when it was installed. The Administration Server comes with several default certificates, which are listed above the certificates you installed. all certificates are stored in the directory server_root/alias.

4. To view more information about a certificate, click the link for the certificate. A window appears, containing information about that certificate. Figure 5.1 shows a sample.

Figure 5.1    Certificate information includes the owner and who issued it.



5. To trust the CA, click Trust. If the CA is already trusted, you can click Do Not Trust. By default, all CAs are not trusted.

To delete the certificate, click the Delete Certificate button.

To close the window, click the Quit button.

• Obtaining a CRL or CKL
• Adding a CRL or CKL to the Trust Database
• Managing CRLs

1. Use a browser to go to the CA's website. Contact your CA administrator for the exact URL to use.
2. Follow the CA's instructions for downloading the CRL or CKL to a local directory.

1. Access the Administration Server and choose the Security tab.
2. Click the Install CRL/CKLs link.

iPlanet Web Server displays the Install a Certificate Revocation List page.

3. Click the File contains radio button for either Certificate Revocation List or Compromised Key List.
4. In The CRL/CKL is in this file field, type the full path name tothe associated file.
5. Click OK. If the list already exists in the database, the list you specify here will replace the existing list.

1. Access the Administration Server and choose the Security tab.
2. Click the Manage CRLs link.

iPlanet Web Server displays the Manage Certificate Revocation Lists page. All installed CRLs are listed along with their expiration dates.

3. Click on the desired CRL for more information and options.
4. Click a CRL to select it.
5. To add the CRL to the trust database, click Add.

• Activating SSL
• Specifying Ciphers
• Setting Security (SSL) Preferences
• Adding a PKCS#11Module
• Using SSL Configuration File Directives

https://<servername.[domain.[dom]]:[port#]>

For more information regarding specific ciphers, see Managing Servers with Netscape Console.

Setting Security (SSL) Preferences
You can set preferences for using SSL encryption on any server. To set the SSL preferences for iPlanet Web Server, perform the steps described in Setting Encryption Preferences.

$SERVER_ROOT/alias/https-$SERVERID-$HOSTNAME-key3.db

$SERVER_ROOT/alias/https-$SERVERID-$HOSTNAME-cert7.db

/usr/local/netscape

/usr/local/netscape/alias/https-secure.example.com- secure-key3.db

/usr/local/netscape/alias/https-secure.example.com- secure-cert7.db

CERTDefaultNickname $TOKENNAME:Server-Cert

1. Access the Administration Server and choose the Security tab.
2. Click the Add PKCS#11 Module link.
3. Type the path for the .jar file in Path to Jar File.
4. Click OK.

Using SSL Configuration File Directives
Installing an SSL-enabled server creates directive entries in the magnus.conf file (the server's main configuration file). These directives are briefly described in the following sections.

value specifies if SSL is on or off. Set the value parameter to on to enable SSL; and to off to disable SSL.

value specifies whether SSL version 2 is enabled or disabled. Set the value parameter to on to enable SSL 2 and to off to disable SSL 2. By default, security is off.

value specifies whether SSL version 3 is enabled or disabled. Set the value parameter to on to enable SSL 3, and to off to disable SSL 3. By default, security is off.

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

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

value specifies if certificates are always required. Set the value parameter to on to require certificates, and to off to specify that certificates are not required.

seconds is the number of seconds until a cached SSL2 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.

1. Maps the subject (user's) DN from the user's cert to a branch point in the LDAP directory.
2. Searches the LDAP directory for an entry that matches the information about the subject (end-user) of the client certificate.
3. Optionally verifies the client certificate with one in the LDAP entry that corresponds to the DN.

• 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

server_root/userdb/certmap.conf

certmap <name> <issuerDN>

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

certmap moz1 ou=Mozilla Certificate Authority,o=Netscape,c=US
certmap moz2 ou=Mozilla Certificate Authority, o=Netscape, c=US

• 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 uid 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 userid
e|mail	Email address

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

• verifycert tells the server whether it should compare the client's certificate with the certificate found in the LDAP directory. It takes two values: on, and off. You should only use this property if your LDAP directory contains certificates. This feature is useful to ensure your end-users have a valid, unrevoked certificate.
• CmapLdapAttr is a name for the attribute in the LDAP directory that contains subject DNs from all certificates belonging to the user. The default for this property is certSubjectDN. This attribute isn't a standard LDAP attribute, so to use this property, you have to extend the LDAP schema. For more information, see Managing Servers with Netscape Console.

If this property exists in the certmap.conf file, the server searches the entire LDAP directory for an entry whose attribute (named with this property) matches the subject's full DN (taken from the certificate). If the search doesn't find any entries, the server retries the search using the DNComps and FilterComps mappings.

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

• Library is a property whose value is a pathname to a shared library or DLL. You only need to use this property if you create your own properties using the certificate API. For more information, see the NSAPI Programmer's Guide for iPlanet Web.
• 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.

<name>:library <path_to_shared_library>
<name>:InitFn <name_of_init_function>

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

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

The following example file has two mappings: a default one 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

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

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

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

1. Access the Administration Server and choose the Security tab.
2. Click the Change Password link.
3. Type the required information and click OK.

• Limit Physical Access
• Limit Administration Access


• Choose Good Passwords


• Secure Your Key-Pair File


• Limit Other Applications on the Server


• Prevent Clients from Caching SSL Files


• Limit Ports


• Know Your Server's Limits


• Consider Additional Measures for Unprotected Servers

• 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 3's for E's and 1's for L's) within dictionary words.
• Include characters from as many of these classes as possible:

• Uppercase letters
• Lowercase letters


• Numbers


• Symbols

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.

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

• 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 and 80 for the unprotected one.
• For Unix/Linux, enable the chroot feature for the document root directory. The unprotected server should have references to its document root redirected using chroot.