Chapter 6 Certificates and Keys

This chapter describes the use of certificates and keys authentication to secure the Sun Java System Web Server. It describes how to activate the various security features designed to safeguard your data, keep out intruders, and allow access to those you want.

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

• Certificate Key Types

• Creating a Self-Signed Certificate

• Managing Certificates

• Managing Certificate Revocation Lists (CRL)

• Setting Password for the Internal Token

• Configuring SSL for Your Server

• Enabling SSL Ciphers for a Configuration

• Enabling Security For HTTP Listener

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.

A certificate consists of digital data that specifies the name of an individual, company, or other entity, and certifies that the public key, included in the certificate, belongs to that entity. Both clients and servers can have certificates.

A certificate is issued and digitally signed by a Certificate Authority, or CA. The CA can be a company that sells certificates over the Internet, or it can be a department responsible for issuing certificates for your company’s intranet or extranet. You decide which CAs you trust enough to serve as verifiers of other people’s identities.

In addition to a public key and the name of the entity identified by the certificate, a certificate also includes an expiration date, the name of the CA that issued the certificate, and the “digital signature” of the issuing CA.

A server certificate must be installed before encryption can be activated.

Server Authentication

Server authentication refers to the confident identification of a server by a client; that is, identification of the organization assumed to be responsible for the server at a particular network address.

Client Authentication

Client authentication refers to the confident identification of a client by a server; that is, identification of the person assumed to be using the client software. Clients can have multiple certificates, much like a person might have several different pieces of identification.

Certificate Key Types

In addition to RSA keys, Sun Java System Web Server 7.0 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, as well as 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 Sun Java System Web Server 7.0 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 nor 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 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.

For creating 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).

Managing Certificates

• Requesting a Certificate

• Installing a Certificate

• Renewing a Certificate

• Deleting a Certificate

Requesting a Certificate

A certificate consists of digital data that specifies the name of an individual, company, or other entity, and certifies that the public key, included in the certificate, belongs to that individual. SSL enabled servers must have a certificate and clients may optionally have a certificate.

A certificate is issued and digitally signed by a Certificate Authority, or CA. The CA can be a company that sells certificates over the Internet, or it can be a department responsible for issuing certificates for your company’s intranet or extranet. You decide which CAs you trust enough to serve as verifiers of other people’s identities.

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

To Request a Certificate

1. Click Server Certificates tab > Request button.

2. Select a 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 Sun Java System Web Server 7.0, 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 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, www.sun.com). 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.

5. 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 –

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

   ---

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

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

8. View Results

   This page provides you with the summary of selected options. Click on 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 --server-name=servername.org --org=sun --country=ABC --state=DEF --locality=XYZ --token=internal

   ---

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

Installing a Certificate

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

To Install a Certificate

1. Click 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 Sun Java System Web Server 7.0, 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 button 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.

6. View Results

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

   ---

   Note –

   Using CLI

   For installing 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).

   ---

Renewing a Certificate

You can renew an existing certificate by following these steps:

To 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 on Finish to complete the renewal process.

Deleting a Certificate

For deleting certificates, perform the following tasks:

To Delete a Certificate

1. Click Server Certificates tab.

2. Select the certificate

   Select the certificate name from the certificate list.

3. Delete certificate

   Click Delete button to delete the selected certificate.

   ---

   Note –

   Using CLI

   For deleting 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

Fore renewing the administration server certificates, execute the command renew-admin-certs CLI command. Use this command to renew the administration certifications with the nicknames Admin-CA-Cert, Admin-Server-Cert, and Admin-Client-Cert. 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 will be in effect. It is necessary that you 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. For renewing 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.

To Install a CRL

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

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

2. Go to the configuration page in administration console.

3. Click the Certificates > Certificate Authorities tab.

4. Click 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

   For installing 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).

To Delete a CRL

1. Go to the configuration page in 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

   For deleting 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

For setting password for the internal PKCS11 token, perform the following tasks:

To 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. For removing the password, perform the above steps and select Unset Password option.

   ---

   Note –

   Using CLI

   For setting 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 Your Server

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 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 
--token=internal

Check the man pages for more options and examples.

With the certificate installed, you need a listener on some 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 --server-name=config1.com 
--default-virtual-server-name=config1_vs_1 config1_ls_1

Now 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

Enabling SSL Ciphers for a Configuration

For enabling SSL Ciphers for your 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

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 meaning less to anyone except the intended recipient. Decryption is the process of transforming encrypted information so that it is meaningful again. Sun Java System 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.

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.

Sun Java System 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, transmit certificates, and establish session keys. Clients and servers may support different cipher suites, or sets of ciphers, depending on factors such as which protocol they support, company policies on encryption strength, and government restrictions on export of encrypted software. Among other functions, the SSL and TLS handshake protocols determine how the server and client negotiate which cipher suites they will use to communicate.

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