Deleting a Certificate Request, a Certificate, or a Trusted Certificate Using WLST

Managing Keystores, Wallets, and Certificates 8-35 where password is the password for this wallet and tmpcert.txt is the file that the CA returned and contains BASE64 encoded PKCS7. If you receive two files from the CA, import the CA certificate first as a trusted certificate, followed by the newly generated certificate. importWalletObjectinst1, oid1, oid, selfsigned, password, TrustedCertificate, tmpcacert.txt importWalletObjectinst1, oid1, oid, selfsigned, password, Certificate, tmpcert.txt where password is the password for this wallet, tmpcert.txt is the file that the CA returned and contains BASE64 encoded certificate and tmpcacert.txt is the file containing the BASE64 encoded CA certificate.

8.4.8 Wallet and Certificate Maintenance

This section contains the following administration topics: ■ Location of Wallets ■ Effect of Host Name Change on a Wallet ■ Changing a Self-Signed Wallet to a Third-Party Wallet ■ Replacing an Expiring Certificate in a Wallet

8.4.8.1 Location of Wallets

This section describes the location of wallets for different components. Root Directory for an Oracle Internet Directory Wallet The root directory for wallets is ORACLE_INSTANCEOIDadmin. This root directory will contain subdirectories with wallet names; these subdirectories will contain the actual wallet files. For example, assuming there are two wallets named oid1 and oid2, respectively, a sample structure could look like: ORACLE_INSTANCEOIDadminoid1cwallet.sso ORACLE_INSTANCEOIDadminoid1ewallet.p12 ORACLE_INSTANCEOIDadminoid2cwallet.sso Root Directory for an Oracle HTTP Server Wallet The root directory for wallets is ORACLE_INSTANCEconfigOHSohs_ instance_namekeystores. This root directory contains subdirectories with wallet names; these subdirectories contain the actual wallet files. For example, assuming there are two wallets named ohs1 and ohs2, respectively, a sample structure could look like: ORACLE_INSTANCEconfigOHSohs_instance1keystoresohs1cwallet.sso ORACLE_INSTANCEconfigOHSohs_instance1keystoresohs1ewallet.p12 ORACLE_INSTANCEconfigOHSohs_instance1keystoresohs2cwallet.sso Root Directory for an Oracle Web Cache Wallet The root directory for wallets is ORACLE_ INSTANCEconfigWebCachewebcache_instance_namekeystores. 8-36 Oracle Fusion Middleware Administrators Guide This root directory will contain subdirectories with wallet names; these subdirectories will contain the actual wallet files. For example, assuming there are two wallets named wc1 and wc2, respectively, a sample structure could look like: ORACLE_INSTANCEconfigWebCachewebcache_instance1keystoreswc1cwallet.sso ORACLE_INSTANCEconfigWebCachewebcache_instance1keystoreswc1ewallet.p12 ORACLE_INSTANCEconfigWebCachewebcache_instance1keystoreswc2cwallet.sso

8.4.8.2 Effect of Host Name Change on a Wallet

Typically, the wallet DN is based on the host name of the server where the wallet is used. For example, if a wallet is being created for the Oracle HTTP Server my.example.com, then the DN of the certificate in this Oracle HTTP Server wallet will be something like CN=my.example.com,O=organization name. This synchronization is required because most clients do host name verification during the SSL handshake. Clients that perform host name verification include Web browsers and Oracle HTTPClient, among others. If the host name of the server does not match that of the certificate DN, then: ■ A clear warning will be displayed in the case of browser clients. ■ There may be SSL handshake failure in the case of other clients. Thus, when you have a wallet on a server that is accepting requests from clients, you must ensure that whenever the host name of this server changes, you also update the certificate in the wallet. You can do this by requesting a new certificate with a new DN based on the new host name. For a Production Wallet The steps are: ■ Generate a new request with the new DN based on new host name. ■ Send this request to a certificate authority CA. ■ Get back a new certificate from the CA. ■ Delete the older certificate and certificate request from the wallet. ■ Import the new certificate. For a Self-signed Wallet The steps are: ■ Delete the existing wallet. ■ Create a new wallet with a self-signed certificate using the new DN based on the new host name. For both production and self-signed wallets, once the new certificate is available in the wallet, you need to ensure that it is imported into all the component wallets where it needs to be trusted. For example, if Oracle WebLogic Server is SSL-enabled and the certificate for Oracle WebLogic Server changed due to a host name change, then you need to import its new certificate into the Oracle HTTP Server wallet so that it can trust its new peer. Managing Keystores, Wallets, and Certificates 8-37

8.4.8.3 Changing a Self-Signed Wallet to a Third-Party Wallet

You can convert a self-signed wallet into a third-party wallet, one that contains certificates signed by a trusted Certificate Authority CA. Assuming a self-signed wallet named MYWallet, containing a certificate with DN as CN=my.example.com,O=example, take these steps to convert it into a third-party wallet: 1. Remove the user certificate CN=my.example.com,O=example from the wallet. 2. Remove the trusted certificate CN=my.example.com,O=example from the wallet this has the same DN as the user certificate, but is a separate entity nonetheless. 3. Export the certificate request CN=my.example.com,O=example from the wallet and save it to a file. 4. Give this certificate request file to a third-party certificate authority CA such as Verisign. 5. The CA will return one of the following: ■ A user certificate file and its own certificate file ■ A single file with a certificate chain consisting of a user certificate and its own certificate 6. Import the above files into the wallet.

8.4.8.4 Replacing an Expiring Certificate in a Wallet

An expiring certificate should be replaced before it actually expires to avoid or reduce application downtime. The steps for replacing an expiring certificate are as follows: 1. Export the certificate request from the wallet this is the same request for which the current expiring certificate was issued. 2. Provide this certificate request to the third-party Certificate Authority CA for certificate issuance. The validity date of the new certificate should be earlier than the expiration date of the current certificate. This overlap is recommended to reduce downtime. 3. Remove the existing certificate the one that is about to expire from the wallet. 4. Import the newly issued certificate into the wallet. To reduce downtime, remove the previous certificate and import the new certificate in the overlap period when the new certificate has become valid and the older one has not yet expired. 5. If the new certificate was issued by a CA other than the one that issued the original certificate, you may also need to import the new CAs trusted certificate before importing the newly issued certificate. Note: Steps 1 and 2 are not required when the third-party CA already maintains the certificate request in a repository. In that case, simply request the CA to issue a new certificate for that certificate request.