Create a new keystore with a key-pair using the new DN (based on the new host name) See Section 8.3.3.1 for details.

For Both Keystore Types

For both production and self-signed keystores, once the new certificate is available in the keystore, ensure that it is imported into all the component keystores where it needs to be trusted. For example, if the HTTP listener on Oracle Virtual Directory was SSL-enabled and its certificate changed due to a host name change, then you need to import its new certificate into the client keystore or browser repository so that it can trust its new peer.

8.4 Wallet Management

This section contains the following topics:

■ About Wallets and Certificates

■ Accessing the Wallet Management Page in Fusion Middleware Control ■ Managing the Wallet Life Cycle

■ Common Wallet Operations ■ Managing the Certificate Life Cycle

■ Accessing the Certificate Management Page for Wallets in Fusion Middleware

Control

Wallet Management

■ Wallet and Certificate Maintenance

8.4.1 About Wallets and Certificates

This section contains the following topics:

■ Password-Protected and Autologin Wallets ■ Self-Signed and Third-Party Wallets ■ Sharing Wallets Across Instances ■ Wallet Naming Conventions

8.4.1.1 Password-Protected and Autologin Wallets

You can create two types of wallets:

■ Auto-login wallet

This is an obfuscated form of a PKCS#12 wallet that provides PKI-based access to services and applications without requiring a password at runtime. You can also add to, modify, or delete the wallet without needing a password. File system permissions provide the necessary security for auto-login wallets.

■ Password-protected wallet

As the name suggests, this type of wallet is protected by a password. Any addition, modification, or deletion to the wallet content requires a password. Every time a password-protected wallet is created, an auto-login wallet is automatically generated. However, this auto-login wallet is different from the user-created auto-login wallet described in the previous bullet. While the user-created wallet can even be updated at configuration time without a

password, an automatically generated auto-login wallet is a read-only wallet that does not allow direct updates. Modifications to the wallet must occur through the password protected file (by providing a password), at which time the auto-login wallet is regenerated.

The purpose of this system-generated auto-login wallet is to provide PKI-based access to services and applications without requiring a password at runtime, while still requiring a password at configuration time.

Note: In previous releases, you could create a wallet with a password and then enable auto-login to create an obfuscated wallet. With 11g Release 1 (11.1.1), auto-login wallets are created without a password. When using such a wallet, you do not need to specify a password.

If using an auto-login wallet without a password, specify a null password ("") in the ldapbind command.

Older type of wallets (such as Release 10g wallets) will continue to work as they did earlier.

Note: Wallets configured for Oracle Internet Directory must have auto-login enabled.

Wallet Management

8-22 Oracle Fusion Middleware Administrator's Guide

8.4.1.2 Self-Signed and Third-Party Wallets

Self-signed wallets contain certificates for which the issuer is the same as the subject. These wallets are typically created for use within an intranet environment where trust is not a high priority. Each self-signed wallet has its own unique issuer; hence, in an environment with multiple components and wallets, the trust management tasks increase n-fold.

When created through Fusion Middleware Control, a self-signed wallet is valid for five years.

Third-party wallets contain certificates that are issued by well known CA's. The functionality and security remain the same as for self-signed wallets, but the use of third-party certificates provides added trust because the issuers are well known, so they are already trusted by most clients.

Difference Between Self-Signed and Third-Party Wallets

From a functional and security perspective, a self-signed certificate is comparable to one issued by a third party. The only difference is that a self-signed certificate is not trusted.

8.4.1.3 Sharing Wallets Across Instances

Oracle recommends that you do not share wallets between component instances or Oracle instances, since each wallet represents a unique identity.

The exception to this is an environment with a cluster of component instances, in which case wallet sharing would be an acceptable practice.

Note that no management tools or interfaces are available to facilitate wallet sharing. However, you can export a wallet from one instance and import it into another instance. See Section 8.4.4 for details of wallet export and import.

8.4.1.4 Wallet Naming Conventions

Follow these naming conventions for your Oracle wallets:

■ Do not use a name longer than 256 characters.

■ Do not use any of the following characters in a wallet name:

| ; , ! @ # $ ( ) < > / \ " ' ` ~ { } [ ] = + & ^ space tab

■ Do not use non-ascii characters in a wallet name.

■ Additionally, follow the operating system-specific rules for directory and file

names

Due to the way data is handled in an LDAP directory such as Oracle Internet Directory, wallet names are not case-sensitive.

Thus, it is recommended that you use case-insensitive wallet names (preferably, using all lower case letters). For example, if you have created a wallet named UPPER, do not create another wallet named upper; doing so could cause confusion during wallet management operations.

Note: Observe this rule even your operating system supports the character.