Securing WebLogic Server

Configuring Identity and Trust

This following sections describe how to configure identity and trust for WebLogic Server:

Before performing the steps in this chapter, review the "Identity and Trust" section in Understanding WebLogic Security.

Private Keys, Digital Certificates, and Trusted Certificate Authorities

Private keys, digital certificates, and trusted certificate authorities establish and verify server identity and trust.

SSL uses public key encryption technology for authentication. With public key encryption, a public key and a private key are generated for a server. The keys are related such that data encrypted with the public key can only be decrypted using the corresponding private key and vice versa. The private key is carefully protected so that only the owner can decrypt messages that were encrypted using the public key.

The public key is embedded into a digital certificate with additional information describing the owner of the public key, such as name, street address, and e-mail address. A private key and digital certificate provide identity for the server.

The data embedded in a digital certificate is verified by a certificate authority and digitally signed with the certificate authority's digital certificate. Well-know certificate authorities include Verisign and Entrust.net. The trusted certificate authority (CA) certificate establishes trust for a certificate.

An application participating in an SSL connection is authenticated when the other party evaluates and accepts the application's digital certificate. Web browsers, servers, and other SSL-enabled applications generally accept as genuine any digital certificate that is signed by a trusted certificate authority and is otherwise valid. For example, a digital certificate can be invalidated because it has expired or the digital certificate of the certificate authority used to sign it expired. A server certificate can be invalidated if the host name in the digital certificate of the server does not match the URL specified by the client.

Configuring Identity and Trust: Main Steps

To create identity and trust for a server:

Obtain digital certificates, private keys, and trusted CA certificates from the CertGen utility, Sun Microsystem's keytool utility, or a reputable vendor such as Entrust or Verisign. You can also use the digital certificates, private keys, and trusted CA certificates provided by the WebLogic Server kit. The demonstration digital certificates, private keys, and trusted CA certificates should be used in a development environment only.

Store the private keys, digital certificates, and trusted CA certificates. Private keys and trusted CA certificates are stored in a keystore.

Note: The preferred keystore format is JKS (Java KeyStore). WebLogic Server supports private keys and trusted CA certificates stored in files or in the WebLogic Keystore provider for the purpose of backward compatibility only.

Configure the identity and trust keystores for WebLogic Server in the WebLogic Server Administration Console. See "Configure Keystores" in the Administration Console Online Help.

The remainder of this chapter describes these steps.

Supported Formats for Identity and Trust

The PEM (Privacy Enhanced Mail) format is the preferred format for private keys, digital certificates, and trusted certificate authorities (CAs). The preferred keystore format is the JKS (Java KeyStore) format.

A .pem format file begins with this line:

----BEGIN CERTIFICATE----

and ends with this line:

----END CERTIFICATE----

A .pem format file supports multiple digital certificates (for example, a certificate chain can be included). The order of certificates within the file is important. The server's digital certificate should be the first digital certificate in the file, followed by the issuer certificate, and so on. Each certificate in the chain is followed by its issuer certificate. If the last certificate in the chain is the self-signed (self-issued) root certificate of the chain, the chain is considered complete. Note that the chain does not have to be complete.

When using the deprecated file-based private keys, digital certificates, and trusted CAs, WebLogic Server can use digital certificates in either PEM or distinguished encoding rules (DER) format.

A .der format file contains binary data for a single certificate. Thus, a.der file can be used only for a single certificate, while a .pem file can be used for multiple certificates.

Microsoft is often used as a certificate authority. Microsoft issues trusted CA certificates in p7b format, which must be converted to PEM before they can be used with WebLogic Server. For more information, see Converting a Microsoft p7b Format to PEM Format.

Private key files (meaning private keys not stored in a keystore) must be in PKCS#5/PKCS#8 PEM format.

You can still use private keys and digital certificates used with other versions of WebLogic Server with this version of WebLogic Server. Convert the private key and digital certificate from distinguished encoding rules (DER) format to privacy-enhanced mail (PEM) format. For more information, see the description of the der2pem utility in "Using the WebLogic Server Java Utilities" in WebLogic Server Command Reference.

After converting the files, ensure the digital certificate file has the
-----BEGIN CERTIFICATE----- header and the -----END CERTIFICATE----- footer. Otherwise, the digital certificate will not work.

Note: OpenSSL can add a header to the PEM certificate it generates. In order to use such certificates with WebLogic Server, everything in front of "-----BEGIN CERTIFICATE-----" should be removed from the certificate, which you can do using a text editor.

Obtaining Private Keys, Digital Certificates, and Trusted Certificate Authorities

Servers need a private key, a digital certificate containing the matching public key, and a certificate for at least one trusted certificate authority. WebLogic Server supports private keys, digital certificates, and trusted CA certificates from the following sources:

The demonstration digital certificates, private keys, and trusted CA certificates in the WL_HOME\server\lib directory and the JAVA_HOME\jre\lib\security directory.

The demonstration digital certificates, private keys, and trusted CA certificates should be used in a development environment only.

Sun Microsystem's keytool utility can also be used to generate a private key, a self-signed digital certificate for WebLogic Server, and a Certificate Signing Request (CSR).

Submit the CSR to a certificate authority to obtain a digital certificate for WebLogic Server.
Use the keytool utility to update the self-signed digital certificate with a new digital certificate.
Use the keytool utility to obtain trust and identity when using WebLogic Server in a production environment.

For more information about Sun's keytool utility, see the keytool-Key and Certificate Management Tool description at http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/keytool.html.

Note: When using the keytool utility, the default key pair generation algorithm is DSA. WebLogic Server does not support the use of the Digital Signature Algorithm (DSA). Specify another key pair generation and signature algorithm when using WebLogic Server.

The CertGen utility generates digital certificates and private keys that should be used only for demonstration or testing purposes in a development environment, and not in a production environment. Use the CertGen utility if you want to set an expiration date in the digital certificate or specify a correct host name in the digital certificate so that you can use host name verification. (The demonstration digital certificate provided by WebLogic Server uses the machine's default host name as the host name.) For more information about using the CertGen utility to obtain private keys and digital certificates, see Using the CertGen Utility.

Note: The Certificate Request Generator servlet is deprecated in this release of WebLogic Server. Use the keytool utility from Sun Microsystems in place of the Certificate Request Generator servlet. For more information about keytool, see Common Keytool Commands.

Common Keytool Commands

Table 10-1 lists keytool commands you use when creating and using JKS keystores with WebLogic Server.

Note: The keytool utility is a product of Sun Microsystems. Therefore, BEA Systems does not provide complete documentation on the utility. For more information, see the keytool-Key and Certificate Management Tool description at http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/keytool.html.

Table 10-1 Commonly Used keytool Commands

Command	Description
`keytool -genkey -keystore` `keystorename` `-storepass` `keystorepassword`	Generates a new private key entry and self-signed digital certificate in a keystore. If the keystore does not exist, it is created.
`keytool -import -alias` `aliasforprivatekey-fileprivatekeyfilename.pem-keypass` `privatekeypassword-keystore` `keystorename` `-storepass` `keystorepassword`	Updates the self-signed digital certificate with one signed by a trusted CA.
`keytool -import -alias` `aliasfortrustedca` `-trustcacerts -file` `trustedcafilename.pem` `-keystore` `keystorename` `-storepass` `keystorepassword`	Loads a trusted CA certificate into a keystore. If the keystore does not exist, it is created.
`keytool -certreq -alias alias -sigalg` `sigalg-file` `certreq_file-keypass` `privatekeypassword-storetype` `keystoretype-keystore` `keystorename-storepass` `keystorepassword`	Generates a Certificate Signing Request (CSR), using the PKCS#10 format, and a self-signed certificate with a private key. Stores the CSR in the specified `certreq_file`, and the certificate/private key pair as a key entry in the specified keystore under the specified alias.
`keytool -list -keystore` `keystorename`	Displays what is in the keystore.
`keytool -delete -keystore` `keystorename` `-storepass` `keystorepassword` `-alias` `privatekeyalias`	Deletes the entry identified by the specified alias from the keystore.
`keytool -help`	Provides online help for keytool.

Using the CertGen Utility

Note: The CertGen utility generates digital certificates and private keys that should only be used for demonstration or testing purposes and not in a production environment.

The CertGen utility provides command line options to specify a CA certificate and key to be used for issuing generated certificates. The digital certificates generated by the CertGen utility have the host name of the machine on which they were generated as the value for its common name field (cn) by default only. Command line options let you specify values for the cn and other Subject domain name (DN) fields, such as orgunit, organization, locality, state, and countrycode.

The CertGen utility generates public certificate and private key files in PEM and DER formats. On Windows, double-click.der files to view the details of the generated digital certificate. The .pem files can be used when you boot WebLogic Server or use the digital certificates with a client.

By default, the CertGen utility uses the following demonstration digital certificate and private-key files: CertGenCA.der and CertGenCAKey.der. CertGen looks for these files in the current directory, or in the WL_HOME/server/lib directory, as specified in the weblogic.home system property or the CLASSPATH. If you want to use these files, you need not specify CA files on the command line. Alternatively, you can specify CA files on the command line, as shown in the following command syntax.

Use the CertGen utility to generate a certificate. See CertGen in the WebLogic Server Command Reference. The following example shows the syntax for the CertGen utility:

$ java utils.CertGen

[-cacert <ca_cert_file->] [-cakey <ca_key_file>]
[-cakeypass <ca_key_password>] [-selfsigned]
[-certfile <cert_file>] [-keyfile <private_key_file>]
[-keyfilepass <keyfile_pass>] [-strength <key_strength>]
[-cn <common_name>] [-ou <org_unit>] [-o <organization>]
[-l <locality>] [-s <state>] [-c <country_code>]
[-subjectkeyid <subject_key_identifier>]
[-subjectkeyidformat UTF-8|BASE64]

Argument	Definition
`ca_cert_file`	The file name of the issuer's CA public certificate.
`ca_key_file`	The file name of the issuer's CA private key.
`ca_key_password`	The password for the issuer's CA private key.
`selfsigned`	Generates a self-signed certificate that can be used as a trusted CA certificate. If this argument is specified, the `ca_cert_filename`, `ca_key_filename`, and `ca_key_password` arguments should not be specified.
`cert_file`	The name of the generated certificate file.
`private_key_file`	The name of the generated private key file.
`keyfile_pass`	The password for the private key.
`key_strength`	The length (in bits) of the keys to be generated. The longer the key, the more difficult it is for someone to break the encryption.
`common_name`	The name to be associated with the generated certificate.
`org_unit`	The name of the organizational unit associated with the generated certificate.
`organization`	The name of the organization associated with the generated certificate.
`locality`	The name of a city or town.
`state`	The name of the state or province in which the organizational unit (ou) operates if your organization is in the United States or Canada, respectively. Do not abbreviate.
`country_code`	Two-letter ISO code for your country. The code for the United States is US.
`subject_key_identifier`	Generates a certificate with the Subject Key identifier extension and the ID value specified on the command line.
`UTF-8\|BASE64`	Format of the `subjectkeyid` value. Allowed values are UTF-8 or BASE64, with UTF-8 assumed by default.

Use the ImportPrivateKey utility to load the digital certificate and private key into a keystore. See ImportPrivateKey in the WebLogic Server Command Reference.

If you do not explicitly specify a hostname with the -cn option, the CertGen tool uses the JDK InetAddress.getHostname() method to get the hostname it puts in the Subject common name. The getHostName() method works differently on different platforms. It returns a fully qualified domain name (FQDN) on some platforms (for example, Solaris) and a short host name on other platforms (for example, Windows NT). On Solaris, the result of InetAddress.getHostname() depends on how the hosts entry is configured in the /etc/nsswitch.conf file.

If WebLogic Server is acting as a client (and by default host name verification is enabled), you need to ensure that the host name specified in the URL matches the Subject common name in the server certificate. Otherwise, connections will fail because the host names do not match.

Using Your Own Certificate Authority

Many companies act as their own certificate authority. To use those trusted CA certificates with WebLogic Server:

Ensure the trusted CA certificates are in PEM format.

If the trusted CA certificate is in DER format, use the der2pem utility to convert them.
If the trusted CA certificate was issued by Microsoft, see Converting a Microsoft p7b Format to PEM Format.
If the trusted CA certificate has a custom file type, use the steps in Converting a Microsoft p7b Format to PEM Format to convert the trusted CA certificate to PEM format.

Create a trust keystore. For more information, see How WebLogic Server Locates Trust.

Store the trusted CA certificate in the trust keystore. For more information, see How WebLogic Server Locates Trust.

Configure WebLogic Server to use the trust keystore. For more information, see Configuring Keystores For Production.

Converting a Microsoft p7b Format to PEM Format

Digital certificates issued by Microsoft are in a format (p7b) that cannot be used by WebLogic Server. The following example converts a digital certificate in p7b (PKCS#7) format to PEM format on Windows XP:

In Windows Explorer, select the file (filename.p7b) you want to convert. Double-click on the file to display a Certificates window.

In the left pane of the Certificates window, expand the file.

Expand the Certificates folder to display a list of certificates.

Select a certificate to convert to PEM format. Right-click on the certificate, then choose All Tasks > Export to display the Certificate Export Wizard.

In the wizard, click Next

Select the Base-64 encoded X.509 (.CER) option. Then click Next. (Base-64 encoded is the PEM format.)

In the File name: field, enter a name for the converted digital certificate; then click Nest.

Note: The wizard appends a.cer extension to the output file The .cer extension is a generic extension which is appended to both base-64 encoded certificates and DER certificates. You can change the extension to .pem after you exit the wizard.

Verify that the settings are correct. If the settings are correct, click Finish; if they are not correct, click Back and make any necessary modifications.

Note: For p7b certificate files that contain certificate chains, you need to concatenate the issuer PEM digital certificates to the certificate file. The resulting certificate file can be used by WebLogic Server.

Obtaining a Digital Certificate for a Web Browser

Low-security browser certificates are easy to acquire and can be done from within the Web browser, usually by selecting the Security menu item in Options or Preferences. Go to the Personal Certificates item and ask to obtain a new digital certificate. You will be asked for some information about yourself.

The digital certificate you receive contains public information, including your name and public key, and additional information you would like authenticated by a third party, such as your E-mail address. Later you will present the digital certificate when authentication is requested.

As part of the process of acquiring a digital certificate, the Web browser generates a public-private key pair. The private key should remain secret. It is stored on the local file system and should never leave the Web browser's machine, to ensure that the process of acquiring a digital certificate is itself safe. With some browsers, the private key can be encrypted using a password, which is not stored. When you encrypt your private key, you will be asked by the Web browser for your password at least once per session.

Note: Digital certificates obtained from Web browsers do not work with other types of Web browsers or on different versions of the same Web browser.

Using Certificate Chains (Deprecated)

Note: The use of file-based certificate chains is deprecated in this release of WebLogic Server. Now the whole certificate chain is imported into a keystore. The steps in this section are provided for the purpose of backward compatibility only.

To use certificate chains with WebLogic Server:

Ensure that all the digital certificates are in PEM format. If they are in DER format, you can convert them using the der2pem utility. If you are using a digital certificate issued by Microsoft, see Converting a Microsoft p7b Format to PEM Format. You can use the steps in the section to convert other types of digital certificates. Save the digital certificate in Base 64 format.

Open a text editor and include all the digital certificate files into a single file. The order is important. The server digital certificate should be the first digital certificate in the file. The issuer of that digital certificate should be the next in the file and so on until you get to the self-signed root certificate authority certificate. This digital certificate should be the last certificate in the file.

You cannot have blank lines between digital certificates.

Specify the file in the Server Certificate File Name field on the Configuration > SSL page in the WebLogic Server Administration Console.

Listing 10-1 shows a sample certificate chain.

Listing 10-1 Sample File with Certificate Chain

Storing Private Keys, Digital Certificates, and Trusted Certificate Authorities

Once you have obtained private keys, digital certificates, and trusted CA certificates, you need to store them so that WebLogic Server can use them to find and verify identity. Private keys, their associated digital certificates, and trusted CA certificates are stored in keystores. The keystores can be configured through the WebLogic Server Administration Console or specified on the command line. Use the Configuration > Keystore page in the WebLogic Server Administration Console to configure identity and trust keystores for WebLogic Server. See Configuring Keystores in the Administration Console Online Help.

For the purpose of backward compatibility, private keys and trusted CA certificates can be stored in a file or in a JKS keystore accessed via the WebLogic Keystore provider. In addition, trusted CA certificates can be stored in a JKS keystore. Use the Configuration > SSL page of the WebLogic Server Administration Console to specify identity and trust options when using a file or a JKS keystore accessed via the WebLogic Keystore provider.

Guidelines for Using Keystores

When configuring SSL you have to decide how identity and trust will be stored. Although one keystore can be used for both identity and trust, BEA recommends using separate keystores for both identity and trust because the identity keystore (private key/digital certificate pairs) and the trust keystore (trusted CA certificates) may have different security requirements. For example:

For trust, you only have to put the certificates (non-sensitive data) in the keystore while for identity, you have to put the certificate and private key (sensitive data) in the keystore.
The identity keystore may be prohibited by company policy from ever being put in the network while the trust keystore can be distributed over the network.
The identity keystore may be protected by the operating system for both reading and writing by non-authorized users while the trust keystore only needs to be write protected.
The identity keystore password is generally known to fewer people than the password for the trust keystore.

In general, systems within a domain have the same trust rules (use the same set of trusted CAs), while they tend to have per-server identity. Identity requires a private key, and private keys should not be copied from one system to another. Therefore, you should maintain separate identity keystores for each system, each keystore containing only the server identity needed for that system. However, trust keystores can be copied from system to system; thus making it easier to standardize trust rules.

Identity is more likely to be stored in hardware keystores such as nCipher. Trust can be stored in a file-based JDK keystore without having security issues because a trust store contains only certificates, not private keys.

Creating a Keystore and Loading Private Keys and Trusted Certificate Authorities into the Keystore

A keystore is for the secure storage and management of private keys/digital certificate pairs and trusted CA certificates. Use the following mechanisms to create a keystore and load private keys and trusted CA certificates into the keystore:

The WebLogic ImportPrivateKey utility. The ImportPrivateKey utility allows you to take private key and digital certificate files and load them into a keystore. For more information, see ImportPrivateKey in the WebLogic Server Command Reference.
Sun Microsystem's keytool utility. Use the keytool utility to generate a private key/digital certificate pair and then import the signed private key into the keystore. For more information, see How WebLogic Server Locates Trust. While you can use the keytool utility to generate new private keys and digital certificates and add them to a keystore, the utility does not allow you to take an existing private key from a file and import it into the keystore. Instead, use the WebLogic ImportPrivateKey utility.

Note: The keytool utility does allow you to import trusted CA certificates from a file into a keystore.

Custom utilities. This release of WebLogic Server can use keystores created with custom tools or utilities. How to create and use these utilities is outside the scope of this document.

All private key entries in a keystore are accessed by WebLogic Server via unique aliases. You specify the alias when loading the private key into the keystore. Aliases are case-insensitive; the aliases Hugo and hugo would refer to the same keystore entry. Aliases for private keys are specified in the Private Key Alias field on the Configuration > SSL page in the WebLogic Server Administration Console. Although WebLogic Server does not use the alias to access trusted CA certificates, the keystore does require an alias when loading a trusted CA certificate into the keystore.

All certificate authorities in a keystore identified as trusted by WebLogic Server are trusted.

How WebLogic Server Locates Trust

WebLogic Server uses the following algorithm when it loads its trusted CA certificates:

If the keystore is specified by the -Dweblogic.security.SSL.trustedCAkeystore command-line argument, load the trusted CA certificates from that keystore.

Else if the keystore is specified in the configuration file (config.xml), load trusted CA certificates from the specified keystore. If the server is configured with DemoTrust, trusted CA certificates will be loaded from the WL_HOME\server\lib\DemoTrust.jks and the JDK cacerts keystores.

Else if the trusted CA file is specified in the configuration file (config.xml), load trusted CA certificates from that file (this is only for compatibility with 6.x SSL configurations).

Else load trusted CA certificates from WL_HOME\server\lib\cacerts keystore.

Configuring Keystores For Production

By default, WebLogic Server is configured with two keystores:

DemoIdentity.jks—Contains a demonstration private key for WebLogic Server. This keystore contains the identity for WebLogic Server.
DemoTrust.jks—Contains the trusted certificate authorities from the WL_HOME\server\lib\DemoTrust.jks and the JDK cacerts keystores. This keystore establishes trust for WebLogic Server.

These keystores are located in the WL_HOME\server\lib directory and the JAVA_HOME\jre\lib\security directory. For testing and development purposes, the keystore configuration is complete. However, do not use the demonstration keystores in a production environment. Because the digital certificates and trusted CA certificates in the demonstration keystores are signed by a WebLogic Server demonstration certificate authority, a WebLogic Server installation using the demonstration keystores will trust any WebLogic Server installation that also uses the demonstration keystores. You want to create a secure environment where only your installations trust each other.

To configure keystores for use in a production environment:

Obtain private keys and digital certificates from a reputable certificate authority such as Verisign, Inc. or Entrust.net. For more information, see Obtaining Private Keys, Digital Certificates, and Trusted Certificate Authorities.

Create identity and trust keystores. For more information, see Creating a Keystore and Loading Private Keys and Trusted Certificate Authorities into the Keystore.

Load the private keys and trusted CAs into the identity and trust keystores. For more information, see Creating a Keystore and Loading Private Keys and Trusted Certificate Authorities into the Keystore.

Use the WebLogic Server Administration Console to configure the identity and trust keystores. See "Configure Keystores" in the Administration Console Online Help.

You can also use the WebLogic Scripting Tool or Java Management Extensions (JMX) APIs to create a new security configuration. For more information see the WebLogic Scripting Tool and Developing Custom Management Utilities with JMX manuals.