Previous Contents Index Next |
iPlanet Directory Server Access Management Edition Installation and Configuration Guide |
Appendix B Securing Your Web Server
This appendix is excerpted from the iPlanet Web Server Administrator's Guide. For your convenience, Chapter 5 of the Guide is reproduced here in its entirety. To view the full online manual on the Internet, go to http://docs.iplanet.com/docs/manuals/enterprise.htmlThis 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.html
The process of securing your web server will be explained in detail in the following sections:
Requiring Authentication
Requesting and Installing a VeriSign Certificate
Requesting and Installing Other Server Certificates
Migrating Certificates When You Upgrade
Installing and Managing CRLs and CKLs
Using External Encryption Modules
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", on page 217.
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:
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.
- server_root/alias/<serverid-hostname>-key3.db
Creating a Trust Database
To create a trust database, perform the following steps:
Access either the Administration Server or the Server Manager and choose the Security tab.
Click on the Create Database link.
- For the Server Manager you must first select the server instance from the drop-down list.
Enter a password for the database.
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:
Make sure SSL is on.
You will always be prompted to supply a password when starting the web server, even after the password.conf file has been created.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:
Stop and restart your server for the new setting to take effect.
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:
- internal:your_password
- nFast:your_password
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:
Access either the Administration Server or the Server Manager and choose the Security tab.
Click the Request VeriSign Certificate link.
- For the Server Manager you must first select the server instance from the drop-down list.
Installing a VeriSign Certificate
If you request and receive approval for a VeriSign certificate, it should appear in the drop-down list of the Install VeriSign Certificate page in one to three days. To install a VeriSign Certificate, perform the following steps:
Access either the Administration Server or the Server Manager and choose the Security tab.
Click the Install VeriSign Certificate link.
- For the Server Manager you must first select the server instance from the drop-down list.
Choose internal (software) from the drop-down list for cryptographic module, unless you will use an external encryption module.
Enter your Key Pair File Password or PIN.
Select the Transaction ID to Retrieve from the drop-down list.
You will usually want the last one.
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.
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.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.
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:
Access either the Administration Server or the Server Manager and choose the Security tab.
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.
Click the Request a Certificate link.
- For the Server Manager you must first select the server instance from the drop-down list.
Select if this is a new certificate or a certificate renewal.
Perform the following steps to specify how you want to submit the request for the certificate:
- Many certificates expire after a set period of time, such as six months or a year. Some CAs will automatically send you a renewal.
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.
Select the cryptographic module for the key-pair file you want to use when requesting the certificate from the drop-down list.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.
Enter the password for your key-pair file.
Enter your identification information.
- 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.
Double-check your work to ensure accuracy.
- The format of this information varies by CA. For a general description of these fields, alist 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.
Click OK.
- 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.
For the Server Manager, click Apply, and then Restart for changes to take effect.
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.
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 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.
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:
Access either the Administration Server or the Server Manager and choose the Security tab.
The certificate is stored in the server's certificate database. The filename will be <alias>-cert7.db. For example:
Click the Install Certificate link.
- For the Server Manager you must first select the server instance from the drop-down list.
Check the type of certificate you are installing:
This Server is for a single certificate associated only with your server.
Select the Cryptographic Module from the drop-down list.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.
Enter the Key-Pair File Password.
Leave the a name for the certificate field blank if it will be the only one used for this server instance, unless:
Multiple certificates will be used for virtual servers
Enter a certificate name unique across all server instances within a single cryptographic moduleEnter a certificate name unique within the server instance
Cryptographic modules other than internal are used
Select either:
- 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.
Message is in this file and enter the full pathname to the saved email
Click OK.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.
For the Server Manager, click Apply, and then Restart for changes to take effect.
- 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:
From your local machine, access either the Administration Server or the Server Manager and choose the Security tab.
Choose:
- For the Server Manager you must first select the server instance from the drop-down list.
Migrate 3.X Certificates link from the Administration Server
Enter the 3.6 Server Root.Migrate Certificate link from the Server Manager.
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:
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:
Access either the Administration Server or the Server Manager and choose the Security tab.
Click the Manage Certificates link.
- For the Server Manager you must first select the server instance from the drop-down list.
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.
Click the Certificate Name you wish to manage.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.
- 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 B-1    Edit Server Certificate ![]()
In the Edit Server Certificate window you may select:
Certificate information includes the owner and who issued it.
Delete Certificate or Quit for certificates obtained internally
Click OK.Set client trust, Unset server trust, or Quit for CA certificates
For the Server Manager, click Apply, and then Restart for changes to take effect.
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:
Obtain the CA's URL for downloading CRLs or CKLs.
Enter the URL in your browser to access the site.
Follow the CA's instructions for downloading the CRL or CKL to a local directory.
Access either the Administration Server or the Server Manager and choose the Security tab.
Click the Install CRL/CKLs link.
- For the Server Manager you must first select the server instance from the drop-down list.
Enter the full path name to the associated file.
If you selected Certificate Revocation List, the Add Certificate Revocation List page will appear listing CRL information.
Click Add.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.
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:
Access either the Administration Server or the Server Manager and choose the Security tab.
Click the Manage CRL/CKLs link.
- For the Server Manager you must first select the server instance from the drop-down list.
Select a Certificate Name from either the Server CRLs or Server CKLs list.
- The Manage Certificate Revocation Lists /Compromised Key Lists page appears with all installed Server CRLs and CKLs listed along with their expiration dates.
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.
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.
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:
Access the Administration Server and choose the Global Settings tab.
Click the Configure Directory Service link.
Select Yes to use Secure Sockets Layer (SSL) for connections.
Click 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 Security On
You must turn security on before you can configure the other security settings for your connection group. You can turn security on when you create a new listen socket, or when you edit an existing listen socket.
Turning Security On When Creating a Listen Socket
To turn security on when creating a new listen socket, perform the following steps:
Access the Server Manager and select the server instance the listen socket will be created in from the drop-down list.
Select the Preferences tab, if not already displayed.
Choose the Add Listen Socket link.
Enter the required information and select a default virtual server.
- The Create a Listen Socket page is displayed.
Turn Security on using the drop-down list.
Click Apply, and then Restart for changes to take effect.
Note You will need to use the Edit Listen Sockets link to configure the security settings after a listen socket is created.
Turning Security On When Editing a Listen Socket
You can also turn security on when editing a listen socket from either the Administration Server or the Server Manager. To turn security on when editing a listen socket, perform the following steps:
Access either the Administration Server or the Server Manager and choose the Security tab.
Select the Preferences tab, if not already displayed.
- For the Server Manager you must first select the server instance from the drop-down list.
Choose the Edit Listen Sockets link.
Use the drop-down Action list to select Edit, if not already displayed, for the connection group you want to secure.
- The Listen Sockets Table page is displayed.
Use the drop-down list in the Security column to turn security on for the connection group.
For the Server Manager, click Apply, and then Restart for changes to take effect.
- The Attributes link will now be displayed in the Security column.
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:
Access either the Administration Server or the Server Manager and choose the Preferences tab.
Click the Edit Listen Sockets link.
- For the Server Manager you must first select the server instance from the drop-down list.
Use the drop-down Action list to select Edit, if not already displayed, for the connection group you are selecting a certificate for.
- The Listen Socket Table page appears.
Use the drop-down list to turn Security on for that connection group, if it is off.
Select a server certificate from the drop-down CertificateName list for the connection group.
- 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.
Click OK
- The list contains all internal and external certificates installed.
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:
Access either the Administration Server or the Server Manager and choose the Preferences tab.
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:
Click the Edit Listen Sockets link.
- For the Server Manager you must first select the server instance from the drop-down list.
Use the drop-down Action list to select Edit, if not already displayed, for the connection group you are enabling security for.
- The Listen Socket Table page appears.
Use the drop-down list to turn Security on for that connection group, if it is off.
Click the Attributes link.
- The Attributes link now appears.
Select either:
- 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.
(Optional) If you selected SSL2 or SSL3/TLS, in the Security Features window either:
Accept Allow and the default ciphers
Click OK to close the Security Features window.Accept Allow and check only desired ciphers, or uncheck unwanted ciphers
Uncheck Allow to disable this protocol and all its ciphers
For the Server Manager, click Apply, and then Restart for changes to take effect.
For example, https://admin.iplanet.com:443.
- https://servername.[domain.[dom]]:[port#]
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:
Access the Server Manager and select the server instance of the virtual server from the drop-down list.
These SSL Configuration File Directives are described below:Select the Preferences tab, if not already selected.
Choose the Edit Listen Sockets link.
Turn Security On for the listen socket you will set values for, if it isn't already on.
Select SSL Settings from the drop-down list and click Manage.
Click OK
SSLSessionTimeout
The SSLSessionTimeout directive controls SSL2 session caching.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.
- SSLSessionTimeout seconds
SSLCacheEntries
Specifies the number of SSL sessions that can be cached.
SSL3SessionTimeout
The SSL3SessionTimeout directive controls SSL3 and TLS session caching.
Syntax
SSL3SessionTimeout secondsseconds 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
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: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:
Make sure all servers, including the Administration server, are turned off.
Go to the server_root/alias directory containing the databases.
Add server_root/bin/https/admin/bin to your PATH.
Locate modutil in server_root/bin/https/admin/bin.
Set the environment. For example:
On Unix: setenv
Enter the command: modutil.LD_LIBRARY_PATH server_root/bin/https/lib:${LD_LIBRARY_PATH}
- LD_LIBRARY_PATH server_root/bin/https/bin
- You can find the PATH for your machine listed under: server_root/https-admin/start.
Perform the actions required.
- The options will be listed.
- 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:
Go to the server_root/alias directory containing the databases.
Add server_root/bin/https/admin/bin to your PATH.
Locate pk12util in server_root/bin/https/admin/bin.
Set the environment. For example:
On Unix: setenv
Enter the command: pk12util.LD_LIBRARY_PATH/server_root/bin/https/lib:${LD_LIBRARY_PATH}
- LD_LIBRARY_PATH server_root/bin/https/bin
- You can find the PATH for your machine listed under: server_root/https-admin/start.
Perform the actions required.
- The options will be listed.
Enter the database password.
- For example, in Unix you would enter:
- pk12util -o certpk12 -n Server-Cert [-d /server/alias] [-P https-test-host]
Importing with pk12util
To import a certificate and key into an internal or external PKCS#11 module, perform the following steps:
Go to the server_root/alias directory containing the databases.
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.Add server_root/bin/https/admin/bin to your PATH.
Locate pk12util in server_root/bin/https/admin/bin.
Set the environment. For example:
On Unix: setenv
Enter the command: pk12util.LD_LIBRARY_PATH/server_root/bin/https/lib:${LD_LIBRARY_PATH}
- LD_LIBRARY_PATH server_root/bin/https/bin
- You can find the PATH for your machine listed under: server_root/https-admin/start.
Perform the actions required.
- The options will be listed.
Enter the database password.
- 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.
Enter pkcs12 password.Starting the Server with an External Certificate
The server always tries to start with the certificate named "Server-Cert." However, certificates in external PKCS#11 modules include one of the module's token names in their identifier. For example, a server certificate installed on an external smartcard reader called "smartcard0" would be named "smartcard0:Server-Cert."
To start a server with a certificate installed in an external module, you'll need to specify the certificate name for the connection group it runs on.
Selecting the Certificate Name for a Connection Group
To select the certificate name for the connection group, perform the following steps:
Access either the Administration Server or the Server Manager and choose the Preferences tab.
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:
Select the Preferences tab, if not already selected.
- For the Server Manager you must first select the server instance from the drop-down list.
Click the Edit Listen Sockets link.
Use the drop-down Action list to select Edit, if not already displayed, for the connection group you are enabling security for.
- The Listen Socket Table page appears.
Use the drop-down list to turn Security on for that connection group, if it is off.
Click the Attributes link.
- The Attributes link now appears.
Use the drop-down CertificateName list to select the external server certificate.
- The Security Settings of Listen Socket page appears.
For the Server Manager, click Apply, and then Restart for changes to take effect.
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.
- $TOKENNAME:Server-Cert
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:
Install the plug-in following the FIPS-140 instructions.
Access either the Administration Server or the Server Manager and choose the Preferences tab.
Click the Edit Listen Sockets link.
- For the Server Manager you must first select the server instance from the drop-down list.
Use the drop-down Action list to select Edit, if not already displayed, for the connection group you are enabling FIPS-140 on.
- The Listen Socket Table page appears.
Use the drop-down list to turn Security on for that connection group, if it is off.
Click the Attributes link.
- The Attributes link now appears.
The Security Settings of Listen Socket page appears.
Check Allow: SSL version 3, if it is not already checked.
- The Security Feature window appears.
Select the appropriate FIPS-140 cipher suite:
(FIPS) DES with 56 bit encryption and SHA message authentication
Click OK to close the Security Features window.(FIPS) Triple DES with 168 bit encryption and SHA message authentication
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)
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 .Trusted Server CA (will not be matched)
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" on page 281.
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 .
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:
Access either the Administration Server or the Server Manager and choose the Preferences tab.
Click the Edit Listen Sockets link.
- For the Server Manager you must first select the server instance from the drop-down list.
Use the drop-down Action list to select Edit, if not already displayed, for the connection group you are requiring client authentication for.
- The Listen Socket Table page appears.
Use the drop-down list to turn Security on for that connection group, if it is off.
Click Off for Client Auth to turn it on.
- The Security Settings of Listen Socket page appears.
For the Server Manager, click Apply, and then Restart for changes to take effect.
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
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.
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.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.
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 .
Table B-1    LDAP Search Results
LDAP Search Result
Certificate Verification ON
Certificate Verification OFF
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
The certificate mapping file is located in the following location: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 file contains one or more named mappings, each applying to a different CA. A mapping has the following syntax:
- server_root/userdb/certmap.conf
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 <name> <issuerDN>
- <name>:<property> [<value>]
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.
For more information on these properties, refer to the examples described in "Sample Mappings," on page 212.
- 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).
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.If the DNComps entry is present but has no value, the server searches the entire LDAP tree for entries matching the filter.
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.
- 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 B-2    Attributes for x509v3 Certificates
Attribute
Description
- 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.
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.
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.
- 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.
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.
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>
- 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:
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.
- certmap default default
default:DNComps ou, o, c
default:FilterComps e, uid
default:verifycert on
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:
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.
- 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
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.
If the client certificate subject is:
- certmap myco ou=My Company Inc, o=myco, c=US
myco:CmapLdapAttr certSubjectDN
myco:DNComps o, c
myco:FilterComps mail, uid
myco:verifycert on
the server first searches for entries that contain the following information:
- 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.
- certSubjectDN=uid=Walt Whitman, 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:
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 fn="ssl-check" [secret-keysize=<nbits>] [bong-file=<filename>]
PathCheck returns REQ_NOACTION if SSL is not enabled, or if the secret-keysize parameter is not specified. If the secret key size for the current session is less than the specified secret-keysize, the function returns REQ_ABORTED with a status of PROTOCOL_FORBIDDEN if bong-file is not specified, or else REQ_PROCEED, and the "path" variable is set to the bong-file <filename>. Also, when a key size restriction is not met, the SSL session cache entry for the current session is invalidated, so that a full SSL handshake will occur the next time the same client connects to the server.
Note The Stronger Ciphers form removes any Service fn=key-toosmall directives that it finds in an object when it adds a PathCheck fn=ssl-check.
To Set Stronger Ciphers, perform the following steps:
Access the Server Manager and select the server instance from the drop-down list.
For more information, see Introduction to SSL.Click the Virtual Server Class tab.
Select a class from the drop-down list and click Manage.
The Class Manger page appears.
Select the secret key size restriction:
Enter the file location of the message to reject access.
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
Limiting Other Applications on the Server
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 .
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:
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," on page 217.
Changing Passwords
To change your trust database/key-pair file password for the Administration Server or an server instance, perform the following steps:
Access either the Administration Server or the Server Manager and choose the Security tab.
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.
Select the Change Password link.
- For the Server Manager you must first select the server instance from the drop-down list.
Select the security token on which you want to change the password from the drop-down list.
Enter your current password.
- 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.
For the Server Manager, click Apply, and then Restart for changes to take effect
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:
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.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.
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 B-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:
Access the Server Manager and select the server instance from the drop-down list.
Select the Virtual Server Class tab.
Make sure the Option is set to Edit for the class in which you wish to specify chroot.
Click the Advanced button for that class.
Enter the full pathname in the Chroot field.
Specifying chroot for a Virtual Server
You can specify the chroot directory for a specific virtual server by performing the following steps:
Access the Server Manager and select the server instance from the drop-down list.
You can also specify the chroot directory for a virtual server using the Class Manager Virtual Servers tab and the CGI Settings link.Select the Virtual Server Class tab.
Click on the link for the virtual server you wish to specify the chroot directory for from the Tree View of the Server.
Enter the full pathname in the Set to field next to Chroot Directory.
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 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated May 13, 2002