test

Sun Java System Web Server 6.1 SP12 Administrator's Guide

Chapter 6 Using Certificates and Keys

This chapter describes how to perform authentication using certificates and keys to secure the Sun Java System Web Server 6.1. This chapter describes how to activate the various security features designed to safeguard your data, deny access to intrudes, and allow access to those you want. Sun Java System Web Server 6.1 incorporates the security architecture of all Sun Java System servers: it is built in adherence with 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.

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

Certificate-based 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 verifies 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 (CA). The CA can either be a company that sells certificates over the Internet, or a department responsible for issuing certificates for your company’s intranet or extranet. You decide which CAs to trust 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. The process involves identifying the organization is responsible for the server at a specific network address.

Client Authentication

Client authentication refers to the confident identification of a client by a server. The process involves identifying the person using the client software. Clients can have multiple certificates, much like a person might have several different kind of identification.

Virtual Server Certificates

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

Creating a Trust Database

Before requesting a server certificate, you must create a trust database. In the Sun Java System 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 is used for a key-pair file. You also need this password to start a server using encrypted communications. For a list of guidelines to follow when changing a password, see Changing Passwords or PINs.

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

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

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

ProcedureTo create a trust database

To create a trust database, perform the following steps:

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

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

  2. Click Create Database link.

  3. Enter a password for the database.

  4. Repeat.

  5. Click OK.

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

Using password.conf

By default, the web server prompts the administrator for the key database password before starting. 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 store the password in plain-text format 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, allowing only the owner to have read and write access to the file.

On UNIX platform, 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.

If you have an NTFS file system on a windows, 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 and the web server users. 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.

ProcedureTo start an SSL-enabled server automatically

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

  1. Make sure SSL is activated.

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

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

      internal:your_password

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

        nFast:your_password

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

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

Requesting and Installing a VeriSign Certificate

VeriSign is the Sun Java System Web Server’s preferred certificate authority. VeriSign’s VICE protocol simplifies the certificate request process. VeriSign has the capability 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.

ProcedureTo request a VeriSign certificate

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

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

  2. Click the Request VeriSign Certificate link.

  3. Review the steps required.

  4. Click OK.

  5. Follow the VeriSign procedure.

ProcedureTo install a VeriSign certificate

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

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

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

  2. Click the Install VeriSign Certificate link.

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

  4. Enter your Key Pair File Password or PIN.

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

    You will usually want the last one.

  6. Click OK.

  7. For the Server Manager, click Apply.

  8. Restart the server 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 organization might provide its own internal certificates. This section describes how you would request and install 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 request a server certificate from a commercial CA or an internal CA, you must provide the following information:

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

If you purchase your certificate from a commercial CA, contact the CA to find out if any additional information is required before a certificate is issued. Most CAs require proof of your identity. For example, to verify your company name and the person authorized to administer the server by the company, they might investigate your legal right to use information you provided.

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.sun.com computer, but that you are a company that has been in business for three years, and have no outstanding customer litigation.

ProcedureTo request other server certificates

To request a certificate, perform the following steps:

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

    From the Server Manager first select the server instance from the drop-down list.

  2. Click the Request a Certificate link.

  3. Select if this is a new certificate or a certificate renewal.

    Many certificates expire after a set period of time, such as six months or a year. Some CAs will automatically send you a renewal.

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

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

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

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

  6. Enter the password for your key-pair file.

    This is the password you specified when you created the trust database, unless you selected a cryptographic module other than the internal module. The server uses the password to get your private key and encrypt a message to the CA. The server then sends both your public key and the encrypted message to the CA. The CA uses the public key to decrypt your message.

  7. Enter your identification information.

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

  8. Double-check your work to ensure accuracy.

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

  9. Click OK.

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

    The server generates a certificate request that contains your information. The request has a digital signature created with your private key. The CA uses a digital signature to verify that the request wasn’t tampered with during routing from your server machine to the CA. In the rare event that the request is tampered with, the CA will usually contact you by phone.

    If you choose to email the request, the server composes an email message containing the request and sends the message to the CA. Typically, the certificate is then returned to you via email. If instead you specified a URL to a certificate server, your server uses the URL to submit the request to the Certificate Server. You might get a response via email or other means depending on the CA.

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

    Note –

    Not all requests for a certificate from a commercial CA are granted. Many CAs require proof of identity before issuing a certificate. Also, it can take anywhere from one day to two months to get approval. You are responsible for promptly providing all the necessary information to the CA.

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

Installing Other Server Certificates

When your certificate is returned from the CA, it is encrypted with your public key so that only you can decrypt it. You can decrypt your certificate and install it by entering the correct password for your trust database.

There are three types of certificates:

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, up to a root CA.

Note –

If your CA does not automatically send you their certificate, request them to send it. Many CAs include their certificate in the email with your certificate, and your server installs both certificates at the same time.

When you receive a certificate from the CA, it is 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:

ProcedureTo install a certificate

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

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

  2. Click the Install Certificate link.

  3. Check the type of certificate you are installing:

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

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

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

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

  5. Enter the Key-Pair File Password.

  6. Leave the certificate name field blank if it will be the only one used for this server instance, unless the following conditions are satisfied:

    • Multiple certificates will be used for virtual servers

      Enter a certificate name unique within the server instance

      • Cryptographic modules other than internal are used

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

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

  7. Select either:

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

    • Message text (with headers) and paste the email text

      If you copy and paste the text, make sure you include the headers “Begin Certificate” and “End Certificate”—including the beginning and ending hyphens.

  8. Click OK.

  9. Select either:

    • Add Certificate if you are installing a new certificate.

    • Replace Certificate if you are installing a certificate renewal.

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

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

    https-serverid-hostname-cert8.db

Migrating Certificates When You Upgrade

If you are migrating from the iPlanet Web Server 4.1 or 6.0, all your files, including your trust and certificate databases, are updated automatically.

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

In previous versions, the 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 the Sun Java System Web Server 6.1, the Administration Server and each server instance have their own certificate and key-pair files, referred to as the trust database instead of an alias.

You manage the trust database and its constituent certificates, including the server certificate and other 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.In the previous version, if 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 Sun Java System Web Server 6.1 database. If duplicate CAs occur, use the previous CA until it expires.

Caution – Caution –

Do not attempt to delete duplicate CAs.

Using the Built-in Root Certificate Module

The dynamically loadable root certificate module included with the Sun Java System Web Server 6.1 contains the root certificates for many CAs, including VeriSign. The root certificate module enables you to upgrade your root certificates 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 the Sun Java System Web Server, or in Service Packs.

Because the root certificate is implemented as a PKCS#11 cryptographic module, you can not delete the root certificates it contains, so the option to delete is not available when managing these certificates. To remove the root certificates from your server instances, you can disable the root certificate module by deleting the following entries 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 (Windows) 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, edit or delete, 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

ProcedureTo manage certificate lists

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

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

  2. Click the Manage Certificates link.

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

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

  3. Click the Certificate Name you wish to manage.

    An Edit Server Certificate page appears with management options for chosen certificate. Only CA certificates allow you to set or unset client trust. Some external cryptographic modules do not allow deletion of certificates.

    Figure 6–1 Edit Server Certificate

    Edit Server Certificate

  4. In the Edit Server Certificate window you may select:

    • Delete Certificate or Quit for certificates obtained internally

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

  5. Click OK.

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

    Certificate information lists the owner and the person who issued the certificate.

    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) expose any certificates and keys that 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 the data appears in a CRL. If a key is tampered with or otherwise compromised, the key and its data appear in a CKL. CRLs and CKLs are produced and periodically updated by a CA.

ProcedureTo install a CRL or CKL

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

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

  2. Enter the URL in your browser window.

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

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

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

  5. Click the Install CRL/CKLs link.

  6. Select either:

    • Certificate Revocation List

      or

    • Compromised Key List

  7. Enter the path name of the associated file.

  8. Click OK.

    • If you selected Certificate Revocation List, the Add Certificate Revocation List page appears listing CRL information.

    • If you selected Compromised Key List, the Add Compromised Key List page appears listing CKL information.

    Note –

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

  9. Click Add.

  10. Click OK.

  11. For the Server Manager, click Apply.

  12. Restart for changes to take effect.

Managing CRLs and CKLs

To manage CRLs and CKLs, perform the following steps

ProcedureTo manage CRls and CKls

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

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

  2. Click the Manage CRL/CKLs link.

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

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

  4. Choose:

    • Delete CRL

    • Delete CKL

  5. For the Server Manager, click Apply.

  6. 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 Sun Java System 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. The Sun Java System Web Server 6.1 supports SSL and TLS encryption protocols.

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

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

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

Note –

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

The encryption process alone is not 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 a 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 enable ciphers with less than optimal encryption.

Caution – Caution –

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

SSL and TLS Protocols

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

SSL and TLS protocols support a variety of ciphers used to authenticate the server and client to each other, transmit certificates, and establish session keys. Clients and servers can 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.

Procedure To Communicate with LDAP Using SSL

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

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

  2. Click the Configure Directory Service link.

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

  4. Click Save Changes.

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

Enabling Security for Listen Sockets

You can secure your server’s listen sockets by:

Turning Security On

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

ProcedureTo Turn Security On When Creating a Listen Socket

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

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

  2. Select the Preferences tab.

  3. Choose the Edit Listen Sockets link.

    The Edit Listen Sockets page is displayed.

  4. Click the New button.

    The Add Listen Socket page is displayed.

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

  6. To turn security on, select Enabled from the Security drop-down list.

  7. Click OK

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

    Note –

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

ProcedureTo Turn Security On When Editing a Listen Socket

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

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

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

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

  3. Choose the Edit Listen Sockets link.

    The Edit Listen Sockets page displays.

  4. To edit a listen socket, click the Listen Socket ID of the listen socket you want to edit.

    The Edit Listen Socket page displays.

  5. To turn security on for the listen socket, select Enabled from the Security drop-down list.

  6. Click OK.

  7. For the Server Manager, click Apply.

  8. Restart for changes to take effect.

ProcedureTo Select a Server Certificate for a Listen Socket

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

Note –

You must have at least one certificate installed.

To select a server certificate for your listen socket to use, perform the following steps:

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

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

  2. Choose the Edit Listen Sockets link.

    The Edit Listen Sockets page is displayed.

  3. To edit a listen socket, click the Listen Socket ID of the listen socket you want to edit.

    The Edit Listen Socket page is displayed.

  4. To turn security on for the listen socket, select Enabled from the Security drop-down list.

    Note –

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

  5. Select a server certificate from the drop-down Server Certificate Name list for the listen socket.

    The list contains all internal and external certificates installed.

    Note –

    If no server certificates are installed, a warning message is displayed in place of the Server Certificate Name drop-down list.

  6. Click OK

  7. For the Server Manager, click Apply.

  8. Restart for changes to take effect.

ProcedureTo select ciphers

To protect the security of your web server, enable SSL. 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 listen socket for the Administration Server. Enabling SSL and TLS on a listen socket for the Server Manager will set the security preferences for all virtual servers associated with that listen socket.

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

The default settings allow the most commonly used ciphers. You should allow them all unless you have a specific reason,why you do not want to use a particular cipher suite. For more information regarding specific ciphers, see Introduction to SSL.

Note –

You must have at least one certificate installed.

The default and recommended setting for the tlsrollback parameter is true. This configures the server to detect man-in-the-middle version rollback attack attempts. Setting this value to false might be required for interoperability with some clients that incorrectly implement the TLS specification.

If you set the tlsrollback parameter to false, the connections becomes vulnerable to version rollback attacks. Version rollback attacks are a mechanism by which a Third parties can force a client and server to communicate using an older, less secure protocol such as SSLv2. Because there are known deficiencies in the SSLv2 protocol, failing to detect version rollback attack attempts makes it easier for a third party to intercept and decrypt encrypted connections.

To enable SSL and TLS, perform the following steps:

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

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

  2. Click the Edit Listen Sockets link.

    The Edit Listen Sockets page appears. For a secure listen socket, the Edit Listen Socket page displays the available cipher settings.

    Note –

    If Security is not enabled on the listen socket, no SSL and TLS information is listed. To work with ciphers, ensure that security is enabled on the selected listen socket. For more information, see Enabling Security for Listen Sockets.

  3. Select the checkboxes corresponding to the required encryption settings.

    Note –

    Select both TLS and SSL3 for Netscape Navigator 6.0. For TLS Rollback also select TLS, and make sure both SSL3 and SSL2 are disabled.

  4. Click OK.

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

    Note –

    When you apply changes after turning on security for a listen socket, the magnus.conf file is automatically shows the newly activated security feature, and all virtual servers associated with the listen socket are automatically assigned the default security parameters.

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

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

    For example, https://admin.sun.com:443.

    If you use the default secure http port number (443), you don’t have to enter the port number in the URL.

Configuring Security Globally

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

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

ProcedureTo set values for your SSL configuration file directives

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

  2. Ensure that security is enabled for the listen socket you want to configure. To enable security, perform the following steps:

    1. Click the Edit Listen Sockets link.

    2. Click the Listen Socket ID corresponding to the listen socket on which you want to enable security.

      This takes you to the Edit Listen Socket page.

    3. Select Enabled from the Security drop-down list.

    4. Click OK.

  3. Click the Magnus Editor link.

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

  5. Enter the values for:

    • SSLSessionTimeout

      • SSLCacheEntries

      • SSL3SessionTimeout

  6. Click OK

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

    These SSL Configuration File Directives are described below:

SSLSessionTimeout

The SSLSessionTimeout directive controls SSL2 session caching.

Syntax

SSLSessionTimeout seconds

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

SSLCacheEntries

Specifies the number of SSL sessions that can be cached.

SSL3SessionTimeout

The SSL3SessionTimeout directive controls SSL3 and TLS session caching.

Syntax

SSL3SessionTimeout seconds

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

Using External Encryption Modules

The Sun Java System Web Server 6.1 supports the following methods when using external cryptographic modules such as smart cards or token rings:

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

Installing the PKCS#11Module

The Sun Java System 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.

Procedure To Install a PKCS#11 Module using the modutil

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

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

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

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

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

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

  5. Set the environment. For example:

    • On UNIX: setenv

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

      • On IBM-AIX: LIBPATH

      • On HP-UX: SHLIB_PATH

      • On Windows, add it to the PATH

        LD_LIBRARY_PATH server_root/bin/https/bin

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

  6. Enter the modutil command.

    The options are listed.

  7. Perform the required actions required.

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

    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 import them into an internal or external PKCS#11 module. You can export certificates and keys to your internal database, but many external tokens do not let you export certificates and keys. By default, the pk12util uses the cert8.db and key3.db certificate and key databases.

Exporting with pk12util

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

ProcedureTo export a certificate and key from an internal database

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

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

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

  4. Set the environment. For example:

    • On UNIX: setenv

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

      • On IBM-AIX: LIBPATH

      • On HP-UX: SHLIB_PATH

      • On Windows, add it to the PATH

        LD_LIBRARY_PATH server_root/bin/https/bin

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

  5. Enter the pk12util command.

    The options are listed.

  6. Perform required actions.

    For example, in UNIX enter:

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

  7. Enter the database password.

  8. Enter the pkcs12 command password.

Importing with pk12util

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

ProcedureTo import a certificate and key into an internal PKCS#11 module

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

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

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

  4. Set the environment. For example:

    • On UNIX, use the setenv command

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

      • On IBM-AIX, use the LIBPATH command

      • On HP-UX, use the SHLIB_PATH command

      • On Windows, add it to the PATH

        LD_LIBRARY_PATH server_root/bin/https/bin

        The PATH for your machine is listed under the server_root/https-admin/start.

  5. Enter pk12util command.

    The options are listed.

  6. Perform required actions.

    For example, in UNIX enter:

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

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

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

  7. Enter the database password.

  8. Enter the pkcs12 command password. Starting the Server with an External Certificate

    If you install a certificate into an external PKCS#11 module (for example, a hardware accelerator), the server is unable to start using the certificate until you edit the server.xml file, or specify the certificate name.

    The server always tries to start with the “Server-Cert” certificate. Certificates in external PKCS#11 modules contains 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 need to specify the certificate name for the listen socket it runs on.

Selecting the Certificate Name for a Listen Socket

To select the certificate name for the listen socket, perform the following steps:

Note –

If Security is not enabled on the listen socket, certificate information is not listed. To select a certificate name for a listen socket, ensure that security is enabled. For more information, see Enabling Security for Listen Sockets.

ProcedureTo select the certificate name for the listen socket

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

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

  2. Select the Preferences tab.

  3. Click the Edit Listen Sockets link.

    The Edit Listen Sockets page appears.

  4. Click the Listen Socket Id link corresponding to the listen socket that you want to associate with a certificate.

    The Edit Listen Socket page appears.

  5. Select a server certificate from the drop-down Server Certificate Name list for the listen socket.

    The list contains all internal and external certificates installed.

    Note –

    If no server certificates are installed, a warning to this effect is displayed in place of the Server Certificate Name drop-down list.

  6. Click OK

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

    You could also tell the server to start with that server certificate by manually editing the server.xml file. Change the servercertnickname attribute in the SSLPARAMS to:

    $TOKENNAME:Server-Cert

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

    Note –

    If you have not created a trust database, it is created for you when you request or install a certificate for an external PKCS#11 module. The default database that is created has no password and cannot be accessed. Although your external module works, you cannot request and install server certificates. If a default database has been created without a password, use the Security Tab Create Database page to set a password.

FIPS-140 Standard

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

ProcedureTo enable FIPs-140

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

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

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

  3. Click the Edit Listen Sockets link.

    The Edit Listen Sockets page appears. For a secure listen socket, the Edit Listen Socket page displays the available security settings.

    Note –

    To work with FIPS-140, ensure that security is enabled on the selected listen socket. For more information, see Enabling Security for Listen Sockets.

  4. Select Enabled from the SSL Version 3 drop-down list.

  5. Check the appropriate FIPS-140 cipher suite:

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

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

  6. Click OK.

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

Setting Client Security Requirements

After you have completed the process to secure your servers, you can set additional security requirements for your clients.

Requiring Client Authentication

You can enable the listen sockets 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 sends a response to a query.

The Sun Java System 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 the Manage Certificates page under Security in the Administration Server. There are four types of CAs:

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

The Sun Java System Web Server logs an error, rejects the certificate, and returns a message to the client if the certificate has expired. You can view a list of certificates that have expired in the Administration Servers Manage Certificates page.

You can configure your server to collect 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, and also ensure that the client certificate matches the one in the LDAP directory. To learn how to do this, see Mapping Client Certificates to LDAP.

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

You can also process information from client certificates. For more information, see the Sun Java System Web Server 6.1 SP12 NSAPI Programmer’s Guide.

To Require Client Authentication

To require client authentication, perform the following steps:

ProcedureTo require client authentication

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

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

  2. Click the Edit Listen Sockets link.

    The Edit Listen Sockets page appears.

  3. Click the Listen Socket Id link corresponding to the listen socket you are requiring client authentication for.

    The Edit Listen Socket page appears.

  4. To require client authenticate for the listen socket, select Required from the Client Authentication drop-down list.

  5. Click OK.

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

    Note –

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

Mapping Client Certificates to LDAP

This section describes the process followed by the Sun Java System Web Server 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 need to set up the required ACLs. For more information, see Chapter 10, Controlling Access to Your Server.

The server tries to match the CA to the list of trusted CAs in the Administration Server. If there is no match, the Sun Java System Web Server terminates the connection. If a match occurs, the server continues processing the request.

After verifying that the certificate is from a trusted CA, the server maps the certificate to an LDAP entry using the following methods:

The server uses a certificate mapping file called the certmap.conffile to determine how to do conduct LDAP search. The mapping file provides the server with values to get from the client certificate (such as the end-user’s name and email address). The server uses these values to search for a user entry in the LDAP directory. First the server needs to determine where in the LDAP directory it needs to start its search. The certificate mapping file also tells the server where to start.

Once the server knows where to start its search and what it needs to search for (step 1), it performs the search in the LDAP directory (step 2). If it finds no matching entry or more than one matching entry, and the mapping is not set to verify the certificate, the search fails. For a complete list of the expected search result behavior, see the following Table 6-1. Note that you can specify the expected behavior in an ACL. For example, you can specify that Sun Java System Web Server accepts only you if the certificate match fails. For more information regarding how to set ACL preferences, see Using Access Control Files.

Table 6–1 LDAP Search Results

LDAP Search Result  

Certificate Verification ON  

Certificate Verification OFF  

No entry found 

Authentication fails 

Authentication fails 

Exactly one entry found 

Authentication fails 

Authentication succeeds 

More than one entry found 

Authentication fails 

Authorization fails 

After the server finds a matching entry and certificate in the LDAP directory, it can use that information to process the transaction. For example, some servers use certificate-to-LDAP mapping to determine access to another server.

Using the certmap.conf File

Certificate mapping determines how a server scans user entry in the LDAP directory. You can use the 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 structure 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:

The certificate mapping file is located in the following location:

server_root/userdb/certmap.conf

The file contains one or more named mappings, each applying to a different CA. A mapping has the following syntax:

certmap <name> <issuerDN>

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

The first line specifies a name for the entry and the attributes that form the distinguished name found in the CA certificate. You can select any name for the entry. However, the issuerDN must exactly match the issuer DN of the CA that issued the client certificate. For example, the following two issuerDN lines have different space separating the attributes, but the server treats these as two separate entries 

certmap sun1 ou=Sun Certificate Authority,o=Sun, c=US
      certmap sun2 ou=Sun Certificate Authority, o=Sun, c=US
Note –

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

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

Table 6–2 Attributes for x509v3 Certificates

Attribute  

Description  

c

Country 

o

Organization 

cn

Common name 

l

Location 

st

State 

ou

Organizational unit 

uid

UNIX/Linux userid 

email

Email address 

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

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

Creating Custom Properties

You can use the client certificate API to create your own properties. For information on programming and using the client certificate API, see the Sun Java System Web Server 6.1 SP12 NSAPI Programmer’s Guide.

Once you have a custom mapping, you reference the mapping as follows:

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

For example:

certmap default1 o=Sun Microsystems, c=US default1:library /usr/sun/userdb/plugin.so default1:InitFn plugin_init_fn default1:DNComps ou o c default1:FilterComps l default1:verifycert on

Sample Mappings

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

Example #1

This example represents a certmap.conf file with only one “default” mapping:

certmap default defaultdefault:DNComps ou, o, cdefault:FilterComps e, uiddefault:verifycert on

Using this example, the server starts its search at the LDAP branch point containing the entry ou=<orgunit>, o=<org>, c=<country> where the text within <> is replaced with the values from the subject’s DN in the client certificate.

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

Example #2

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

certmap default defaultdefault:DNCompsdefault:FilterComps e, uid

certmap usps ou=United States Postal Service, o=usps, c=USusps:DNComps ou,o,cusps:FilterComps eusps:verifycert on

When the server gets a certificate from someone other than the USPS , it uses the default mapping, which starts at the top of the LDAP tree and searches for an entry matching the client’s userid and email address. If the certificate is from the USPS, the server starts its search at the LDAP branch containing the organizational unit and searches for matching email addresses. Note that if the certificate is from the USPS, the server verifies the certificate; other certificates are not verified.

Caution – Caution –

The issuer DN (that is, the CA’s information) in the certificate must be identical to the issuer DN listed in the first line of the mapping. In the previous example, a certificate from an issuer DN that is o=United States Postal Service,c=US will not match because there is not a space between the o and the c attributes.

Example #3

The following example uses the CmapLdapAttr property to scan the LDAP database for the certSubjectDN attribute whose value exactly matches the entire subject DN taken from the client certificate.

certmap myco ou=My Company Inc, o=myco, c=USmyco:CmapLdapAttr certSubjectDNmyco:DNComps o, c myco:FilterComps mail, uid myco:verifycert on

If the client certificate subject is:

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

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

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

If one or more matching entries are found, the server proceeds to verify the entries. If no matching entries are found, the server will use DNComps and FilterComps to search for matching entries. In this example, the server would search for uid=Walt Whitman in all entries under o=LeavesOfGrass Inc, c=US.

Note –

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

Setting Stronger Ciphers

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

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

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

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

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

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

Note –

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

To Set Stronger Ciphers, perform the following steps:

ProcedureTo set stronger ciphers

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

  2. Click the Virtual Server Class tab.

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

    The Class Manager page appears.

  4. Choose the Content Mgmt tab.

  5. Select Stronger Ciphers.

  6. Choose to edit:

    • from the drop down list

      • by clicking Browse

      • by clicking Wildcard

  7. Select the secret key size restriction:

    • 168 bit or larger

      • 128 bit or larger

      • 56 bit or larger

      • No restrictions

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

  9. Click OK.

  10. Click Apply.

  11. Select hard start /restart or dynamically apply

    For more information, see Introduction to SSL.

Considering Additional Security Issues

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

In addition to enabling encryption on your server, take extra security precautions. For example, put the server machine into a secure room, and do not allow unauthorized individuals to upload programs to your server.

The following sections describe some important tasks you can perform to make your server more secure:

Limit Physical Access

Keep the server machine in a locked room that only authorized people can access. This step prevents the possibility of hacking the server machine.

Protect your machine’s administrative (root) password.

Limit Administration Access

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

For more information regarding clusters, see About Clusters.

You should also turn on encryption for the Administration Server. If you do not use an SSL connection for administration, then 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 many passwords with your servers the administrative password, the private key password and database passwords. Your administrative password is the most important passwords since anyone with that password can configure the servers on your computer. Your private key password is also important. If someone obtains your private key and your private key password, they can create a unauthorized server that appears to be yours, or intercept and change communications to and from your server.

A good password is one you can remember but others cannot 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

You can follow guidelines to create a secure password.

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

Changing Passwords or PINs

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

Change this password only from your local machine. For a list of guidelines follow when changing a password, see Creating Hard-to-Crack Passwords.

ProcedureTo change passwords

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

  1. Access either the Administration Server or the Server Manager.

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

  2. Select the Change Password link.

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

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

  4. Enter the current password.

  5. Enter the new password.

  6. Renter the new password.

  7. Click OK.

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

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

    It is also important find out if the file is stored on backup tapes or is otherwise available for someone to intercept. If as, 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 is possible to circumvent your server’s security by exploiting holes in other programs running on your server. Disable 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 the inittab and rc scripts. Do not run the telnet or rlogin from the server machine. You also should not have the rdist on the server machine (this can distribute files but it can also be used to update files on the server machine).

Windows

Carefully consider the drives and directories that are share with other machines. Also, consider the users who have Guest privileges.

Be careful about programs you upload on your server, or those that other people install on your server. Other people’s programs might have security gaps. Someone could 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 in the <HEAD> section of a file in HTML:

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

Limiting Ports

Disable ports not in use on the machine. Use routers or firewall configurations to prevent incoming connections to anything other than the minimum number 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 itself and the client. It can not control the security of information once information is transferred to the client has it, nor can it control access to itself and its directories and files.

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 need to have both protected and unprotected servers, you should operate the unprotected server on a different machine from the protected one. If resources are limited and you must run an unprotected server on the same machine as your protected server, do the following.

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

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

Figure 6–2 Example of chroot Directory Structure

Example of chroot Directory Structure

ProcedureTo specify the chroot for a Virtual Server Class

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

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

  2. Select the Virtual Server Class tab.

  3. Click the Edit Classes link.

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

  5. Click the Advanced button for that class.

    The Virtual Servers CGI Settings page appears.

  6. Enter the full pathname in the Chroot field.

  7. Click OK.

  8. Click Apply.

  9. Choose Load Configuration Files to dynamically apply.

Specifying the chroot for a Virtual Server

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

ProcedureTo specify the chroot directory for a specific virtual server

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

  2. Select the Virtual Server Class tab.

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

  4. Select the Settings tab.

    The Settings page appears.

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

  6. Click OK.

  7. Click Apply.

  8. Choose Load Configuration Files to dynamically apply.

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

    For more information about how to specify a chroot directory for a virtual server, see the Sun Java System Web Server 6.1 SP12 Programmer’s Guide.