Importing a Certificate or Trusted Certificate into a Keystore Using WLST

Managing Keystores, Wallets, and Certificates 8-17 ■ Two files, one containing the newly generated certificate and a second containing its own CA certificate 10. Use Import to import these files into your keystore: ■ If you received a single file from the CA, import it as a certificate, using an alias that matches the alias of the self-signed certificate you are replacing from Step 6 ■ If you received two files: – Import the file containing the CA certificate as a trusted certificate use an alias that is unique in the keystore – Import the certificate file as a certificate using an alias that matches the alias of the self-signed certificate you are replacing The CA returned a single file, which is imported as a certificate: 11. After import, the certificate issued by the CA replaces the self-signed certificate.

8.3.5.12 Converting a Self-Signed Certificate to a Third-Party Certificate Using WLST

Use these steps to convert a self-signed certificate to a third-party certificate: 1. Generate and export a CSR. exportKeyStoreObjectinst1, ovd5, ovd, jks1, password, CertificateRequest, tmp, mykey 2. Submit the CSR tmpbase64.txt to a certificate authority. The CA will return a newly generated certificate and its own certificate, either as one file in PKCS7 format or as two separate files. 3. If you receive a single file from the CA, run the command: 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 the BASE64 encoded PKCS7, 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. Note: The order is important: you must import the trusted certificate first, followed by the certificate. 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.