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

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.

Note –

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

Server Authentication

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

Client Authentication

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

Certificate Key Types

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:

prime256v1

secp256r1

nistp256

secp256k1

secp384r1

nistp384

secp521r1

nistp521

sect163k1

nistk163

sect163r1

sect163r2

nistb163

sect193r1

sect193r2

sect233k1

nistk233k1

nistk233

sect233r1

nistb233

sect239k1

sect283k1

nistk283

sect283r1

nistb283

sect409k1

nistk409

sect571k1

nistk571

sect571r1

nistb571

secp160k1

secp160r1

secp160r2

secp192k1

secp192r1

nistp192

secp224k1

secp224r1

nistp224

prime192v1

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.

Managing Certificates

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

Click Server Certificates tab > Request button.

Select a Configuration

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

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.

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.

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.

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.

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.

View Results

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

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

Click Server Certificates tab > Install button.

Select Configuration

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

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.

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.

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.

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.

Renewing a Certificate

To Renew a Certificate

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

Update Certificate Details

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

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.

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

Click Server Certificates tab.

Select the certificate

Select the certificate name
from the certificate list.

Delete certificate

Click Delete button to delete
the selected certificate.

Note –

Using CLI

For deleting
a certificate through the CLI, execute the following command:

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.

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:

Obtain the CRL as a file from your CA.

Go to the configuration page in administration console.

Click the Certificates > Certificate Authorities tab.

Click Install CRL button

Enter the full path name to the associated file.

Click OK.

Note –

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

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.

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.

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.

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.

Table 6–1 HTTP Listener Security Properties

Property

Description

Name

Name of the HTTP Listener.

Security

Enable/Disable security for the selected HTTP Listener.

Certificate

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

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.

TLS

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 listen socket for the Administration Server.
Enabling SSL and TLS on a listen socket for the Server Manager will set those
security preferences for all virtual servers associated with that listen socket.

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.