Changes in This Release for Oracle Key Vault

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

Changes for Oracle Key Vault Release 18.3

Oracle Key Vault release 18.3 has two new features.

Oracle Key Vault Available in the Oracle Cloud Marketplace

Starting with this release, you can deploy Oracle Key Vault to run on an Oracle Cloud Infrastructure (OCI) VM compute instance.

This functionality is available as click-to-deploy software in the Oracle Cloud Marketplace. Another benefit of this type of deployment is that provisioning in OCI is more streamlined and provides for a faster way to get an application running than in an on-premises installation, which requires an administrator to manage the hardware on which Oracle Key Vault is installed.

Ability to Rename Endpoint Groups and Virtual Wallets using RESTful Services

Starting with this release, you can rename endpoint groups and virtual wallets using RESTful services.

In previous releases, this ability was available in the Oracle Key Vault management console only, but is now available with the following new RESTful API commands:
  • modify_endpoint_group_name
  • modify_wallet_name

Changes for Oracle Key Vault Release 18.2

Oracle Key Vault release 18.2 has enhancements to existing features throughout and the following new parameter.

Endpoint Software Installation Logs Environment Variables For Later Diagnostics

Greater detail in the endpoint software installation logs available starting with this release.

The PKCS#11 library used by Oracle Database endpoints makes use of environment variables like ORACLE_HOME, ORACLE_BASE, and OKV_HOME to look up the endpoint configuration file, okvclient.ora. The environment variables might change over time which may result in the creation of multiple persistent caches and/or the failure of database sessions or the background processes to find the endpoint configuration file.

To facilitate a quick diagnosis, additional information about ORACLE_HOME, ORACLE_BASE, and OKV_HOME when deploying okvclient.jar is included in the deployment log. This should be consistent across database processes that use PKCS#11 library. This information is available in the log file and if the -v option is used when deploying okvclient.jar it is also printed to standard output.

New Endpoint Database Persistent Cache Parameter

Starting with Oracle Key Vault release 18.2, you can set the EXPIRE PKCS11 PERSISTENT CACHE ON DATABASE SHUTDOWN parameter.

The EXPIRE PKCS11 PERSISTENT CACHE ON DATABASE SHUTDOWN automatically expires the PKCS#11 persistent cache for a given endpoint database when the endpoint database shuts down. However, you can only use this parameter the endpoint database has had the patch for bug 29869906: AUTO-LOGIN OKV NEEDS PERSISTENT CACHE PROTECTION KEY FROM RDBMS.

When you enable EXPIRE PKCS11 PERSISTENT CACHE ON DATABASE SHUTDOWN, the persistent cache is protected by a system-generated random password independently of the password that you create when you install the Oracle Key Vault software on an endpoint database. This means the persistent cache will never be an auto-login wallet. It will always be password protected, which provides better security when your password choice is auto-login wallet.

Oracle Key Vault Server Certificate Rotation

Starting with this release, you can rotate certificates for both endpoint and certificates in one operation. This operation does not rotate the console certificates.

The certificates are used to authenticate the Oracle Key Vault server and endpoints. The rotation process pushes the new certificates to all endpoints. The endpoints switch over to using the new certificates as soon as they receive the new certificates. After all the endpoints have received new certificates and switched over, then the Oracle Key Vault switches over to using the new certificate.

The server certificate in Oracle Key Vault lasts 730 days. If you do not rotate the certificate (both server and endpoint certificates), then the endpoints that use the certificate cannot connect to the Oracle Key Vault server. To avoid this scenario, you must rotate the server certificate and re-enroll the endpoint. To avoid this scenario, you can configure the alert to remind you to rotate the certificate before the 730-day limit is up. You can find out the expiry times of the Oracle Key Vault server certificate by checking the Manage Server Certificate page under System tab in the Oracle Key Vault management console. To find the expiry time of the endpoints' certificates, you must navigate to the Endpoints page and check the Certificate Expires column.

If you have a primary-standby or multi-master cluster configuration, then Oracle Key Vault automatically synchronizes the certificates in both systems.

Related Topics

Recover the Candidate Node If There Is a Failure or Error During Node Induction

Starting with this release, you can abort the induction of a candidate node.

Previously, you could not abort induction of a candidate node. This was a problem if you put in the wrong recovery passphrase, IP address, or certificate of the controller node. There is now an Abort button on the Adding Candidate Node for Cluster page for the candidate node that reverts the candidate to its original pre-candidate state. The candidate node cannot be aborted after it has started to receive bundles from the controller node.

Limit Reset of User Password to Recovery Through Email Only

Starting with this release, you can replace a lost password only if an email address is configured for the user who lost the password.

When the user needs to have a password changed, an administrator can send a randomly generated one-time password to the user through the configured email address. Only an option to send a one-time password to user's email address is provided.

In earlier releases, if a user forgot his or her password, another user with equal or higher privileges could create a new password manually to a password, but this password would be known to the user who changed the password. The ability to reset the user password to recovery of email only provides greater security because only the user whose password must be changed will know the new password.

Automatically Update Endpoint Configuration with Changes to Reverse-SSH Tunnels in the Cluster

New reverse-SSH tunnels that an endpoint can use but are created after an endpoint was enrolled now are automatically added to the endpoint configuration, okvclient.ora.

With the addition or deletion of a node in the cluster, like other endpoints, the DBCS endpoints' automatically update the list of node IP addresses in the endpoint configuration. Endpoints created on nodes of the cluster that have been deleted will get their endpoint configuration updates from other nodes in the cluster.

New tunnels are not included in okvclient.ora for existing endpoints, even if that endpoint could use the tunnel and has since been re-enrolled.

Endpoints created on nodes of the cluster that are then deleted don't receive scan list updates.

Upgrade Oracle Key Vault Server with HSM as Root of Trust Without the Need to Reverse Migrate

Starting with this release, upgrades to an HSM-enabled Oracle Key Vault are supported.

In previous releases, upgrading an Oracle Key Vault that was HSM-enabled could not proceed for several reasons. First, if Oracle Key Vault was registered as a client of an HSM that it had to contact through using a host name, after you restarted the Oracle Key Vault server, the Oracle Key Vault DNS service, dnsmasq, was not running when Oracle Key Vault tried to contact the HSM. This resulted in a failure to open the TDE wallet. There was a workaround for this issue as described for Bug 24478865 that required adding DNS server entries to /etc/resolv.conf, but the upgrade process reset this file and so it was not a valid workaround for HSM upgrades. Bug 24478865 has since been resolved and the workaround is no longer necessary. Another issue blocking HSM-enabled Oracle Key Vault upgrades was that for nCipher HSMs, the hardserver service was not running when Oracle Key Vault attempted to open the TDE wallet. This resulted in a failure after the reboot during upgrade. Oracle Key Vault now starts the hardserver service if necessary before opening the wallet. Upgrading with HSM as the root of trust is available when upgrading from versions of Oracle Key Vault version 18.1 and later.

HSM as Root of Trust Improvements

This section describes Oracle Key Vault HSM as Root of Trust improvements .

Validate HSM Setup Periodically

In previous versions of Oracle Key Vault with HSM as Root of Trust, the connectivity to HSM was only validated once during the Oracle Key Vault startup process.

Now the connectivity is checked periodically to validate that the HSM is working properly. If it is not working properly, an Invalid HSM Configuration alert is raised.

Improved Error Reporting for HSM Functionality

Several improvements to error handling for HSM functionality are introduced in this release.

The following improvements were made to the error handling:
  • Reverse migrating from an HSM in Oracle Key Vault release 18.1 in standalone mode (not cluster and not primary-standby) with the same recovery passphrase for the Old Recovery Passphrase and New Recovery Passphrase fields displays an error message such as ORA-20101: Failed to change recovery passphrase. The old and new recovery passphrases can now be the same when reverse migrating.
  • Generic error messages were received when there was an error while applying the bundle. These error messages were made more specific to better diagnose problems.
  • Setting the credential for HSM using the Set Credential button with the same credential twice produced an error. This can now be completed without issues.
  • The error message received when creating the HSM bundle with the wrong HSM credential did not indicate the specific problem. The error messages are now more specific as to the cause of the problem.

RESTful Services Improvements

This section describes improvements to RESTful services in Oracle Key Vault.

KMIP REST Locate Supports Filtering by Key Name

The Oracle Key Vault RESTful service locate command now has a new option to help retrieve the KMIP UUID more easily.

Given a human readable name of the KMIP object, you can find the KMIP identifier associated with the object. The Oracle Key Vault RESTful service now provides the -name option in the locate command to retrieve KMIP UUID more easily because the UUID is difficult to remember. Once you get the UUID by using the -name option using the locate command, you can use this UUID in other KMIP REST calls.

Related Topics

Re-Enroll All Endpoints With a Single RESTful Command

You now can use a single RESTful command, re_enroll_all, to re-enroll all endpoints in one operation.

The re_enroll_all command is useful in Oracle Key Vault deployments that have a large number of endpoints. In previous releases, you had to re-enroll all endpoints one by one, even with the RESTful API, which can be time consuming.

New wallet_root Option for the REST Provision Command

A new wallet_root option has been added to the RESTful service provision command.

Unlike the dir option, the wallet_root option does not create the endpoint name directory. As a result, user can provide the TDE WALLET_ROOT root directory with this option. The user can choose between the wallet_root option or the dir option, based on requirement.

Refresh Cached Oracle Key Vault Configuration Periodically In Long Running Processes

In previous releases, the endpoint database's gen0 process did not pick up new okvclient.ora values periodically.

As a result, changes to okvclient.ora parameters (such as the SERVER list, PKCS11_CACHE_TIMEOUT, PKCS11_PERSISTENT_CACHE_TIMEOUT, PKCS11_PERSISTENT_CACHE_REFRESH_WINDOW, and so on) were not picked up even when the key was refreshed from Oracle Key Vault. Now, per process, if the time since okvclient.ora was last read is greater than the new PKCS11_CONFIG_PARAM_REFRESH_INTERVAL value, in minutes, the next time that an in-memory cache key expires and has to be refreshed either from the persistent cache or from the Oracle Key Vault server, okvclient.ora is re-read and the changed values are incorporated by the process.