Exporting a Certificate or Trusted Certificate from the Keystore Using WLST

8-18 Oracle Fusion Middleware Administrators Guide If you receive two files from the CA, import the CA certificate first as a trusted certificate, followed by the newly generated certificate: importKeyStoreObjectinst1, ovd5, ovd, jks1, password, TrustedCertificate, tmpcacert.txt, unique_alias where unique_alias is a unique alias by which the trusted certificate is imported. importKeyStoreObjectinst1, ovd5, ovd, jks1, password, Certificate, tmpcert.txt, alias where password is the password for this keystore, tmpcert.txt is the file that the CA returned and contains BASE64 encoded certificate, tmpcacert.txt is the file containing the BASE64 encoded CA certificate, and alias is the alias by which this certificate is imported. Note that this alias must match that of the key pair that was used to generate the certificate request.

8.3.6 Keystore and Certificate Maintenance

This section contains the following administration topics: ■ Location of Keystores ■ Replacing Expiring Certificates ■ Effect of Host Name Change on Keystores

8.3.6.1 Location of Keystores

The root directory for Oracle Virtual Directory keystores is located in ORACLE_ INSTANCEconfigOVDovd_instance_namekeystores. This root directory will contain all the JKS files. A sample structure, assuming there are two keystores named keys.jks and trust.jks respectively, would look like this: ORACLE_INSTANCEconfigOVDovd_instance_namekeystoreskeys.jks ORACLE_INSTANCEconfigOVDovd_instance_namekeystorestrust.jks

8.3.6.2 Replacing Expiring Certificates

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. Generate a certificate request from the keystore use the same key-pair 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. 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 ask the CA to issue a new certificate for that certificate request. Managing Keystores, Wallets, and Certificates 8-19 3. Import the newly issued certificate into the keystore using the same alias as that of the key-pair. 4. 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.

8.3.6.3 Effect of Host Name Change on Keystores

Typically, the certificate DN is based on the host name of the server where the keystore is used. For example, if a keystore is being created for the Oracle Virtual Directory server on host my.example.com, then the DN of the certificate in this Oracle Virtual Directory keystore 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 HTTP Client, among others. If the host name of the server does not match that of the certificate DN: ■ A clear warning is displayed in the case of browser clients. ■ There may be SSL handshake failure in the case of other clients. Thus, whenever you have a keystore 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 keystore. This can be done by requesting a new certificate with a new DN based on the new host name. For a Production Keystore The steps are: 1. Generate a new request with the new DN based on a new host name. 2. Send this request to a certificate authority CA. 3. Get back a new certificate from the CA. 4. Import the new certificate with the same alias as the key-pair for which certificate request was generated. For a Self-signed Keystore The steps are: 1. Delete the existing keystore. 2. Create a new keystore with a key-pair using the new DN based on the new host name. 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