Oracle® Key Vault

Release Notes

Release 18.1

E99979-04

May 2019

These release notes list the new features for this release of Oracle Key Vault, how to download the latest product software and documentation, and how to address known issues in Oracle Key Vault.

1.1 Changes in This Release for Oracle Key Vault

Oracle Key Vault release 18.1 introduces several new features that enhance the use of Key Vault in a large enterprise.

1.1.1 Multi-Master Cluster

Oracle Key Vault release 18.1 introduces the multi-master cluster capability. This feature provides an active-active high availability solution that you can extend across data centers and geographic regions to provide disaster recovery and high availability for both read and write key management operations. Also, the multi-master cluster capability provides zero-downtime from the database endpoint perspective.

1.1.2 Support for FIPS Mode

You can install Oracle Key Vault so that it operates in FIPS 140-2 compliant mode (FIPS mode), which provides increased security. If you do not install Oracle Key Vault so that it uses FIPS mode, then a user with the System Administrator role can enable or disable it from the Oracle Key Vault management console.

1.1.3 Enhancements to RESTful API

The Oracle Key Vault RESTful services utility enables you to automate Oracle Key Vault administration tasks such as endpoint enrollment and virtual wallet management for a large distributed deployment. With Oracle Key Vault 18.1, customers can also automate key management tasks such as key creation, deactivation, and key deletion for the endpoints.

1.2 Downloading the Oracle Key Vault Software and the Documentation

At any time, you can download the latest version of the Oracle Key Vault software and documentation.

1.2.1 Downloading the Oracle Key Vault Installation Software

For a fresh installation, you can download the Oracle Key Vault software from Software Delivery Cloud. You cannot use this package to upgrade Oracle Key Vault. For an upgrade from an existing Oracle Key Vault 12.2 deployment, you can download the Oracle Key Vault upgrade software from the My Oracle Support website.

  1. Use a web browser to access the Oracle Software Delivery Cloud portal:
  2. Click Sign In, and if prompted, enter your User ID and Password.
  3. In the All Categories menu, select Release. In the next field, enter Oracle Key Vault and then click Search.
  4. From the list that is displayed, select Oracle Key Vault 18.1.0.0.0 or click the +Add to Cart button next to the Oracle Key Vault 18.1.0.0.0.
    The download is added to your cart. (To check the cart contents, click View Cart in the upper right of the screen.)
  5. Click Checkout.
  6. On the next page, verify the details of the installation package, and then click Continue.
  7. In the Oracle Standard Terms and Restrictions page, select I have reviewed and accept the terms of the Commercial License, Special Programs License, and/or Trial License, and click Continue.

    The download page appears, which lists the following Oracle Key Vault ISO files:

    • Vpart_number.iso (Oracle Key Vault 18.1.0.0.0 - Disc 1)

    • Vpart_number.iso (Oracle Key Vault 18.1.0.0.0 - Disc 2)

  8. To the right of the Print button, click View Digest Details.

    The listing for the two ISO files expands to display the SHA-1 and SHA-256 checksum reference numbers for each ISO file.

  9. Copy the SHA-256 checksum reference numbers and store them for later reference.
  10. Click Download and select a location to save the ISO files. 
    You can save each file individually by clicking its name and then specifying a location for the download.
  11. Click Save.

    The combined size of both ISO files exceeds 4 GB, and will take time to download, depending on the network speed. The estimated download time and speed are displayed in the File Download dialog box.

  12. After the ISO files are downloaded to the specified location, verify the SHA-256 checksums of the downloaded files:
    1. From a Linux or Unix machine, generate a SHA256 checksum for the first Vpart_number.iso:
      $ sha256sum Vpart_number.iso

      Ensure that the checksum matches the value that you copied from the File Download dialog box in .

    2. Generate a SHA-256 checksum for the second Vpart_number.iso:
      $ sha256sum Vpart_number.iso

      Ensure that the checksum matches the value that you copied from the File Download dialog box in .

  13. Optionally, burn each of the two Vpart_number.iso files to a DVD-ROM disc and then label the discs:
    • OKV Disc 1

    • OKV Disc 2

You can now install Oracle Key Vault on a server machine.

1.2.2 Downloading the Oracle Key Vault Upgrade Software

For an upgrade, Oracle Key Vault can be downloaded from the https://support.oracle.com (My Oracle Support) website.

For a fresh installation, Oracle Key Vault can be downloaded from Software Delivery Cloud. Note that this package cannot be used for an upgrade.

Download the upgrade software:

  1. Go to https://support.oracle.com, sign in, and click the Patches & Updates tab.
  2. Use the Patch Search box to find the patch.
    1. Click the Product or Family (Advanced) link on the left.
    2. In the Product field, start typing Oracle Key Vault, and then select the product name from the list of options.
    3. In the Release field, select the latest bundle patch Oracle Key Vault 18.1.0.0.0 from the drop-down list.
    4. Click Search.
  3. In the search results page, in the Patch Name column, click the number for the latest Bundle Patch ORACLE KEY VAULT 18.1.0.0.0 RELEASE (Patchset).

    A corresponding patch page appears.

  4. Click the Read Me button to open the readme file in a browser.
  5. Click the Download button to open the File Download page.
  6. Click the Download File Metadata link on the bottom left, and then the Download button to download the XML metadata file.

    You can use the data in this file to verify the patch files.

  7. Click the Return to File Window link to go back to the File Download page.
  8. Click the following .zip files to download them on your system:
    • p29695836_181000_Linux-x86-64_1of2.zip
    • p29695836_181000_Linux-x86-64_2of2.zip
  9. Unzip the downloaded .zip files to access the upgrade software.

    After unzipping the downloaded zip files to your destination directory, you will see the following files:

    • The following two ISO files include all the files that are required to perform the upgrade:
      • okv-upgrade-18.1.0.0.0-part1.iso
      • okv-upgrade-18.1.0.0.0-part2.iso
    • Readme_OKV_181.html
  10. You can use the XML metadata file to verify the checksum of the downloaded .iso files.
  11. On your Linux machine, combine the two ISO files into one ISO file.
    cat okv-upgrade-18.1.0.0.0-part1.iso okv-upgrade-18.1.0.0.0-part2.iso > okv-upgrade-18.1.0.0.0.iso
    Execute the above commands on a different machine other than an Oracle Key Vault server.
  12. On your Limux machine, generate a sha256 checksum for the combined ISO files.
    sha256sum okv-upgrade-18.1.0.0.0.iso
    Ensure that the file checksum matches the following value:
    4d3f145eeb5ec53427dc2522408151c6ff38af459469a2bfecb5dcea508af31a  okv-upgrade-disc-18.1.0.0.0.iso

Refer to Upgrading the Oracle Key Vault Server Software in Oracle Key Vault Administrator's Guide for detailed instructions on performing an upgrade.

1.2.3 Downloading the Oracle Key Vault Documentation

  1. Access the Oracle documentation site.
  2. Select Related Products.
  3. In the Database Security section, search for and download the most current version of the Oracle Key Vault 18.1 documentation, including these release notes.

1.3 Known Issues

At the time of this release, there are several issues with Oracle Key Vault that could occur in rare circumstances. For each issue, a workaround is provided.

1.3.1 Failover Issues When Primary OKV Experiences a Controlled Shutdown

Issue: Periodically, the primary Oracle Key Vault server in a primary-standby pair has a controlled shutdown. For example, a user performs the shutdown by pressing a power off button in the user interface or executes the shutdown command from the terminal. When this happens, there will be no failover operation and the standby Oracle Key Vault server will not take over as the primary server. This can be predicted by the existence of the file /var/lock/subsys/dbfwdb on the primary Oracle Key Vault server. If the file exists on the primary at the time of the controlled shutdown, there will not be a failover. If it does not exist, then a failover should occur.

Note that failover still does occur in other situations such as power loss on the primary or database failure, regardless of the file's existence.

Workaround: If performing a controlled shutdown in an attempt to cause the standby to take over as the new primary, instead perform a switchover.

Bug Number: 29666606

1.3.2 HA Setup Succeeds with Different Primary & Standby RO Restricted Mode Config

Issue: For a primary-standby configuration, if read-only restricted mode is enabled on one Oracle Key Vault server and not on the other Oracle Key Vault server, then the configuration succeeds. This mismatch can lead to issues and confusion in a primary-standby deployment.

Workaround: Use the Oracle Key Vault management console to ensure that both servers have the same read-only restricted mode state applied. To do so, select the System tab, then Primary-Standby. Select the Allow Read-Only Restricted Mode option. Only then apply the primary-standby configuration on each server.

Bug Number: 26536033

1.3.3 OKV 12.2 BP1: User Gets Locked and Expired with Multiple Failed Logins

Issue: The current password policy locks the user account for a day if the user has incorrectly entered the password more than three consecutive times. Therefore, the user will be able to log in only after the 24-hour lockout period expires.

Workaround: Make a note of the password and keep it accessible and secure.

Bug Number: 23300720

1.3.4 OKV 12.2 BP2: SSH Tunnel Status Shows as Disabled on Failover Case in HA

Issue: After a failover operation, the new Oracle Key Vault primary server does not show the correct status of the SSH tunnel. It shows the SSH tunnel as disabled when the SSH tunnel is available. The dashboard also shows an alert, warning that the setup of an SSH tunnel failed. This is because after the failover operation, Oracle Key Vault tried to establish two SSH tunnels to the same database as a service endpoint, resulting in the incorrect status and dashboard alert. The second SSH tunnel to the database as a service endpoint does not affect connectivity between the Oracle Key Vault server and the database as a service endpoint. The first SSH tunnel to the database as a service endpoint is functional and available after the failover.

Workaround: After a failover, the new Oracle Key Vault primary server shows the correct SSH status as available and connected to the database as a service endpoints. You also can use the okvutil list on the database as a service endpoint to check the status of the SSH tunnel.

Bug Number: 24679516

1.3.5 OKV 12.2 BP8: Audit Trail is not Sent To Remote Syslog on Switchover in HA Pair

Description: With syslog configured on the primary, the audit logs are also written to the syslog. On switchover, the audit logs may not be written to the syslog. This is because the syslog has not been configured on the standby. Syslog needs to be configured on primary and standby separately.

Workaround: Configure the syslog on standby after switchover to enable write of audit logs to syslog.

Bug Number: 28790364

1.3.6 OKV 18.1: Aborting the Pairing When the Controller Node Can't Contact the Candidate Node Takes an Hour

Issue: When attempting to add a node to the cluster, if the controller node fails to make contact with the candidate node, aborting the addition of the node can take an excessively long time. This is due to the controller node's repeated attempts to make contact with the candidate node before ultimately failing and letting the abort proceed.

Workaround: No workaround to abort faster.

Bug Number: 29688831

1.3.7 OKV 18.1: Click On New Add Node Link In Nodes Other Than Controller Node Gives Add Node Link

Issue: When you add a node to a multi-master cluster, on the Cluster Management page, in the Cluster Details table, if you click the name of the candidate node on any node other than the controller node, you will be redirected to the Add Node to Cluster page instead of to the candidate node.

Workaround: Directly navigate to the candidate node using its URL instead of clicking the name of the candidate node in the Cluster Details table.

Bug Number: 29669752

1.3.8 OKV 18.1: HA Can Be Configured on the Node Which is Cluster Enabled in 18.1 Unpair HA

Issue: Some leftover alerts from the primary-standby configuration (formerly known as high availability) may exist on the dashboard after unpairing the primary from the standby and converting the former primary Oracle Key Vault server to a cluster node. Additionally, clicking on the link on the alert on the homepage will bring you to the Primary-Standby page, even though this page is blocked in cluster mode.

Workaround: Disable all primary-standby alerts before converting the first node to a cluster node. Alternatively, just ignore the alerts. Definitely do not attempt to use the primary-standby configuration on a cluster node.

Bug Number: 29679389

1.3.9 OKV 18.1: Primary Switchover Alerts Seen Even After Unpair of the OKV 18.1 HA Pair

Issue: Some leftover alerts from the primary-standby configuration (formerly known as high availability) may exist on the dashboard after unpairing the primary from the standby.

Workaround: Disable all primary-standby alerts after unpairing the primary from the standby. If you again decide to use the Primary-Standby configuration, it is recommended that you re-enable all of the alerts.

Bug Number: 29679378

1.3.10 OKV 18.1: Warnings Messages Seen on Doing Upgrade of OKV Server From 12.2BP8

Issue: When you upgrade from an older release of Oracle Key Vault to release 18.1, the following error messages may appear:
  • /images/upgrade/lib/dbfw/process.rb:277: warning: assigned but unused variable - e
  • /images/upgrade/lib/dbfw/system_logger.rb:79: warning: assigned but unused variable - e
  • /images/upgrade/lib/preconditions.rb:528: warning: assigned but unused variable - latest_version
  • /images/upgrade/lib/dbfw/system_history.rb:154: warning: File.exists? is a deprecated name, use File.exist? instead

Workaround: Not needed. You can safely ignore these warnings.

Bug Number: 29671115

1.3.11 OKV Alerts Still Show in the List After Fixing the Problem

Issue: User password expiration alerts are still showing even after the user changes their password.

Workaround: In the Oracle Key Vault management console, select Reports and then Configure Reports. Then uncheck the User Password Expiration option. Alternatively, ignore the alert.

Bug Number: 27620622

1.3.12 OKV SYSTEMS That Were Unpaired Before Being Upgraded Need a DB_UNIQUE_NAME Reset

Issue: Oracle Key Vault systems that were part of an Oracle Key Vault 12.2 high availability (now primary-standby) configuration before being unpaired, and then upgraded, have their DB_UNIQUE_NAME parameters set to 'DBFWDB_HA1' or 'DBFWDB_HA2'. This parameter needs to be reset to 'DBFWDB' before the system is converted to cluster mode, as attempting to add the node to a cluster would otherwise fail.

Workaround: For a system that was the primary server in an Oracle Key Vault 12.2 high availability configuration, and then unpaired before being upgraded to Oracle Key Vault 18.1, the following commands need to be run on the system after successful upgrade and before it is converted to a cluster node:
  1. Log into the primary Oracle Key Vault system as user support through ssh.
  2. Switch to user root.
    su - root
  3. Check the owner and group on directory /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv.
    ls -l /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb
    The output should be similar to this output.
    drwxr-xr-x 2 root   oinstall  4096 Apr 24 22:01 metadata_pv
  4. If the directory is owned by user root, as shown above, execute the following command:
    chown oracle:oinstall /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
    List the file and verify that the owner is now oracle.
    ls -l /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb
    The output should be similar to this output.
    drwxr-xr-x 2 oracle oinstall 4096 Apr 24 22:01 metadata_pv
  5. Switch to user oracle.
    su oracle
  6. Start SQL*Plus.
    sqlplus / as sysdba
  7. Execute the following statement:
    show parameter db_unique_name;
  8. If the DB_UNIQUE_NAME is something other than DBFWDB, then execute the following statements:
    alter system set db_unique_name='DBFWDB' scope=spfile;
    exit
  9. As user root, execute the following commands:
    service dbfwdb stop
    service dbfwdb start
  10. Verify that the DB_UNIQUE_NAME parameter has changed.
    Start SQL*Plus.
    sqlplus / as sysdba
  11. Execute the following statement:
    show parameter db_unique_name
    The output returned should match the output shown here.
    NAME                  TYPE        VALUE
    --------------------- ----------- -----------
    db_unique_name        string      DBFWDB

Bug Number: 29696058

1.3.13 On HP-UX System, SELECT FROM V$ENCRYPTION_KEYS May Return ORA-28407 Occasionally

Issue: On HP-UX operating system, a Transparent Data Encryption (TDE) query such as the following that is executed in a long-running database process or session may occasionally result in an ORA-28407 Hardware Security Module error detected error:

SELECT * FROM V$ENCRYPTION_KEYS;

This is because the system could not create another thread-specific data key because the process had reached or exceeded the system-imposed limit on the total number of keys per process, which is controlled by the PTHREAD_KEYS_MAX setting. PTHREAD_KEYS_MAX is typically set to 128.

Workaround: Switch the database sessions and execute the TDE query again. If it is not convenient to switch the sessions, then set PTHREAD_USER_KEYS_MAX to 16384 before starting the database and the listener.

Bug Number: 28270280

1.3.14 Private Keys Are Not Overwritten When a Java Keystore Is Uploaded Using the -o Option of the okvutil Utility

Issue: When you upload a Java keystore (JKS) or Java Cryptography Extension keystore (JCEKS) to the Oracle Key Vault server using the -o option of the okvutil upload command, user-defined keys are not overwritten.

Workaround: Remove the private key from the wallet and then upload the keystore again.

Bug Number: 26887060

1.3.15 Re-pair After Un-pair from HA 12.2 BP5 to new OKV Server Still Shows Standalone

Issue: When an unpaired Oracle Key Vault primary server running Oracle Key Vault 12.2.0.5.0 or later is paired with a newly installed Oracle Key Vault server, the Current status on the Primary-Standby page shows that the server is in standalone mode. The Standalone status indicates that the primary-standby configuration has failed. The primary-standby setup fails because the SSH configuration on the primary server is not re-enabled.

Workaround: Before pairing an unpaired Oracle Key Vault primary server running Oracle Key Vault, disable and re-enable the SSH configuration. You should disable and then re-enable the SSH configuration after you perform the primary-standby configuration on the primary server after unpairing it with the standby server.

Note:

Before pairing an unpaired Oracle Key Vault primary server running Oracle Key Vault, ensure that you have closed all other browser instances.

Bug Number: 26617880

1.3.16 Replication May Fail to Resume After Multiple System Failures in OKV Cluster

Issue: Due to GoldenGate Bug 29624366, after multiple system failures in an Oracle Key Vault cluster, replication from some nodes may fail to resume. Specifically, GoldenGate replicats will terminate and not be able to process new change logs in the GoldenGate trail file when it happens.

Workaround: Manually reposition such replicats to skip erroneous records in the trail file or forcefully delete the troubled Oracle Key Vault nodes from the cluster and add new nodes to replace them.

Bug Number: 29700647

1.3.17 System Settings Changed on an OKV System After Conversion to a Candidate Node Do Not Reflect On The Controller Node

Issue: If system settings are changed on an Oracle Key Vault system after it has been converted to a candidate node, and after the controller node's initial attempt to verify the candidate node's settings has failed, the updated settings do not reflect on the controller node. The pairing process must be aborted and the candidate node re-installed.

Workaround: None. Verify that the Oracle Key Vault system's settings match with those of the cluster before attempting to convert it into a candidate node and induct it into a cluster.

Bug Number: 29430349

1.3.18 Unable to Open the Database When a DNS Server Is Configured to Access HSM

Issue: Users can configure DNS servers by using the management console. However, if access to HSM depends on a DNS server, the database fails to open when HSM starts.

Workaround: Add the DNS server entries to /etc/resolv.conf. Add the same DNS servers using the management console: System tab > System Settings page > DNS section. Alternatively, you can provide the IP address of the HSM.

Bug Number: 24478865

1.3.19 Unpair of upgraded Primary-Standy OKV 18.1 servers may fail due to permission issues

Issue: After having completed an upgrade to Oracle Key Vault 18.1, attempting to unpair from a primary-standby configuration sometimes fails, with the following messages written out to the /var/log/debug files:
ORA-48141: error creating directory during ADR initialization: [/var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv]
ORA-48189: OS command to create directory failed
Workaround: Before attempting an unpair in a Primary-Standby configuration that has been upgraded to Oracle Key Vault 18.1, please ensure that the /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv directory has the right permissions using the steps below:
  1. Log into the primary Oracle Key Vault system as user support through ssh.
  2. Switch to user root.
    su - root
  3. Check the permissions on directory /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv.
    ls -l /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb
    The output should be similar to this output.
    drwxr-xr-x 2 root   oinstall  4096 Apr 24 22:01 metadata_pv
  4. If the directory is owned by user root, as shown above, execute the following command:
    chown oracle:oinstall /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
    List the file and verify that the owner is now oracle.
    ls -l /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb
    The output should be similar to this output.
    drwxr-xr-x 2 oracle oinstall 4096 Apr 24 22:01 metadata_pv

Bug Number: 29693700

1.4.1 Oracle TDE and Oracle Key Vault Integration

Depending on the Oracle Database version used and on the feature of TDE used, there might be a need to patch the Oracle database for smooth operations.

Refer to the MOS-NOTE with Doc ID 2535751.1 to ascertain if your deployment needs a database patch.

The MOS-NOTE lists known issues with Oracle Database Transparent Data Encryption (TDE) feature when it is configured to use Oracle Key Vault as the keystore. The document also lists the fixes that resolve the issues enabling smoother integration between Oracle Database TDE and Oracle Key Vault. The issues could be defects, reducing the user burden with simplified operations, or improving the integration between TDE and OKV. The document is for Database Administrators and others tasked with managing the TDE Master Keys with Oracle Key Vault.

1.4.2 Oracle Key Vault System Cleanup After Upgrade

After upgrading to Oracle Key Vault 18.1 from a previous release, you may choose to clean up the older kernels left behind after the upgrade. While the older kernel is not in use, it may be marked as an issue by some code analysis tools.

You may also want to rename the DSA keys on upgrade. To rename the keys, follow these steps:

  1. Enable SSH from the Oracle Key Vault management console.
  2. Login to the Oracle Key Vault support account using SSH.
    ssh support@OKVserverIPaddress
  3. Switch to the root user.
    su -
  4. Change directory to /etc/ssh.
    cd /etc/ssh
  5. Rename the keys.
    mv ssh_host_dsa_key.pub ssh_host_dsa_key.pub.retire
    mv ssh_host_dsa_key ssh_host_dsa_key.retire

1.4.3 Reports are Affected by Audit Replication in a Multi-Master Cluster

Oracle Key Vault reports and details in the home page are generated from Oracle Key Vault audit records. Each node will show reports of the operations specifically done on that node if audit replication is turned off. Each node will show reports of the operations done on all nodes in the cluster if audit replication is turned on.

The recommendation is to turn off audit replication and use a security information and event management (SIEM) solution like Oracle Audit Vault and Database Firewall (AVDF) to collect audit records from all nodes.

1.4.4 Supported Database Versions

The following versions of Oracle Database are supported with Oracle Key Vault 18.1:

  • Oracle DB 11.2 with the compatible parameter set to 11.2
  • Oracle DB 12.1 with the compatible parameter set to 11.2
  • Oracle DB 12.2
  • Oracle DB 18c
  • Oracle DB 19c

1.4.5 Updates in a Multi-Master Cluster are Slower Than in a Single Instance

An update in a multi-master cluster might check for an object's existence, which may result in a scan of all nodes in the cluster slowing down the update operation. The time will increase proportional to the number of nodes in the cluster. The update could take several minutes to complete.

The rotation of a TDE Master Key or a TDE REKEY is an example of an update operation.

1.4.6 Upgrading to Oracle Key Vault 18.1 and Converting to a Multi-Master Cluster

After upgrading Oracle Key Vault from previous releases to release 18.1 in a primary-standby deployment (formerly high availability), it is recommended that no switchovers/failovers be performed if the intention is to unpair the systems in the primary-standby configuration, and then convert the primary to the first node of a multi-master cluster. Also, check known issues in section 1.3 before unpairing the servers.

It is recommended that you use the primary server in the primary-standby configuration during the upgrade to Oracle Key Vault 18.1 for initializing the cluster.

It is recommended that you upgrade to Oracle Key vault 18.1 from releases Oracle Key Vault 12.2 BP8 or Oracle Key Vault 12.2 BP9.

1.5 Upgrading an Existing Oracle Key Vault Deployment

Upgrade by installing this release on top of an existing base installation of Oracle Key Vault 12.2.0 or a supported base installation of 12.1.0. This Release Notes contains instructions about how to apply this release to your existing installation of Oracle Key Vault.

Before you upgrade to a new release of Oracle Key Vault, you must ensure that your existing Oracle Key Vault installation is complete. This means that you have logged into the Oracle Key Vault management console and completed all the post-installation tasks.

Note:

If you have applied any one-off Patch Set Exceptions to your installation in addition to a prior Bundle Patch, then you must roll back the one-off patch before upgrading. Please work with Oracle Support to get updated one-off patches and reapply them after the upgrade.

AES256 encryption is supported for fresh installations of Oracle Key Vault 12.2.0.4.0 and higher. After upgrading to the latest version such as Oracle Key Vault 18.1.0.0.0 from an Oracle Key Vault server first installed as Oracle Key Vault 12.2.0.4.0, the Oracle Key Vault tablespaces will continue to use AES256 encryption.

If you have an installation of Oracle Key Vault that is upgraded from a fresh installation of Oracle Key Vault version prior to 12.2.0.4.0, the Oracle Key Vault tablespaces will continue to use AES128 encryption.

1.5.1 Supported Upgrade Paths

There are three supported upgrade paths to Oracle Key Vault Release 18.1: one-step upgrade, two-step upgrade, and and three-step upgrade. The path you choose depends on the version of your existing Key Vault installation.

1.5.1.1 One-Step Upgrade Path

If your existing Key Vault base version is listed in the Compatible Base Versions for One-Step Upgrade Path list below, you can upgrade directly to Release 18.1.0.0.0. Oracle recommends you upgrade to Oracle Key Vault 12.2 BP8 before upgrading to Oracle Key Vault 18.1.

  • 12.2.0.9.0
  • 12.2.0.8.0
  • 12.2.0.7.0
  • 12.2.0.6.0
  • 12.2.0.5.0
  • 12.2.0.4.0
  • 12.2.0.3.0
  • 12.2.0.2.0
  • 12.2.0.1.0
  • 12.2.0.0.0
1.5.1.2 Two-Step Upgrade Path

If you are upgrading from a base version older than 12.2.0.0.0, such as:

  • 12.1.0.9.0
  • 12.1.0.8.0
  • 12.1.0.7.0
  • 12.1.0.6.0
  • 12.1.0.5.0

you must upgrade to Release 18.1.0.0.0 in two steps:

  1. First upgrade to 12.2.0.9.0.
  2. Then upgrade to 18.1.0.0.0.
1.5.1.3 Three-Step Upgrade Path

If you are upgrading from a base version older than 12.1.0.5.0, such as:

  • 12.1.0.4.0
  • 12.1.0.3.0
  • 12.1.0.2.0
  • 12.1.0.1.0
  • 12.1.0.0.0

you must upgrade to Release 18.1.0.0.0 in three steps:

  1. First upgrade to 12.1.0.5.0.
  2. Then upgrade to 12.2.0.9.0.
  3. Finally, upgrade to 18.1.0.0.0.
1.5.1.4 Upgrade Path for 12.2.0 HSM Customers

To upgrade to Release 18.1 from an existing HSM-enabled 12.2.0.1.0, 12.2.0.2.0, 12.2.0.3.0, 12.2.0.4.0, 12.2.0.5.0, 12.2.0.6.0, 12.2.0.7.0, 12.2.0.8.0, or 12.2.0.9.0 installation, please contact Oracle Support.

1.5.2 Installing Oracle Key Vault for a New Deployment

Perform a fresh installation of Oracle Key Vault 18.1.0.0.0 for new Oracle Key Vault deployments. Download and install the latest version of the product Oracle Key Vault 18.1.0.0.0. Installation instructions may be found in the chapter: "Oracle Key Vault Installation and Configuration" in the Oracle Key Vault Administrator's Guide.

1.6 Critical Patch Updates Included in Release 18.1.0.0.0

Oracle Key Vault release 18.1 updated the underlying infrastructure to incorporate the April 2019 Release Update for Oracle Database 18 (18.6 DB RU) - April Release Update. Please sign in for full details.

https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html

Oracle Key Vault release 18.1 also includes security and stability fixes for Java and Oracle Linux (OL) operating system.

1.7 Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.


Oracle Key Vault Release Notes, Release 18.1

E99979-04

Copyright © 2013, 2019, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.