Sun Java System Web Server 7.0 Update 4 Administrator's Guide

Chapter 6 Certificates and Keys

This chapter describes the use of certificates and keys authentication to secure the server. It describes how to activate various security features designed to safeguard data, keep out intruders, and allow access.

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.

Using Certificates for 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.

Certificates or digital certificates are collections of data that uniquely identify or verify an individual, company, or other entity on the Internet. Certificates also enable secure, confidential communication between two entities. Personal certificates are used by individuals, whereas server certificates are used to establish secure sessions between the server and clients through secure sockets layer (SSL) technology.

A certificate is like a passport; it identifies the holder and provides other important information. Certificates are verified, issued and digitally signed by a trusted third party called Certification Authority (CA). Once a CA has signed a certificate, the holder can present it as proof of identity to establish encrypted, confidential communication. 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.

Certificates are based on public key cryptography, which uses a pair of digital keys (very long numbers) to encrypt (encode) information, so that it can be read only by its intended recipient. The recipient then decrypts (decodes) the information to read it.

A key pair contains a public key and a private key. The owner distributes the public key and makes it available to anyone. But the owner never distributes the private key; it is always kept secret. Because the keys are mathematically related, data encrypted with one key can be decrypted only with the other key in the pair. Most importantly, a certificate binds the owner's public key to the owner's identity.

In addition to the public key, a certificate typically includes information such as:

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. SSL enabled servers must have a certificate and clients may optionally have a certificate.

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.

Certificate Chain

Digital certificates are verified using a chain of trust. The trust anchor for digital certificate is the root Certificate Authority (CA). Web browsers are preconfigured with a set of root CA certificates that the browser automatically trusts. Any certificate from elsewhere must come with a certificate chain to verify its validity.

A certificate chain is a sequence of certificates, where each certificate in the chain is signed by the subsequent certificate, eventually resulting in a tree structure. A certificate chain thus traces the path of a certificate from a branch to the root in the hierarchy. The root certificate is a self-signed, topmost certificate of the tree and is generated first. A self-signed certificate is one for which the issuer (signer) is the same as the subject (the entity whose public key is being authenticated by the certificate). The certificates that are directly subordinate to the root certificate have CA certificates that are signed by the root certificate. All certificates below the root certificate thus inherit the trustworthiness of the root certificate.

A certificate chain has the following components:

In a certificate chain:

Verifying a certificate chain is a process of ensuring that a specific chain is valid, correctly signed, and trustworthy. The purpose of certificate chain is to establish a chain of trust from a subordinate certificate to a trusted root CA certificate. The root CA certificate vouches for the identity in the branch certificate by signing it. If the root CA is the one you trust, it implies that you can trust the certificate of its branches.

During a certificate chain verification, the authentication will fail when:

Certificate Key Types

In addition to RSA keys, Web Server introduces support for Elliptic Curve Cryptography (ECC).

ECC is emerging as an attractive public-key cryptosystem because compared to traditional cryptosystem like RSA, ECC offers equivalent security with smaller key sizes, which results in faster computations, lower power consumption, and memory and bandwidth savings. Elliptic Curve Cryptography (ECC) has been endorsed by the US government.

It is now possible to select whether you want to generate a certificate request or a self-signed certificate using RSA keys or ECC keys.

For RSA keys different key sizes can be provided (bigger key sizes means better encryption. Default key size is 1024). For ECC keys you should choose the curve the keypair will be generated on. A number of curves have been named by various organizations (ANSI X9.62, NIST, SECG) and Web Server supports all the ones currently specified.

If you intend to request a certificate from a CA (instead of using a self-signed certificate) be sure to contact your preferred CA first to obtain their latest information regarding ECC usage. Ask if they recommend a particular ECC curve for your use case(s). If you do not have guidance on curve selection from your CA or from your organizations internal policies, here are some recommendations. Keep in mind that since ECC is an emerging technology it is possible that curve recommendations for particular use cases may have changed from the time this document was written.

Some supported ECC Curves are listed below:










































Creating a Self-Signed Certificate

You can generate a self-signed certificate if you do not need your certificate to be signed by a CA, or if you wish to test your new SSL implementation while the CA is in the process of signing your certificate. This temporary certificate will generate an error in the client browser to the effect that the signing certificate authority is unknown and not trusted.

To create a self-signed certificate through CLI, execute the following command.

wadm> create-selfsigned-cert --user=admin --port=8989 --password-file=admin.pwd 
--config=config1 --token=internal --org-unit=org1 --locality=XYZ --state=DEF 
--validity=10 --org=sun --country=ABC --server-name=serverhost --nickname=cert1

See CLI Reference, create-selfsigned-cert(1).

Importing Self-signed Certificate to IE Browser

The Web Server installer should import the admin self-signed certificate into the IE certificate tab. When the Admin console is accessed using a browser, a pop-up window (in the case of IE6 and Mozilla/Firefox) or a warning page (IE7) may appear stating that the certificate is not issued by a trusted certificate authority. This is because the administration server uses a self-signed certificate. To proceed to the Administration GUI login page, do the following:

These procedures will accept the certificate temporarily for that browser session. To accept the certificate permanently, follow the steps below:

Managing Certificates

Requesting a Certificate

You can request a certificate and submit it to a 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 information they require. You can also create a self-signed certificate for the server. Self-signed certificates are not suitable for Internet-facing deployments but can be very useful for development and testing because they allow you to set up test servers without CA involvement.

As mentioned above, a certificate includes the public key of the entity (the web server in this case). A public key is generated based on a particular algorithm (the algorithm type is also encoded in the certificate). The next section provides background on the algorithm types supported by the Web Server for its keys.

ProcedureTo Request a Certificate

  1. Click Server Certificates tab > Request button.

  2. Select a configuration from the configuration list for which you need to install the certificate.

  3. Select the token (Cryptographic Device), which contains the keys.

  4. If your key is stored in the local key database maintained by the server, choose internal. If your key is stored in a Smart Card or other external device or engine, choose the name of the external token from the drop-down list box. Enter the password for the selected token.

  5. Enter Details.

    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:

    • Server Name must be the fully qualified hostname used in DNS lookups (for example, This is the hostname in the URL that a browser uses to connect to your site. If these two names do not match, a client is notified that the certificate name doesn’t match the site name, creating doubt about the authenticity of your certificate.

      You can also enter wildcard and regular expressions in this field if you are requesting a certificate from an internal CA. Most vendors will not approve a certificate request with a wildcard or regular expression entered for common name.

    • 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, for the organization.

    • State or Province is optional.

    • Country is a two-character abbreviation of your country name (in ISO format). The country code for the United States is US.

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

  6. Choose Certificate Options

    You are required to provide the key information. For key type, you can choose RSA or ECC. If the key type is RSA, the key size can be 1024, 2048 or 4098. If your key type is ECC you will also need to select a curve. Keep in mind that generating a new key pair takes time. The longer the key length the longer the time the wizard takes to generate it.

    Caution – Caution –

    Be sure to select a key type that the CA (to which you will later submit the request for signing) can support.

  7. Select Certificate Type.

    Select the Certificate Signing Authority (CSA) for the certificate (self-signed or CA signed). If you are selecting a self-signed certificate, you can also associate an HTTP Listener for the certificate. You can also perform this action later.

  8. Generate Request.

    The generated certificate request will be available in ASCII format in case of CA signed certificate. In case of self-signed certificate, it will be installed directly. If the type is self-signed, provide values for nickname, validity (Months) and the HTTP Listener name for handling secure requests.

  9. View Results.

    This page provides you with the summary of selected options. Click Finish to complete the request generation.

    Note –

    Using CLI

    To request a certificate through CLI, execute the following command.

    wadm> create-cert-request --user=admin --password-file=admin.pwd 
    --host=serverhost --port=8989 --config=config1 
    --org=sun --country=ABC --state=DEF --locality=XYZ --token=internal

    See CLI Reference, create-cert-request(1).

    Note –

    To create a self-signed certificate through CLI, see Creating a Self-Signed Certificate.

Configuring Solaris Cryptographic Framework

This section describes how to configure Solaris cryptographic for use with Web Server.

ProcedureTo Configure Solaris Cryptographic

  1. Remove the ./sunw directory from your machine using the following command:

    %rm -rf $HOME/.sunw

  2. Set a new pin using the following command:

    % pktool setpin Enter new PIN:<type the pin here>

    Re-enter new PIN:<retype the pin again>

  3. Disable the mechanisms in the and files using the following command:



    Note –

    Ensure to disable mechanisms in file, if it is used.

ProcedureTo Register PKCS#11 Library File

  1. Type the following command to add the Solaris crypto framework to network security services (NSS) in the config directory

    $ cd <install-dir>/<instance-dir>/lib/modutil -dbdir <install-dir>/<instance-dir>/config -nocertdb -add "scf" -libfile /usr/lib/ -mechanisms RSA

  2. Verify the registration using the following command:

    $cd <install-dir>/<instance-dir>/lib/modutil -dbdir <install-dir>/<instance-dir>/config -nocertdb -list

    Listing of PKCS #11 Modules
    1. NSS Internal PKCS #11 Module
         slots: 2 slots attached
             status: loaded
              slot: NSS Internal Cryptographic Services
             token: NSS Generic Crypto Services
              slot: NSS User Private Key and Certificate Services
             token: NSS Certificate DB
       2. scf
             library name: /usr/lib/
              slots: 1 slot attached
             status: loaded
              slot: Sun Crypto Softtoken
             token: Sun Software PKCS#11 softtoken
       3. Root Certs
             library name:
              slots: There are no slots attached to this module
             status: Not loaded

    For more information on creating server certificates, see Requesting a Certificate

    If certificates exists in the NSS database, you can export or import the certificates using the following pk12util command:

    $pk12util -o server.pk12 -d . -n <server-cert>

    $pk12util -i server.pk12 -d . -h "Sun Software PKCS#11 softtoken"

    Note –

    By default, certutil/pk12util searches the databases for cert8.db and key3.db. Add -P as the prefix for the Web Server, which uses the alternate names https-instance-hostname-cert8.db and https-instance-hostname-key3.db.

ProcedureTo Enable and Bypass PKCS#11 Tokens

  1. From the home page, click the Configurations tab.

  2. In the Configuration page, click the configuration that you want to enable the PKCS#11 and Allow Bypass option.

  3. Click the Certificates tab.

  4. Click the PKCS#11 Tokens sub tab.

  5. In General Settings, select the check boxes to enable PKCS#11 and Allow Bypass.

  6. Click the Save button.

    See CLI reference, set-pkcs11-prop(1).

Creating a Self-Signed Certificate Using CLI and Enabling SSL

Start the wadm from the installation directory and perform the following steps:

$wadm --user=admin
Please enter admin-user-password>enter the administration serverpassword


Sun Software PKCS#11 softtoken

$wadm>create-selfsigned-cert --nickname=MyCert 
--token="Sun Software PKCS#11 softtoken"
Please enter token-pin>enter the password

CLI201 Command 'create-selfsigned-cert' ran successfully

$wadm>set-ssl-prop --http-listener=http-listener-1 enabled=true 
server-cert-nickname="Sun Software PKCS#11 softtoken:MyCert"
CLI201 Command 'set-ssl-prop' ran successfully

CLI201 Command 'deploy-config' ran success

Start the Administration Server.

$ cd <install-dir>/<instance-dir>/bin/startserv
Sun Java System Web Server 7.0 Update 3

Please enter the PIN for the "Sun Software PKCS#11 softtoken" token:enter the password
info: HTTP3072: http-listener-1: ready to accept requests
info: CORE3274: successful server startup

Installing a Certificate

After obtaining the certificate from a CA, you can install the certificate for a configuration using the Administration Console.

ProcedureTo Install a Certificate

  1. Click the Server Certificates tab > Install button.

  2. Select Configuration.

    Select a configuration from the configuration list for which you need to install the certificate.

  3. Select Tokens.

    Select the token (Cryptographic Device) which contains the keys. If your key is stored in the local key database maintained by the server, choose internal. If your key is stored in a Smart Card or other external device or engine, choose the name of the external token from the drop-down list box. Enter the password for the selected token.

  4. Enter Certificate Data.

    Paste the certificate text in the text area provided. When you copy and paste the text, be sure to include the headers “Begin Certificate” and “End Certificate” — including the beginning and ending hyphens. You can also click Browse and select the .DER file manually.

  5. Provide Certificate Details.

    Provide a nickname to be used for the certificate. Select the HTTP Listener from the available list for handling the secure requests. You can also select the self-signed certificate option.

  6. View Results.

    This page provides you with a summary of selected options. Click Finish to complete the installation process.

    Note –

    Using CLI

    To install a certificate through CLI, execute the following command.

    wadm> install-cert --user=admin --port=8989  --password-file=admin.pwd 
    --config=config1 --token=internal --cert-type=server --nickname=cert1 cert.req

    where cert.req contains the certificate data.

    See CLI Reference, install-cert(1).

Requesting and Installing External Certificates

You can request and install certificates from other certificate authorities. A list of CAs are available in the industry. This section describes how to request and install external server certificates.

Perform the steps 1– 5, as described in the To Request a Certificate section. Perform the following steps to complete the request for external certificate.

  1. In the Certificate Type wizard, select the CA Signed Certificate option and click Next.

  2. Review page is displayed. Verify the settings and click Finish.

  3. Copy the Certificate Signing Requests (CSR) including the headers and click the Close button.

  4. Go to the certificate authorities web site, complete the formalities to get the certificate signed by the authority.

  5. Save the certificate in the local folder or copy the certificate from the web site.

To install the obtained certificate, perform the steps 1–3, as described in the To Install a Certificate. Perform the following steps to complete the installation for external certificates.

  1. In the Enter Certificate Data page, paste the certificate or provide the path of the file that you have saved in the machine. Click the Next button.

  2. Enter the nick name for the certificate and select the listener from the drop-down list. Click the Next button.

  3. Review page is displayed. Click the Finish button to complete the installation.

For more information on setting a token pin, see To Set the Token Password.

Renewing a Certificate

You can renew an existing certificate by following these steps:

ProcedureTo Renew a Certificate

  1. Click Server Certificates tab > Certificate Name > Renew button.

  2. Provide Token Information.

    Enter the password for the token if required. Otherwise click Next to continue.

  3. Update Certificate Details.

    Review the certificate details and provide the validity period in months.

  4. Update Key Information.

    For key type, you can choose RSA or ECC. If the key type is RSA, the key size can be 1024, 2048 or 4098. If your key type is ECC you will also need to select a curve. Keep in mind that generating a new key pair takes time.

  5. View Summary.

    This page provides you with the summary of selected options. Click Finish to complete the renewal process.

    Note –

    You must restart the administration server and node after the administration server certificates are renewed.

Deleting a Certificate

To delete a certificate, perform the following tasks:

ProcedureTo Delete a Certificate

  1. Click Server Certificates tab.

  2. Select the certificate.

    Select the certificate name from the certificate list.

  3. Delete certificate.

    Click the Delete button to delete the selected certificate.

    Note –

    Using CLI

    To delete a certificate through the CLI, execute the following command:

    wadm> delete-cert --user=admin --port=8989  --password-file=admin.pwd 
    --token=internal --config=config1 cert1

    See CLI Reference, delete-cert(1).

Renewing Administration Server Certificates

To renew Administration Server certificates, with the nicknames Admin-CA-Cert, Admin-Server-Cert, and Admin-Client-Cert execute therenew-admin-certs CLI command. . This command also updates the nodes that are currently running and are accessible with the renewed certificates.

After executing this command, it is recommended that you restart the administration servers and nodes so that the new certificates can take effect. You must re-register a node if the node was offline (not running or was not accessible due to network problems) during the renewal of the certificates. To renew the administration server certificates, execute the following command.

wadm> renew-admin-certs --user=admin --password-file=admin.pwd --host=serverhost 
--port=8989 --validity=120

See CLI Reference, renew-admin-certs(1).

Managing Certificate Revocation Lists (CRL)

Certificate revocation lists (CRLs) makes known any certificate and key 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. CRLs are produced and periodically updated by a CA.

ProcedureTo Install a CRL

To install a CRL obtained from a CA, perform the following steps:

  1. Obtain the CRL as a file from your CA.

  2. Go to the configuration page in the administration console.

  3. Click the Certificates > Certificate Authorities tab.

  4. Click the Install CRL button.

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

  6. Click OK.

    Note –

    If the CRL already exists in the database, a Replace Certificate Revocation List page will appear.

  7. You may need to click Deploy for changes to take effect.

    Note –

    Using CLI

    To install a CRL through CLI, execute the following command.

    wadm> install-crl --user=admin --password-file=admin.pwd 
    --host=serverhost --port=8989 --config=config1 data/install-crl/ServerSign.crl

    See CLI Reference, install-crl(1).

ProcedureTo Delete a CRL

  1. Go to the configuration page in the administration console.

  2. Click the Certificates > Certificate Authorities tab.

  3. Select the CRL entry and click Delete.

  4. You may need to click Deploy for changes to take effect.

    Note –

    Using CLI

    To delete a CRL through CLI, execute the following command.

    wadm> delete-crl --user=admin --password-file=admin.pwd 
    --host=serverhost --port=8989 --config=config1 issuer

    See CLI Reference, delete-crl(1).

Setting Password for the Internal Token

To set password for the internal PKCS11 token, perform the following tasks:

ProcedureTo Set the Token Password

  1. Go to the configuration page in administration console.

  2. Click the Certificates > PKCS11 Tokens tab.

  3. Click the PKCS11 token name (default is internal).

  4. Select the Token State checkbox.

  5. Enter password information.

  6. If you do not want to be prompted for password at instance startup, select the checkbox. Do not prompt for the new password at instance startup. Click OK.

  7. The password will be saved in the configuration. To remove the password, perform the above steps and select Unset Password option.

    Note –

    Using CLI

    To set the password for the internal PKCS11 token through CLI, execute the following command.

    wadm> set-token-pin --user=admin --password-file=admin.pwd --host=serverhost 
    --port=8989 --config=config1 --token=internal

    See CLI Reference, set-token-pin(1).

Configuring SSL for the Server

SSL is the most popular standard for securing Internet communications and transactions. Web applications use HTTPS (HTTP over SSL), which uses digital certificates to ensure secure, confidential communications between server and clients. In an SSL connection, both the client and the server encrypt data before sending it, then decrypt it upon receipt.

When a Web browser (client) wants to connect to a secure site, an SSL handshake happens:

After the handshake, the client has verified the identity of the Web site, and only the client and the Web server have a copy of the session key. From this point forward, the client and the server use the session key to encrypt all their communications with each other. Thus, their communications are ensured to be secure.

The newest version of the SSL standard is called TLS (Transport Layer Security).

Use the command create-cert-request to generate a request and send the request to your CA. Later, when you receive the certificate from the CA you'll need to install it using the install-cert command. If you have a key and a certificate in a Java keystore which you're looking to migrate, use the command migrate-jks-keycert. For a development/test server, the easiest way to get going is to generate a self-signed certificate using the command create-selfsigned-cert.

wadm> create-selfsigned-cert --server-name=hostname --nickname=MyServerCert 

Check the man pages for more options and examples.

With the certificate installed, you need a listener on a port which will have SSL enabled.

wadm> create-http-listener --user=admin --password-file=admin.pwd --host=serverhost 
--port=8989 --listener-port=18003 --config=config1 
--default-virtual-server-name=config1_vs_1 config1_ls_1

Next enable SSL for the listener and associate the listener with the nickname of the certificate.

wadm> set-ssl-prop --http-listener=http-listener-ssl enabled=true
wadm> set-ssl-prop --http-listener=http-listener-ssl server-cert-nickname=MyServerCert

After this setup, deploy the configuration and start the instance.

wadm> deploy-config config_name
wadm> start-instance --config config_name hostname

Note –

Using Administration Console

To create a self-signed certificate through Administration Console, perform the tasks as mentioned in Requesting a Certificate and select 'Self-Signed Certificate' as the certificate type.

Enabling SSL Ciphers for a Configuration

To enable SSL Ciphers for a configuration, execute the following command.

wadm> enable-ciphers --user=admin --password-file=admin.pwd --host=serverhost 
--port=8989 --config=config1 --http-listener=http-listener-1 
--cipher-type=ssl2 SSL_RC4_128_WITH_MD5

See CLI Reference, enable-ciphers(1).

Enabling Security For HTTP Listener

Note –

Security can be enabled for the HTTP listener only when there are available installed certificates.

Once you have a certificate, you can associate the certificate with a HTTP Listener and thus secure the server.

Encryption is the process of transforming information so it is meaningless to anyone except the intended recipient. Decryption is the process of transforming encrypted information so that it is meaningful again. Web Server includes support for SSL and TLS protocols.

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

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

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

Note –

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

The encryption process alone isn’t enough to secure your server’s confidential information. A key must be used with the encrypting cipher to produce the actual encrypted result, or to decrypt previously encrypted information. The encryption process uses two keys to achieve this result: a public key and a private key. Information encrypted with a public key can be decrypted only with the associated private key. The public key is published as part of a certificate; only the associated private key is safeguarded.

Web Server 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, to transmit certificates, and to 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.

Click theConfigurations > HTTP Listeners > Security tab to edit the HTTP Listeners security settings. The following table lists the properties that you can configure in this page.

Table 6–1 HTTP Listener Security Properties




Name of the HTTP Listener. 


Enable/Disable security for the selected HTTP Listener. 


Select the server certificate from the available certificates. You should have installed either a RSA or ECC certificate for performing this action. 

Client Authentication

Specifies whether the client authentication is required or optional. Select False option to disable client authentication. 

Authentication Timeout

Timeout after which client authentication handshake fails. [0.001–3600]. The default value is 60 seconds.

Maximum Authentication Data

Maximum amount of authentication data to buffer. [0–2147.0483647.0]. The default value is 104857.06.

SSL Version 2/Version 3

Enable/Disable SSL Version 2/ SSL Version 3. 


Enable/Disable TLS. Detect version rollbacks is enabled by default. This configures the server to detect man-in-the-middle version rollback attack attempts. Disabling this may be required for interoperability with some clients that incorrectly implement the TLS specification.

SSL3/SSL2/TLS 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 HTTP Listener for the Administration Server.

The default settings allow the most commonly used ciphers. Unless you have a compelling reason why you do not want to use a specific cipher suite, you should allow them all.