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.

Note:

This is the terminal release of Oracle Key Vault release 18.

1.1 About These Release Notes

These release notes provide information that you should be aware of before using Oracle Key Vault.

The release notes cover changes in this new release, how to download the Oracle Key Vault software and documentation, known issues, considerations, supported Oracle Database versions, and critical patches that have been included in this release.

1.2 Changes in This Release for Oracle Key Vault

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

1.2.1 Changes for Oracle Key Vault Release 21.5

Oracle Key Vault release 21.5 introduces several new features.

1.2.1.1 Support for SSH Public Key Authentication using SSH User Keys from Oracle Key Vault

Starting in Oracle Key Vault release 21.5, you can use SSH key-based authentication with a key pair stored only in Oracle Key Vault.

The Oracle Key Vault PKCS#11 library supports SSH public key authentication using a SSH key pair that is stored only in Oracle Key Vault. The centralized management of SSH user keys in Oracle Key Vault simplifies key life-cycle management, enables key governance and makes it easier to enforce policies. You can centrally perform actions such as, rotating the keys and revoking them when needed. This also allows you to minimize the risks that are associated with the SSH user keys footprint on local disks.

1.2.1.2 Automatic Purging of Audit Records Based on a Retention Policy

Starting in Oracle Key Vault release 21.5, you can now purge the old audit records automatically based on a retention policy.

You can now better manage the disk space consumed by Oracle Key Vault audit records without the need to manually delete them once they are deemed no longer needed. You can configure Oracle Key Vault to automatically purge older audit records based on a retention policy. For example, you can configure and apply a policy to automatically purge audit records that are older than 180 days.

1.2.1.3 Ability to Rotate Endpoint Certificates

Starting in Oracle Key Vault release 21.5, you can rotate an endpoint in order to increase its certificate validity without incurring endpoint downtime.

With Oracle Key Vault release 21.5, you can rotate an endpoint in order to increase its certificate validity without incurring endpoint downtime. Previously, this could only be done by re-enrolling the endpoint. You can choose to rotate multiple endpoints at once if required. Rotating an endpoint certificate this way is independent of the CA or server/node certificate rotation processes.

Related Topics

1.2.1.4 Endpoint and Endpoint Group Privileges Support for LDAP Users

Starting in Oracle Key Vault release 21.5, you can grant the endpoint and endpoint group privileges to LDAP users through the LDAP group mappings.

The privileges to the LDAP users are granted through the LDAP groups mappings. You map the endpoint or endpoint group privileges to an LDAP group. LDAP users that are members of this group are granted the mapped endpoint or endpoint group privileges at the time of login.

1.2.1.5 User Account Management

Starting in Oracle Key Vault release 21.5, you can configure the user account profile parameters to meet your corporate user management security policies for the Oracle Key Vault users.

User account profile parameters govern the rules and requirements for the user passwords, and the account lockout behavior of Oracle Key Vault users. These settings apply to Oracle Key Vault users that are created locally. For LDAP users, the user account management policies are managed in the LDAP directory server.

Oracle Key Vault now also supports unlocking of a user account through a password reset. An Oracle Key Vault administrator can unlock a user account by resetting the user’s password.

Related Topics

1.2.1.6 Severity based Alert Categorization

Starting in Oracle Key Vault release 21.5, alerts are categorized based on their severity levels to improve ease of administration.

Oracle Key Vault supports several types of alerts. Oracle Key Vault now categories these alerts to one of the severity levels: CRITICAL, HIGH, MEDIUM, and LOW. The home page of the Oracle Key Vault management console now displays the unresolved alerts in the order of their severity. Oracle Key Vault administrators can now easily identify most critical alerts that need immediate attention to ensure operational continuity.

Related Topics

1.2.1.7 Displaying Endpoint Group Membership Column in Endpoint Metadata Report

Starting with Oracle Key Vault release 21.5, additional column for Endpoint Group Membership is available in Endpoint Metadata Report.

The Endpoint Metadata Report displays endpoint information and deployment configuration detail. The Metadata Report now displays the Endpoint Group Membership column.

The Endpoint Group Membership information is useful when:
  • Granting privileges to Endpoint group
  • Performing the Endpoint rotation

1.2.1.8 Ability to Determine Time of Last Endpoint Activity


Starting in Oracle Key Vault release 21.5, you can quickly determine when an endpoint was last active by checking the Endpoints page on the Oracle Key Vault Management Console.

Starting in Oracle Key Vault release 21.5, you can determine when an endpoint was last active from the Oracle Key Vault Management Console by navigating to the “Endpoints” page and checking the “Last Active Time” column for that endpoint. This information can be useful in quickly determining which endpoints are unused. Previously, the only way to glean this information was from the endpoint activity reports (in particular, in a multi-master cluster, by consolidating all of the endpoint activity reports from all nodes of the cluster).

1.2.1.9 UEFI Support for OCI marketplace Image

Starting in Oracle Key Vault release 21.5, the Oracle Key Vault OCI marketplace images are available in UEFI mode only.

The OCI marketplace images of the earlier versions of Oracle Key Vault continue to use the BIOS mode.

1.2.1.10 Separate Alerts for CA Certificate Expiration and Server/Node Certificate Expiration

Starting in Oracle Key Vault release 21.5, you can configure the alerts for the CA certificate expiration and server/node certificate expiration separately.

You can configure different threshold values for these alerts. The default threshold value for CA certificate expiration is 90 days, while that for server/node certificate expiration is 60 days. Having separate alerts makes it easier to determine when a server/node certificate rotation is to be performed. The server/node certificate rotation is short and quick process performed on a per-node basis, as opposed to a CA certificate rotation which affects the entire Oracle Key Vault deployment and involves multiple steps. Previously, a single alert type 'Oracle Key Vault Server Certificate expiration' was raised when either the CA or the server/node certificate was expiring within the configured server certificate expiration threshold.

1.2.1.11 Support for Cluster Management and Monitoring using RESTful Services Utility

Starting in Oracle Key Vault release 21.5, you can deploy, manage, and monitor the multi-master cluster using RESTful services utility.

Using the RESTful Services Utility, you can now perform several cluster management operations including creating a cluster, adding or deleting a node, enabling or disabling a node. You can also monitor and manage the cluster services and replication links between nodes using RESTful services utility.

The new commands are as follows:

  • okv cluster node create
  • okv cluster node status
  • okv cluster node add
  • okv cluster node abort-pairing
  • okv cluster link enable
  • okv cluster link disable
  • okv cluster node cancel-disable
  • okv cluster node update
  • okv cluster service start
  • okv cluster service stop
  • okv cluster service monitor
  • okv cluster link enable
  • okv cluster link disable
  • okv cluster link monitor

1.2.1.12 Support for System Resources Monitoring using RESTful Services Utility

Starting in Oracle Key Vault release 21.5, you can obtain the current and historical utilization metrics of the system resources such as CPU and memory using RESTful services utility. These system metrics would help you appropriately configure system resources for the Oracle Key Vault servers to meet the performance and scalability requirements of your deployment.

Using the RESTful services utility, you can obtain the information about the:
  • Configured system resources (CPU and memory)
  • CPU and memory utilization metrics over a specified period, including load averages

The new or updated commands are as follows:

  • okv metrics server get
  • okv server status get
  • okv server info get

Related Topics

1.2.1.13 RESTful Services Utility Commands to Support from Nested JSON Level

Starting in Oracle Key Vault release 21.5, you can now specify custom-attributes and certain KMIP attributes as the command line options when using RESTful services utility to create, register, fetch and locate security objects.

In earlier releases, commands that use the attributes or custom-attributes could only be executed using the JSON input method only. The RESTful services utility is now enhanced to support the passing of attributes and custom-attributes as the command line options for the commands to create or register security objects. These commands also support simplified variants of the complex input.

The KMIP attributes "activation date" and "deactivation date" are now exposed as the command line options --activation-date and --deactivation-date respectively. You can pass the custom-attributes using the new command line option --custom-attribute. Several RESTful services utility commands also support simplified and complex format on name and custom attribute.

The following commands have been updated to accommodate this enhancement:

  • okv managed-object key create
  • okv managed-object key register
  • managed-object secret register
  • okv managed-object certificate register
  • okv managed-object certificate-request register
  • okv managed-object opaque register
  • okv managed-object public-key register
  • okv managed-object private-key register
  • okv managed-object object fetch
  • okv managed-object object locate

Related Topics

1.2.1.14 Support for Text Output Format in RESTful Services Utility

Starting in Oracle Key Vault release 21.5, several RESTful services utility commands are enhanced to support the output in the text format.

In previous releases, the RESTful services utility commands always produced output in the JSON format. Now, you can use the new command line option –output_format to generate the command output in the text format. The text output format helps simplify the creation of automation scripts such as when the output of a command serves as input for another command.

Supported values for the --output_format option are:
  • json (default value)
  • text

The following commands have been updated to accommodate this enhancement:

  • okv managed-object certificate get
  • okv managed-object certificate register
  • okv managed-object certificate-request get
  • okv managed-object certificate-request register
  • okv managed-object key create
  • okv managed-object key get
  • okv managed-object key register
  • okv managed-object object activate
  • okv managed-object object destroy
  • okv managed-object object locate
  • okv managed-object object revoke
  • okv managed-object opaque get
  • okv managed-object private-key register
  • okv managed-object public-key get
  • okv managed-object public-key register
  • okv managed-object secret get
  • okv managed-object secret register
  • okv managed-object wallet add-member
  • okv managed-object wallet delete-member
  • okv managed-object wallet list

Related Topics

1.2.2 Changes for Oracle Key Vault Release 21.4

Oracle Key Vault release 21.4 introduces several new features.

1.2.2.1 Ability to Control the Extraction of Symmetric Encryption Keys from Oracle Key Vault

Starting in Oracle Key Vault release 21.4, to strengthen the protection of symmetric encryption keys, you now can restrict these keys from leaving Oracle Key Vault.

This restriction applies to the key material of the symmetric keys, but not its metadata. For example, Transparent Database Encryption (TDE) master encryption keys are stored in Oracle Key Vault. When an endpoint needs to decrypt the key, the PKCS#11 library fetches the TDE master encryption key from Oracle Key Vault to perform the decryption. If your site requires that symmetric keys never leave Oracle Key Vault, then you can configure these keys to remain within Oracle Key Vault during operations. In this case, the PKCS#11 library will send the encrypted data encryption key to Oracle Key Vault. Decryption is then performed within Oracle Key Vault and afterward, the plaintext data encryption key is returned to the PKCS#11 library. The Oracle Key Vault PKCS#11 library performs the encryption and decryption operation within Oracle Key Vault if the TDE master encryption key is restricted to leave Oracle Key Vault, or if it cannot be extracted from Oracle Key Vault.

To control whether symmetric encryption keys can be retrieved (extracted) from Oracle Key Vault, you can use the Oracle Key Vault management console, RESTful services utility commands, the C SDK APIs, and Java SDK APIs.

The following Oracle Key Vault RESTful services utility commands have been updated to accommodate this enhancement:

  • okv managed-object attribute get
  • okv managed-object attribute get-all
  • okv managed-object attribute list
  • okv managed-object attribute modify
  • okv managed-object key create
  • okv managed-object key register
  • okv managed-object object locate

New APIs for the C SDK to manage extractable attribute:

  • okvAttrAddExtractable
  • okvAttrAddNeverExtractable
  • okvAttrGetExtractable
  • okvAttrGetNeverExtractable

New APIs for the Java SDK to manage extractable attribute:

  • okvAttrAddExtractable
  • okvAttrAddNeverExtractable
  • okvAttrGetExtractable
  • okvAttrGetNeverExtractable

1.2.2.2 Support for Cryptographic Operations in RESTful Services Utility

Oracle Key Vault release 21.4 adds the support for performing cryptographic operations within Oracle Key Vault.

You can use either RESTful services utility commands or C and Java SDK to perform encryption and decryption operations.

This enhancement accommodates the use of symmetric keys that have been configured to not be extracted from Oracle Key Vault.

The new commands are as follows:

  • okv crypto data decrypt
  • okv crypto data encrypt

Related Topics

1.2.2.3 C and Java SDK APIs for Cryptographic Operations

Oracle Key Vault Client SDK release 21.4 adds the support for cryptographic operations.

Oracle Key Vault release 21.4 adds support for performing encryption and decryption cryptographic operations within Oracle Key Vault.

You can use either RESTful services utility commands or C and Java SDK to perform encryption and decryption operations.

C SDK APIs

  • KMIP cryptographic operations are as follows:
    • okvDecrypt
    • okvEncrypt
  • Attribute operations are as follows:
    • okvAttrAddExtractable
    • okvAttrAddNeverExtractable
    • okvAttrGetExtractable
    • okvAttrGetNeverExtractable
  • Cryptographic utility operations are as follows:
    • okvCryptoContextCreate
    • okvCryptoContextFree
    • okvCryptoContextGetAuthEncryptionAdditionalData
    • okvCryptoContextGetAuthEncryptionTag
    • okvCryptoContextGetBlockCipherMode
    • okvCryptoContextGetIV
    • okvCryptoContextGetPadding
    • okvCryptoContextGetRandomIV
    • okvCryptoContextSetAuthEncryptionAdditionalData
    • okvCryptoContextSetAuthEncryptionTag
    • okvCryptoContextSetBlockCipherMode
    • okvCryptoContextSetIV
    • okvCryptoContextSetPadding
    • okvCryptoContextSetRandomIV
    • okvCryptoResponseGetAuthEncryptionTag
    • okvCryptoResponseGetDecryptedData
    • okvCryptoResponseGetEncryptedData
    • okvCryptoResponseGetIV
    • okvDecryptResponseCreate
    • okvDecryptResponseFree
    • okvEncryptResponseCreate
    • okvEncryptResponseFree

Java SDK APIs

  • KMIP cryptographic operations are as follows:
    • okvDecrypt
    • okvEncrypt
  • Attribute operations are as follows:
    • okvAttrAddExtractable
    • okvAttrAddNeverExtractable
    • okvAttrGetExtractable
    • okvAttrGetNeverExtractable
  • Cryptographic utility operations are as follows:
    • okvCryptoContextCreate

1.2.2.4 Enhancements to Certificate Management

Starting in Oracle Key Vault release 21.4, several enhancements to the management of certificates are available.

The enhancements are as follows:

  • Support for using an Oracle Key Vault certificate authority (CA) certificate that has been signed by an external certificate signing authority: You can choose to have the CA certificate issued by a third-party signing authority. This option can be exercised by first generating a certificate signing request (CSR), having that CSR signed by the external signing authority, and then uploading that signed CA to Oracle Key Vault. You will then be required to perform a CA certificate rotation so that all certificates on board Oracle Key Vault (endpoint certificates as well as those used for communication between Oracle Key Vault multi-master cluster nodes) are re-issued by the new CA. In previous releases, the Oracle Key Vault CA certificate was always self-signed.
  • Ability to configure a validity period of Oracle Key Vault self-signed root CA certificate: You can configure the certificate validity period of the Oracle Key Vault self-signed CA. The new validity period would take effect the next time a CA certificate rotation is performed. Previously, this value was fixed and unchangeable.
  • In multi-master cluster environments, the ability to set the order in which endpoints are rotated during the Oracle Key Vault CA certificate rotation process: This enhancement enables you to configure the order in which endpoints are rotated during a CA certificate rotation. Starting in this release, the endpoints are, by default, rotated in order of endpoint certificate expiry (that is, those expiring soonest are rotated first). You can also choose to order the endpoint rotation by providing a cluster subgroup priority list before initiating a CA certificate rotation. Then, during the CA certificate rotation process, endpoints that belong to cluster subgroups higher in the priority list are rotated before those in lower-priority cluster subgroups. In previous releases, when a CA certificate rotation was performed, the endpoints were rotated in random order.
  • Ability to configure a batch number of endpoints rotated during an Oracle Key Vault CA certificate rotation: You can configure the number of endpoints that can be in the Updating to current certificate issuer state at a given point in the CA certificate rotation process. You can configure this value based on the number of endpoints in the Oracle Key Vault configuration. Previously, this value was static and release dependent (for example, at most, 15 endpoints could be in this state in Oracle Key Vault release 21.3).
  • Ability to rotate Oracle Key Vault server and node certificates: Starting in this release, the certificates that are used for communication between Oracle Key Vault systems (cluster nodes in a multi-master cluster environment, or primary and standby environments), and for communication between an Oracle Key Vault system and its endpoints are now known as server certificates (in standalone or primary-standby environments) and node certificates (in multi-master cluster environments). This enhancement provides greater operational flexibility, because you now can choose different validity periods for the Oracle Key Vault CA certificate and server and node certificates. You then can rotate the server and node certificates as often as needed, without needing to go through the entire CA certificate rotation process.

Related Topics

1.2.2.5 Support for Policy Based Automatic Purging of Old Oracle Key Vault Backups

Starting in Oracle Key Vault release 21.4, you can create a policy to schedule the removal of one or more remote backups.

You can now better manage the disk space consumed by Oracle Key Vault backups on remote backup destination servers without the need to manually delete them once they are deemed no longer needed. You can configure Oracle Key Vault to automatically purge older backups from a remote backup destination based on a policy. For example, you can configure and apply a policy to a remote backup destination to automatically purge backups that are older than 30 days unless the backup is among the 10 more recent backups. In addition, you can now manually delete a local Oracle Key Vault backup.

1.2.2.6 Support for Policy Based Automatic Purging of Old Oracle Key Vault Backups in RESTful Services Utility

Starting in Oracle Key Vault release 21.4, you can manually purge the local Oracle Key Vault backup or create a destination policy to purge one or more remote backups.

The following commands have been updated:

  • okv backup destination create
  • okv backup destination update

The following commands are new:

  • okv backup destination delete-backup
  • okv backup destination-policy create
  • okv backup destination-policy delete
  • okv backup destination-policy get
  • okv backup destination-policy list
  • okv backup destination-policy list-purged-backups
  • okv backup destination-policy update
  • okv backup destination resume-policy
  • okv backup destination suspend-policy

1.2.2.7 Ability to Restrict Oracle Key Vault Administrative Role Grants

Starting in Oracle Key Vault release 21.4, you can control whether a grantee of an Oracle Key Vault administrative role can grant the role to other Oracle Key Vault users.

In previous releases, the Oracle Key Vault administrative roles (System Administrator, Key Administrator, and Audit Manager) could be granted to another Oracle Key Vault user by any user who currently has the role. Starting with this release, when an administrator grants the role to another user, the administrator can restrict how the grantee user can in turn grant the role to other users. This enhancement improves overall user security and helps to adhere to good least privileges practices.

1.2.2.8 Enhancements to Endpoint, Endpoint Group, and Wallet-Related RESTful Services Utility Commands

Starting in Oracle Key Vault release 21.4, additional commands are available to enable you to perform more operations with endpoints, endpoint groups, and wallets.

The new commands are as follows:

  • okv admin endpoint get
  • okv admin endpoint list
  • okv admin endpoint list-objects
  • okv admin endpoint resume
  • okv admin endpoint suspend
  • okv manage-access endpoint-group get
  • okv manage-access endpoint-group list
  • okv manage-access wallet add-object
  • okv manage-access wallet get
  • okv manage-access wallet list
  • okv manage-access wallet list-objects
  • okv manage-access wallet remove-object

The commands to list objects for an endpoint (okv admin endpoint list-objects) and a wallet (okv admin wallet list-objects) provide an option to show or hide the wallet membership of the objects. Omitting wallet membership information of objects can improve command's performance.

1.2.2.9 Support for Updating the Configuration of Endpoints

Starting in Oracle Key Vault release 21.4, you can update the endpoint configuration parameters and endpoint settings for keys and secrets of an endpoint using the RESTful service utility command okv admin endpoint update.

The endpoint configuration parameters includes various PKCS#11 settings and endpoint settings for keys and secrets includes the extractable attribute setting for the new symmetric keys.

1.2.2.10 RESTful Commands to Set Date and Time Accommodate ISO 8601 Standard

Starting in Oracle Key Vault release 21.4, the duration time interval settings will follow the ISO 8601 standard, and the fixed format for date and time settings are compatible with ISO 8601 when using RESTful commands.

You can specify the following formats:

  • duration (follows the ISO 8601 standard)
  • timestamp (is in a format that is compatible with the ISO 8601 standard)
  • now (represents the current time when a command is run)

You can use these formats in the following combinations:

  • timestamp
  • now
  • timestamp + duration
  • now + duration

The timestamp format that has been used in previous releases is still supported.

The following commands have been updated for this enhancement:

  • okv backup schedule create
  • okv backup schedule update
  • okv managed-object attribute add
  • okv managed-object attribute delete
  • okv managed-object attribute modify
  • okv managed-object certificate-request register
  • okv managed-object key register
  • okv managed-object object locate
  • okv managed-object opaque register
  • okv managed-object private_key register
  • okv managed-object public-key register
  • okv managed-object secret register

1.2.2.11 Support for Command Line Help for the RESTful Services Utility

Starting in Oracle Key Vault release 21.4, you can find the command line help information about the RESTful services utility commands.

This enhancement enables you to find the detailed help information about the various categories, resources, and actions that are supported for all Oracle Key Vault RESTful services utility commands. The help information shows the command's syntax, and definitions for the available categories, resources, and actions as well as the configuration parameters that are applicable to all the commands.

1.2.2.12 Preferred KMIP Version Updated to 1.1 for Oracle Key Vault KMIP Server

Oracle Key Vault KMIP Server now uses KMIP protocol version 1.1 as its preferred version.

In prior releases of Oracle Key Vault, even though the KMIP server accepted and processed client requests with KMIP version 1.1, it always sent the server response with the KMIP version 1.0. Now, the KMIP server sends a response with the protocol version with which the KMIP request was made. The KMIP server is also enhanced to return an error for client requests that are made with unsupported KMIP version. Such error responses are returned using the server’s preferred KMIP version which is currently set to 1.1.

1.2.2.13 Client IP Address in the Oracle Key Vault Audit Trail

Starting in Oracle Key Vault release 21.4, the Oracle Key Vault audit trail has one new field: Client IP.

The Oracle Key Vault audit trail contains fields to capture information such as the name and type of the entity that performed an operation, the time the operation was performed, the node in which an operation was performed, and the result of the operation. The addition of the Client IP field enables users to better find where operations were performed, particularly in Cloud environments.

1.2.2.14 Client Endpoint File Updated When A KMIP Server Operation Is Executed Using SDK

The client endpoint file okvclient.ora is now updated when a KMIP server operation is executed using the SDK.

Prior to Oracle Key Vault release 21.4, the client endpoint file okvclient.ora was not updated whenever a KMIP server operation was performed using the SDK. Now, the client endpoint file okvclient.ora will be updated if there are any new endpoint updates whenever a KMIP server operation is performed using the Oracle Key Vault client SDK.

1.2.2.15 Support for Additional Monitoring Information Through SNMP

Starting in Oracle Key Vault release 21.4, additional monitoring information is available through the SNMP nsExtendOutputFull MIB base variable.

The nsExtendOutputFull MIB base variable now returns the following values:

  • Oracle Audit Vault monitor status
  • Oracle Audit Vault agent status
  • Server or CA certificate expiration information (whichever certificate expires sooner)

1.2.3 Changes for Oracle Key Vault Release 21.3

Oracle Key Vault release 21.3 introduces several new features.

1.2.3.1 Ability to Configure Other HSMs for Oracle Key Vault

Starting with Oracle Key Vault release 21.3, in addition to the Thales Luna Network HSM version 7000, Entrust nShield Connect + and XC models, and Utimaco’s SecurityServer 4.31.1 HSMs, you can configure other HSMs that have been certified to work with Oracle Key Vault.

Those additional HSMs may or may not be already certified by the HSM vendor.

This feature gives you a much wider range of HSM products that you can use with Oracle Key Vault. The configuration is slightly different from the configuration of the Thales Luna Network HSM version 7000, Entrust nShield Connect + and XC models, and Utimaco’s SecurityServer 4.31.1 HSMs in that you will need to work with your HSM vendor with regard to the requirements that they must fulfill in order for their HSM to work with Oracle Key Vault. After you have successfully integrated the HSM with Oracle Key Vault, you will be able to perform all the tasks that you normally perform with the Thales Luna Network HSM version 7000, Entrust nShield Connect + and XC models, and Utimaco’s SecurityServer 4.31.1 HSMs, such as upgrade operations, backup and restore operations, and reverse migrations.

1.2.3.2 Easier Oracle Audit Vault and Database Firewall Integration with Oracle Key Vault

Starting in Oracle Key Vault release 21.3, steps in the integration of Oracle Audit Vault and Database Firewall (AVDF) with Oracle Key Vault have been automated.

In previous releases, an Oracle Key Vault administrator had to manually perform steps such as downloading and installing the AVDF agent to perform this integration. Now, much of this integration work is built in to the Oracle Key Vault management console, enabling an administrator to perform the integration easily and quickly.

1.2.3.3 Enhancements for RESTful Services Utility Commands Used for Registration

In Oracle Key Vault release 21.3, RESTful services utility commands that are used for the registration of managed objects will have additional attributes.

The affected commands are as follows:

  • okv managed-object certificate register
  • okv managed-object certificate-request register
  • okv managed-object key register
  • okv managed-object opaque register
  • okv managed-object private-key register
  • okv managed-object public-key register
  • okv managed-object secret register

In previous releases, these commands provided two attributes, name and contactInfo. In this release, in addition to these two attributes, the following new attributes are included:

  • activationDate
  • deactivationDate
  • processStartDate
  • protectStopDate

Related Topics

1.2.3.4 Alert for Fast Recovery Area Space Utilization

Starting in Oracle Key Vault release 21.3, an alert will be generated when the Fast Recovery Area Space utilization of the Oracle Key Vault's embedded database exceeds the configured threshold value.

By default, the configured threshold value is 70 and the alert is available for standalone, multi-master cluster, and primary-standby environments. The new alert enables you to better monitor the Fast Recovery Area space usage of the Oracle Key Vault's embedded database.

Related Topics

1.2.3.5 Cluster Redo Shipping Status Alert Message Change

Starting in Oracle Key Vault release 21.3, the Cluster Redo Shipping Status alert notification message has changed.

In previous releases, users were alerted only when the redo-shipping status was active (up) or inactive (down). The message now, in addition to this information, indicates whether the node in the cluster is operating in read-only mode or is no longer in read-only mode.

1.2.4 Changes for Oracle Key Vault Release 21.2

Oracle Key Vault release 21.2 introduces new features that are related to installation and upgrade operations.

1.2.4.1 Certificate and Secret Objects Expiration Alerts

Starting with this release, you can configure alert notifications for the expiration of certificate and secret objects.

In previous releases, expiration alerts for all managed objects shared a common configuration under the Key Rotations alert. Starting with this release, you can separately configure the expiration alerts for certificate and secret objects. The expiration alerts for the certificate and secret objects are no longer reported as Key Rotations alerts. Similar to alerts such as those for cluster components or user password expiration, you can set this type of alert to notify users when the deactivation date for a certificate or secret object is within its threshold value.

The new alerts for certificate and secret objects are as follows:

  • Certificate Object Expiration
  • Secret Object Expiration

The object expiration alerts are now raised only when the object is in the PRE-ACTIVE or ACTIVE state. Previously, they were raised regardless of the object state.

The object expiration alerts are now deleted when an object is revoked or destroyed. Previously, they were deleted when object was destroyed.

1.2.4.2 New C and Java SDK APIs for Certificates, Certificate Requests, Private Keys, and Public Keys

In Oracle Key Vault release 21.2, new APIs enable you to perform operations such as registering and fetching objects, and adding attributes to those objects (for example, length, type, ID, subject, issuer, and algorithm).

C SDK APIs

Registration and fetch operations are as follows:

  • okvGetCertificate

  • okvGetCertificateRequest

  • okvGetPrivateKey

  • okvGetPublicKey

  • okvRegCertificate

  • okvRegCertificateRequest

  • okvRegPrivateKey

  • okvRegPublicKey

Attribute operations are as follows:

  • okvAttrAddCertLen

  • okvAttrAddCertType

  • okvAttrAddDigitalSignAlgo

  • okvAttrAddX509CertId

  • okvAttrAddX509CertIss

  • okvAttrAddX509CertIssAltName

  • okvAttrAddX509CertSubj

  • okvAttrAddX509CertSubjAltName

  • okvAttrGetCertLen

  • okvAttrGetCertType

  • okvAttrGetDigitalSignAlgo

  • okvAttrGetX509CertId

  • okvAttrGetX509CertIdIssuerLen

  • okvAttrGetX509CertIdSerialNoLen

  • okvAttrGetX509CertIss

  • okvAttrGetX509CertIssAltName

  • okvAttrGetX509CertIssAltNameLen

  • okvAttrGetX509CertIssDNLen

  • okvAttrGetX509CertSubj

  • okvAttrGetX509CertSubjAltName

  • okvAttrGetX509CertSubjAltNameLen

  • okvAttrGetX509CertSubjDNLen

Java SDK APIs

Registration and fetch operations are as follows:

  • okvGetCertificate

  • okvGetCertificateRequest

  • okvGetPrivateKey

  • okvGetPublicKey

  • okvRegCertificate

  • okvRegCertificateRequest

  • okvRegPrivateKey

  • okvRegPublicKey

Attribute operations are as follows:

  • okvAttrAddArchiveDate

  • okvAttrAddCertLen

  • okvAttrAddCertType

  • okvAttrAddDigitalSignAlgo

  • okvAttrAddInitialDate

  • okvAttrAddLastChangeDate

  • okvAttrAddState

  • okvAttrAddX509CertId

  • okvAttrAddX509CertIss

  • okvAttrAddX509CertIssAltName

  • okvAttrAddX509CertSubj

  • okvAttrAddX509CertSubjAltName

  • okvAttrGetCertLen

  • okvAttrGetCertType

  • okvAttrGetDigitalSignAlgo

  • okvAttrGetX509CertId

  • okvAttrGetX509CertIss

  • okvAttrGetX509CertIssAltName

  • okvAttrGetX509CertSubj

  • okvAttrGetX509CertSubjAltName

1.2.4.3 New and Changed RESTful Services Utility Commands

Several new and changed okv managed-object RESTful services utility commands are available starting with this release.

The new okv managed-object RESTful services commands, which add support for get and register operations for certificate requests, private keys, and public keys, are as follows:

  • okv managed-object certificate-request get
  • okv managed-object certificate-request register
  • okv managed-object private-key get
  • okv managed-object private-key register
  • okv managed-object public-key get
  • okv managed-object public-key register

The changed okv managed-object RESTful services commands are as follows:

  • okv managed-object certificate register
  • okv managed-object object locate

Related Topics

1.2.4.4 Changes in the Oracle Key Vault Management Console

In Oracle Key Vault release 21.2, the Oracle Key Vault management console user interface has had minor changes throughout.

These changes are the result of modified terms, updates to the current release, and enhancements for better usability. The overall interface has not had major changes.

1.2.5 Changes for Oracle Key Vault Release 21.1

Oracle Key Vault release 21.1 introduces several new features.

1.2.5.1 Dual NIC Network Interface Support

Starting with this release, Oracle Key Vault supports the use of two network interfaces, referred to as dual NIC configuration.

In a dual NIC configuration, Oracle Key Vault combines the two network interfaces into a single logical interface using the Linux NIC bonding mechanism to provide redundancy at the network layer. The dual NIC configuration maintains the network availability of an Oracle Key Vault in case one of the interfaces becomes unavailable. Depending upon the dual NIC configuration mode, load balancing of the network traffic may also be achieved.

This type of configuration is particularly useful in large Oracle Key Vault deployments where need for operational continuity is higher despite physical or software failures. Configuring a dual NIC network interface helps to avoid the scenario where, for example, a network interface associated with an Oracle Key Vault server becomes unavailable, which can result in a loss of communication between the Oracle Key Vault nodes and between endpoints and Oracle Key Vault server.

In previous releases, Oracle Key Vault supported only one network interface. When you install and configure Oracle Key Vault in this release, you have the option of using a single network interface (Classic mode) or using dual NIC mode.

1.2.5.2 LDAP User Authentication and Authorization in Oracle Key Vault

Starting with this release, you can configure authentication and authorization of Oracle Key Vault users to be centrally managed in a Microsoft Active Directory.

This feature benefits large deployment environments where enterprise users are centrally managed in a Microsoft Active Directory. Centrally managing users, as opposed to creating user accounts in different systems and applications, is not only easier and more efficient for administrators, it improves compliance, control, and security. You enable the Microsoft Active Directory users to authenticate with Oracle Key Vault through the use of their directory credentials. You manage the authorization of the directory users in Oracle Key Vault through mapping definitions between Microsoft Active Directory groups and Oracle Key Vault administrative roles or user groups. When a directory user successfully logs in to Oracle Key Vault the first time, Oracle Key Vault automatically creates an Oracle Key Vault user account for this user.

1.2.5.3 RESTful Services Utility Command-Line Interface for Appliance Management

In Oracle Key Vault release 21.1, the the RESTful service command-line interface has been expanded and redesigned to provide more functionality.

This redesign includes the following:

  • Structured and simplified command-line interface with the following format:
    okv category resource action configuration-options command-options 
  • Profile support in configuration file to centrally administer multiple Oracle Key Vault endpoints.
  • JSON support for command input and output.
  • New commands to support system management tasks and monitoring of deployments, in addition to the enhancements for the current functionality for endpoints, wallets, and security objects.

In previous releases, the RESTful command-line interface covered only endpoint, wallet, and security object management commands. The addition of system management commands, which include commands for backup operations and server operations for standalone, multi-master, and primary-standby environments, benefits large deployments where the automation of these types of configuration is needed.

The previous RESTful services APIs are still supported.

1.2.5.4 Support for SFTP to Transfer External Backups

Oracle Key Vault now supports the use of SSH Secure File Transfer Protocol (SFTP) for the transfer of (scheduled) external backups to remote backup destinations.

SFTP enables the use of ZFS Storage Appliance as a backup destination. The use of Secure Copy Protocol (SCP) is also supported.

1.2.5.5 Development Using the Java SDK

This release introduces a new Java language software development kit that you can use to integrate custom endpoints with the Oracle Key Vault server.

The Java SDK enables developers to create their own custom endpoint integration solutions for Oracle Key Vault.

1.2.5.6 Development Using the C SDK

This release introduces a new C language software development kit that you can use to integrate custom endpoints with the Oracle Key Vault server.

The C SDK allows developers to create their own custom endpoint integration solutions for Oracle Key Vault.

1.3 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.3.1 Downloading the Oracle Key Vault Installation Software

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

  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 21.5.0.0.0 or click the +Add to Cart button next to the Oracle Key Vault 21.5.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, after you have read the terms and restrictions and agree with them, 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 file:

    • Vpart_number.iso (Oracle Key Vault 21.5.0.0.0)

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

    The listing for the ISO file expands to display the SHA-1 and SHA-256 checksum reference number for the ISO file.

  9. Copy the SHA-256 checksum reference number and store it for later reference.
  10. Click Download and select a location to save the ISO file. 
  11. Click Save.

    The size of the ISO file 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 file is downloaded to the specified location, verify the SHA-256 checksums of the downloaded file:
    $ sha256sum Vpart_number.iso

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

  13. Optionally, burn the Vpart_number.iso file to a DVD-ROM disc and then label the discs:
    OKV 21.5
You can now install Oracle Key Vault on a server machine.

1.3.2 Downloading the Oracle Key Vault Documentation

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

1.4 Known Issues

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

1.4.1.1 Assigning Default Wallet Fails if an Endpoint Already Has Access to Same Wallet

Issue: If an endpoint already has access to a wallet, then making this wallet as a default wallet fails. As a side-effect, current default wallet setting is also removed.

Workaround: Remove the endpoint's access to the wallet before assigning it as a default wallet of the endpoint.

Bug Number: 31416663

1.4.1.2 Certificate Attributes Will Not Get Uploaded By okvutil For Windows Endpoints Using 11.2.0.4 DB

Issue: When you upload an object containing certificates to the Oracle Key Vault server from a Windows endpoint system that has Oracle Database release 11.2.0.4, the cryptographic algorithm and cryptographic length will not be displayed on the management console for such certificates uploaded.

Workaround: If you wish the cryptographic algorithm and cryptographic length to be displayed for certificates, then consider uploading such objects from a different combination of endpoint platform or Oracle Database version.

Bug Number: 32855953

1.4.1.3 DB Crashes On Windows When Using PKCS#11 To Perform Certificate Rotation

Issue: When performing an Oracle Key Vault certificate rotation operation, the endpoint certificates are regenerated and then are fetched by the endpoint, sent from the server along with the normal KMIP response. Endpoints can fetch the new certificates either via an okvutil operation or by the Oracle Database which is utilizing the PKCS#11 library. On Windows, if the certificates are fetched by an endpoint using the PKCS#11 library, the database may crash.

Workaround: Before starting the certificate rotation operation, prepare for the event by shutting down endpoints on Windows machines. Get these endpoints’ new certificates by re-enrolling the endpoints once certificate rotation has proceeded to the stage where there is a message on the Oracle Key Vault management console stating Automatic certificate update of endpoints is in progress.

Bug Number: 33037993

1.4.1.4 Deleting a Default Wallet Causes Associated Endpoint to Not Be Able to Execute OKVUTIL LIST

Issue: When deleting a virtual wallet, if that virtual wallet is the default wallet of an endpoint, the endpoint may not be able to execute okvutil list. This is because when the endpoint searches for the wallet, it is unable to find it and therefore generates an error.

Workaround: Do not delete a virtual wallet without first being sure that no endpoint is currently using it as its default wallet. If the wallet is deleted, be sure to remove the default wallet from the endpoint via the Endpoint Details page and re-enroll the endpoint.

Bug Number: 30699255

1.4.1.5 "Expiring In" Field Not Updated After Server Certificate Rotation

Issue: After certificates are rotated, the Expiring In number of days displayed is incorrect.

Workaround: Log out of the management console and log in again.

Bug Number: 33749408

1.4.1.6 KMIP Daemon May Stop Servicing Endpoints Until the Server is Rebooted

Issue: It has been observed that the KMIP daemon, which services endpoint requests, may stop working on an Oracle Key Vault server due to database bug 33846119. This was observed during a CA certificate rotation operation. Because endpoints must have their certificates rotated by specific nodes, this may result in certain endpoints getting stuck. On the Endpoint Details page of the management console, the endpoint will be seen as having the Common Name of Certificate Issuer stuck on Updating to current certificate issuer and not transitioning to the new CA certificate’s common name, despite repeated successful endpoint operations to other nodes. In standalone and primary-standby configurations, this may result in endpoints failing to fetch objects from the server. In multi-master cluster environments, the endpoints will be able to fetch objects from other nodes, but not the affected node.

Workaround: Rebooting the server will resolve the issue.

Bug Number: 33846151

1.4.1.7 KMIPD May Be Stopped At The Same Time On Multiple Nodes During Certificate Rotation

Issue: During certificate rotation, the kmip and kmipus daemons are restarted several times, with downtime of a few minutes each. It is possible that this restart can happen on multiple nodes at the same time. Especially in smaller clusters, this means it is possible, although unlikely, that all of the kmip daemons in the cluster are unable to respond to endpoint requests, potentially leading to downtime.

Workaround: Turn on or increase the in-memory cache timeout, persistent cache timeout, and persistent cache refresh window values prior to certificate rotation in order to avoid endpoint downtime.

Bug Number: 31311978

1.4.1.8 Modal pages in system settings page are blank on page load and after saving

Issue: The modal pages (pop-ups) in System Settings page will be blank while the page loads. Also on clicking Save, the page is loaded again and the page goes blank while loading the content.

Workaround: The pages usually will show up in about 5 to10 seconds after opening the modal page. Also, the page load time depends on the network speed on the client side.

Bug Number: 32283750

1.4.1.9 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.4.1.10 Oracle Key Vault 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.4.1.11 Oracle Key Vault Boot-Time Warnings When in FIPS Mode

Issue: When an Oracle Key Vault server operating in FIPS mode is booted, warnings such as the below may be seen on console:
Warning : Error inserting
    serpent_avx2(/lib/modules/4.1.12-124.34.1.1.el6uek.x86_64/kernerl/arch/x86/crypto/serpent_avx2):
    No such device

These are informational messages thrown on screen indicating that instruction sets for ciphers that are not available or not supported in FIPS mode are not being loaded. These warnings can be safely ignored.

Workaround: None.

Bug Number: 30844891

1.4.1.12 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.4.1.13 Update Client Endpoint Software With Latest Scan List, Config Params, and Certificate Rotation Updates When a KMIP Server Operation Is Executed Using REST

Issue: Whenever a server operation is performed using the RESTful utility, the configuration file okvclient.ora does not get updated with the latest state. The configuration file remains static as it is when the endpoint software is installed. For example, if there is a new node added to the Oracle Key Vault cluster, the client configuration file okvclient.ora will not get updated with the new node information whenever a server operation is performed using the RESTful utility.

Workaround: In order to have an updated okvclient.ora after a change in configuration, perform an operation using okvutil or the Oracle Key Vault SDK.

Bug Number: 29492842

1.4.1.14 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.4.1.15 Oracle Key Vault Integration with Oracle Audit Vault 20.8 Fails

Issue: Integrating Oracle Key Vault with Oracle Audit Vault 20.8 fails with the following error:

Failed to get client software from Audit Vault server, ensure Public Host Keyand 'support' user password are valid

This is due to a change in permissions of Oracle Audit Vault client jar files that are required for the integration process.

Workaround: Before integrating Oracle Key Vault with Oracle Audit Vault 20.8, the following commands need to be run on the Oracle Audit Vault 20.8 server:
  1. Log into the Oracle Audit Vault 20.8 server as user support through ssh:

    $ ssh support@AV_instance_ip_address

  2. Switch to user root:

    support $ su – root

  3. Check the permissions of the /var/lib/oracle/dbfw/av/jlib/agent.jar and /var/lib/oracle/dbfw/av/jlib/avcli.jar files. They should be similar to the below:

    # ls -l /var/lib/oracle/dbfw/av/jlib/agent.jar

    -rw-r-----. 1 oracle oinstall 36212863 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/agent.jar

    # ls -l /var/lib/oracle/dbfw/av/jlib/avcli.jar

    -rw-r-----. 1 oracle oinstall 30091681 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/avcli.jar

  4. Take a backup of these files (using /bin/cp -p below preserves file permissions):

    # /bin/cp -p /var/lib/oracle/dbfw/av/jlib/agent.jar /var/lib/oracle/dbfw/av/jlib/agent.jar.bkp

    # /bin/cp -p /var/lib/oracle/dbfw/av/jlib/avcli.jar /var/lib/oracle/dbfw/av/jlib/avcli.jar.bkp

    # ls -l /var/lib/oracle/dbfw/av/jlib/agent.jar /var/lib/oracle/dbfw/av/jlib/agent.jar.bkp

    Check that the file permissions and ownership of the original files and their backups are identical:

    -rw-r-----. 1 oracle oinstall 36212863 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/agent.jar

    -rw-r-----. 1 oracle oinstall 36212863 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/agent.jar.bkp

    # ls -l /var/lib/oracle/dbfw/av/jlib/avcli.jar /var/lib/oracle/dbfw/av/jlib/avcli.jar.bkp

    -rw-r-----. 1 oracle oinstall 30091681 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/avcli.jar

    -rw-r-----. 1 oracle oinstall 30091681 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/avcli.jar.bkp

  5. Update the permissions of /var/lib/oracle/dbfw/av/jlib/agent.jar and

    /var/lib/oracle/dbfw/av/jlib/avcli.jar:

    # /bin/chmod 644 /var/lib/oracle/dbfw/av/jlib/agent.jar

    # /bin/chmod 644 /var/lib/oracle/dbfw/av/jlib/avcli.jar

    Check the file permissions and ownership of the original files and their backups again:

    # ls -l /var/lib/oracle/dbfw/av/jlib/agent.jar /var/lib/oracle/dbfw/av/jlib/agent.jar.bkp

    -rw-r--r--. 1 oracle oinstall 36212863 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/agent.jar

    -rw-r-----. 1 oracle oinstall 36212863 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/agent.jar.bkp

    # ls -l /var/lib/oracle/dbfw/av/jlib/avcli.jar /var/lib/oracle/dbfw/av/jlib/avcli.jar.bkp

    -rw-r--r--. 1 oracle oinstall 30091681 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/avcli.jar

    -rw-r-----. 1 oracle oinstall 30091681 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/avcli.jar.bkp

    The additional permissions on /var/lib/oracle/dbfw/av/jlib/agent.jar and /var/lib/oracle/dbfw/av/jlib/avcli.jar The additional permissions on /var/lib/oracle/dbfw/av/jlib/agent.jar and /var/lib/oracle/dbfw/av/jlib/avcli.jar when compared to their backups.

    You can now proceed to integrate Oracle Key Vault with Oracle Audit Vault 20.8 using the normal process.

    After the integration has been successfully completed, the permissions on the Oracle Audit Vault 20.8 files can be restored to their original values. To do so:

  1. Log into the Oracle Audit Vault 20.8 server as user support through

    ssh: $ ssh support@AV_instance_ip_address

  2. Switch to user root:
    $ su – root
  3. Check the permissions of the /var/lib/oracle/dbfw/av/jlib/agent.jar and /var/lib/oracle/dbfw/av/jlib/avcli.jar files.

    They should be similar to the below:

    # ls -l /var/lib/oracle/dbfw/av/jlib/agent.jar /var/lib/oracle/dbfw/av/jlib/avcli.jar

    -rw-r--r--. 1 oracle oinstall 36212863 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/agent.jar

    -rw-r--r--. 1 oracle oinstall 30091681 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/avcli.jar
  4. Restore the files to their backups:

    # /bin/cp -pf /var/lib/oracle/dbfw/av/jlib/agent.jar.bkp /var/lib/oracle/dbfw/av/jlib/agent.jar

    # /bin/cp -pf /var/lib/oracle/dbfw/av/jlib/avcli.jar.bkp /var/lib/oracle/dbfw/av/jlib/avcli.jar

  5. Check permissions again. This time, the files should be identical in permissions and ownership to the backups:

    # ls -l /var/lib/oracle/dbfw/av/jlib/agent.jar /var/lib/oracle/dbfw/av/jlib/agent.jar.bkp

    -rw-r-----. 1 oracle oinstall 36212863 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/agent.jar

    -rw-r-----. 1 oracle oinstall 36212863 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/agent.jar.bkp

    # ls -l /var/lib/oracle/dbfw/av/jlib/avcli.jar /var/lib/oracle/dbfw/av/jlib/avcli.jar.bkp

    -rw-r-----. 1 oracle oinstall 30091681 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/avcli.jar

    -rw-r-----. 1 oracle oinstall 30091681 Sep 29 09:28 /var/lib/oracle/dbfw/av/jlib/avcli.jar.bkp

    The same workaround must be applied when deleting Oracle Key Vault integration with Oracle Audit Vault 20.8.

1.4.2.1 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 the current release of Oracle Key Vault, 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.
    $ ssh support@okv_instance_ip_address
  2. Switch to user root.
    support$ su - root
  3. Check the owner and group on directory /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv.
    root# 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:
    root# chown oracle:oinstall /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
    List the file and verify that the owner is now oracle.
    root# 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.
    root# su oracle
  6. Start SQL*Plus.
    oracle$ 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:
    oracle$ service dbfwdb stop
    oracle$ service dbfwdb start
  10. Verify that the DB_UNIQUE_NAME parameter has changed.
    Start SQL*Plus.
    oracle$ 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.4.2.2 Unpair of Upgraded Primary-Standby Oracle Key Vault 18.x Servers May Fail Due to Permission Issues

Issue: After having completed an upgrade to the current release of Oracle Key Vault, 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.
    $ ssh support@okv_instance_ip_address
  2. Switch to user root.
    support$ su - root
  3. Check the permissions on directory /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv.
    root# 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:
    root# chown oracle:oinstall /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
    List the file and verify that the owner is now oracle.
    root# 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.3.1 Audit Trail is not Sent To Remote Syslog on Switchover in Primary-Standby 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.4.3.2 Failover Issues When Primary OKV Experiences a Controlled Shutdown

Issue: Periodically, the primary Oracle Key Vault node in a primary-standby pair may have a controlled shutdown. For example, a user performs the shutdown by pressing a power off button in the management console or executes the shutdown command from the terminal. When this happens, there will be no failover operation and the standby Oracle Key Vault node 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 node. 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 node to take over as the new primary node, instead perform a switchover.

Bug Number: 29666606

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

Issue: For a primary-standby configuration, before pairing 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.4.3.4 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.4.3.5 SSH Tunnel Status Shows as Disabled on Failover Case in Primary-Standby

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.4.4.1 After Force-Deleting A Read-Write Node In 18.1 Cluster And Then Upgrading, May Not Be Able To Replace Force-Deleted Node In Higher Version

Issue: When force-deleting a read-write node, it should be shutdown first. However, due to GoldenGate bug 30413969, if the force-deleted node is shut down, the downstream extract on the deleted node's read-write peer node is not fully cleaned up. The workaround for this bug is present in Oracle Key Vault versions 18.2 and higher. However, if upgrading from an Oracle Key Vault 18.1 multi-master cluster that has had a read-write node force-deleted, if attempting to replace it after upgrade, it will still not succeed because the cleanup was not executed when the force-delete happened in version 18.1.

Workaround: The following steps are to be executed with caution. Executing these steps on the wrong Oracle Key Vault server will break replication and result in having to force-delete the node on which they were executed.

Example scenario: Nodes A and B are read-write peers. Node B was force-deleted from the cluster. Node A may not have been fully cleaned up due to GoldenGate bug 30413969. Before or after upgrading, but before attempting to add another node as Node A's read-write peer, execute the following steps on node A to finish the cleanup.
ssh support@Oracle_Key_Vault_IP_address
su - root
su - oracle
/var/lib/oracle/dbfw/bin/sqlplus / as sysdba
exec sys.dbms_xstream_adm.drop_outbound('OGG$OKV_DEXT');
exec sys.dbms_streams_adm.remove_queue('OGG$Q_OKV_DEXT', TRUE, TRUE);

After the above steps are successfully executed on Node A, it can be used as the controller node to add another node to the cluster as Node A's read-write peer.

Bug Number: 31216736

1.4.4.2 Backup From Oracle Key Vault 18.1, 18.2 or 18.3 Cluster Node That Is Then Upgraded and Used To Make Another Cluster May Not Be Able To Add A Read-Write Peer

Issue: When restoring a backup taken on a cluster node to a standalone Oracle Key Vault server, the global_name of the database on Oracle Key Vault may be either DBFWDB.DBFWDB or DBFWDB_HA2.DBFWDB, depending on the global_name of the cluster node on which the backup was taken. If the global_name is DBFWDB_HA2.DBFWDB, and the standalone Oracle Key Vault server is converted to a cluster node, then it will not be able to successfully add a read-write peer node due to the global_name mismatch. The global name is fixed during backup restore in versions 18.4 and higher, but if the backup was taken and restored on a lower version, the issue will persist even after upgrading to 18.4 or higher.

Workaround: After restoring the backup to a standalone Oracle Key Vault server, execute these steps before converting it to a cluster node. The first select statement is to confirm that the global_name is DBFWDB_HA2.DBFWDB. Do not proceed with the global_name update if the global_name returned by the below select statement is not DBFWDB_HA2.DBFWDB or if the server has already been converted to a cluster node.
ssh support@Oracle_Key_Vault_IP_address
su - root
su - oracle
/var/lib/oracle/dbfw/bin/sqlplus / as sysdba
select global_name from global_name;
alter database rename global_name to DBFWDB.DBFWDB;

Bug Number: 31241245

1.4.4.3 Cannot Create A Key On The Upgraded Nodes In A Cluster That Is Not Fully Upgraded

Issue: When a multi-master cluster is in the process of upgrading to Oracle Key Vault release 21.4, the symmetric key creation operations fail on the cluster nodes that have been upgraded. The symmetric key creation operations continue successfully on the nodes that have not yet been upgraded. While upgrading the last read-write pair of the cluster, you cannot create a new symmetric key in a multi-master cluster. During the upgrade, operations such as database re-key or enrolling a new database will fail. Once the upgrade of the multi-master cluster completes, symmetric key create or register operations will resume.

Workaround: If you are upgrading a multi-master cluster with more than 2 nodes, you can ensure that symmetric key create or register operations continue to be available on upgraded read-write nodes by applying the patch for Bug 33974435, which is applied to each cluster node after upgrading it, but before enabling the node back into the cluster.

Bug Number: 33974435

1.4.4.4 Certificate Must Be Rotated Before Converting To Cluster If Upgrading From 12.2 BP4 or Older

Issue: If you upgrade from Oracle Key Vault 12.2 BP4 or older and do not generate a new certificate before converting the upgraded Oracle Key Vault server to a cluster node, you will receive the following error message:

Failed to convert server to cluster node, detected use of weak signature
algorithms in OKV server credentials. Please perform a certificate rotation
operation before converting this server to a cluster node.
Workaround: Upgrade to Oracle Key Vault release 18.4 in two steps:
  1. Upgrade from Oracle Key Vault 12.2 BP4 to 12.2 BP11, and perform a certificate rotation operation.
  2. Upgrade from Oracle Key Vault 12.2 BP11 to Oracle Key Vault release 18.4.
For more information on how to perform a certificate rotation in Oracle Key Vault 12.2 BP11, refer to the Oracle Key Vault Administrator's Guide for release 12.2.

Bug Number: 30673249

1.4.4.5 Cluster Service Status Is Down After Rotating Server Certificate

Issue: Rotating the server certificate will stop multiple processes in order to replace the certificates. However, under normal circumstances, they are restarted soon after they are stopped. During or after certificate rotation, on the Monitoring page under the Cluster tab, the Cluster Services Status may show a downward arrow, indicating that one or more cluster services are not running. This will cause replication to be broken to and from this node. If it persists for more than a few minutes, it is likely that this bug has occurred.

Workaround: If this issue occurs, try to restart the cluster services by clicking the Restart Cluster Services button on the Monitoring page. After a few minutes, refresh the page. If the Cluster Service Status still shows a red downward arrow, contact Oracle Support.

Bug Number: 31371440

1.4.4.6 OGG Bug 32079454 Causes Intermittent Distribution Path Failures Causing Replication to Break

Issue: Due to Oracle GoldenGate bug 32079454, distribution paths will intermittently encounter SSL errors that cause them to fail and not automatically restart. This can cause replication between non-read-write peer nodes to break. Other side effects are objects that transition from PENDING to ACTIVE status to be stuck in PENDING status. You will also get replication lag alerts. You can see if a distribution path has potentially failed by checking the Monitoring page under the Cluster tab, and looking for red, downward arrows in the Cluster Link State section.

Workaround: If restarting the cluster link on the Monitoring page under the Cluster tab does not resolve the issue, restart the node and verify that there are no red, downward arrows on the Monitoring page afterward.

Bug Number: 32079491

1.4.4.7 Oracle Key Vault Should Prevent Enabling From Finishing If It Takes Longer Than MDND

Issue: If you enable or disable an Oracle Key Vault node before the Maximum Disable Node Duration time limit, but the enabling does not finish before the Maximum Disable Node Duration time limit expires, it is possible that there could be cleanup of archivelogs and trail files that would cause inconsistency in the cluster. Don't allow the enabling process to finish in this case.

Workaround: Delete or force delete the node from the cluster if it takes longer than the Maximum Disable Node Duration amount of time to finish enabling.

Bug Number: 30533066

1.4.4.8 Read-Write Nodes in Read-Only Restricted Mode After a Reboot

Issue: After rebooting a read-write node, sometimes the node or its read-write peer will become stuck in read-only restricted mode.

Workaround: When you reboot a node, it is normal for a node's read-write peer node to temporarily run in read-only restricted mode. However, soon after the node finishes booting, the read-write peer should transition back to read-write mode within a few minutes. The node that was rebooted may come up in read-only restricted mode, but should also transition back to read-write mode within a few minutes. However, if either a node or its read-write peer does not leave read-only restricted mode, redo shipping may be stuck. It may be fixed by rebooting the node still in read-only restricted mode.

Bug Number: 30589921

1.4.4.9 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.4.4.10 RMAN Automatically Cleans Up Archivelogs Still Necessary for OGG

Issue: RMAN automatically manages the archivelogs in the fast recovery area. Under normal circumstances, RMAN will not delete archivelogs that may still be needed by Oracle GoldenGate. However, under space pressure, RMAN may clean up the needed archivelogs. These archivelogs getting cleaned up will break replication from the current node to all other nodes except the node's read-write peer node. Oracle Key Vault attempts to mitigate this issue by performing regular clean up of the fast recovery area, but under rare circumstances, the fast recovery area may be filled up and this issue may occur.

Workaround: Identify the source of space pressure in the fast recovery area and remedy the issue. You may identify space pressure in the fast recovery area by keeping tabs on the disk space. The fast recovery area is located under /var/lib/oracle/fast_recovery_area/. If replication has broken because of this issue, take a remote backup of the node and then force delete it from the cluster. Note that you may need to make sure that any keys or other objects created on that node are also on all other nodes in the cluster, and manually re-upload them if they are not.

Bug Number: 30558372

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

Issue: If system settings are changed on an Oracle Key Vault node 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 on both the controller and candidate nodes.

Workaround: None. Abort the pairing process on both the controller and candidate nodes. Change the system settings on the candidate node as desired, then re-attempt the pairing process.

Bug Number: 29430349

1.4.4.12 When Password Expiration Alert Is Raised, Administrators Receiving an Email Storm

Issue: The expiration date of an Oracle Key Vault user’s password may be slightly different on different nodes in a multi-master cluster environment. This causes the text of the alert raised on each node to differ, which may result in each Oracle Key Vault node sending many emails.

Workaround: To prevent all emails and notifications for the User Password Expiration alert, disable the alert. To disable the alert, navigate to the Configure Alerts page, deselect the Enabled check box next to User Password Expiration, then click Save.

Bug Number: 34095430

1.4.5 Software Development Kit Issues

The Oracle Key Vault Software Development Kit (SDK) has the following issues when working with Oracle Key Vault server.

  • If an unsupported attribute for an object type is added using the attribute addition or registration APIs, the server adds the attribute to the KMIP object, and no error is given by server.

    APIs impacted are: okvAddAttribute, okvCreateKey, okvRegKey, okvRegSecretData, okvRegOpaqueData, okvRegTemplate, okvRegPrivateKey, okvRegPublicKey, okvRegCertificateRequest, okvRegCertificate

  • If a positive integer is passed as value for attribute index for a single instance attribute in request TTLV for registration, addition, modification and delete APIs , the server will add/modify/delete the attribute at index 0 and will return success irrespective of the index passed in the request.

    APIs impacted are : okvAddAttribute, okvModifyAttribute, okvDeleteAttribute, okvCreateKey, okvRegKey, okvRegSecretData, okvRegOpaqueData, okvRegPrivateKey, okvRegPublicKey, okvRegCertificateRequest, okvRegCertificate

  • If an invalid integer is passed as value for attribute index for a multi instance attribute in request TTLV for modification and deletion APIs, the server will not modify or delete the attribute value and also will not throw any error.

    APIs impacted are : okvModifyAttribute, okvDeleteAttribute

  • The server doesn’t validate the cryptographic usage mask value passed in request TTLV and the value will be added in case of attribute addition and modification.

    APIs impacted are: okvModifyAttribute, okvAddAttribute, okvCreateKey, okvRegKey, okvRegSecretData, okvRegPrivateKey, okvRegPublicKey, okvRegCertificate

  • Oracle Key Vault server currently stores type of name attribute as Uninterpreted Text string in all cases irrespective of the name type in request TTLV.

    APIs impacted are: okvAddAttribute, okvModifyAttribute, okvDeleteAttribute, okvCreateKey, okvRegKey, okvRegSecretData, okvRegOpaqueData, okvRegPrivateKey, okvRegPublicKey, okvRegCertificateRequest, okvRegCertificate

  • If an invalid custom attribute identifier is passed in request TTLV for modification or deletion, the server returns success and no attribute value is modified or deleted.

    APIs impacted are: okvModifyAttribute, okvDeleteAttribute

  • If multiple single instance attributes are added to request TTLV, then no error will be thrown and the first value will get added.

    APIs impacted are: okvCreateKey, okvRegKey, okvRegSecretData, okvRegOpaqueData, okvRegTemplate, okvRegPrivateKey, okvRegPublicKey, okvRegCertificateRequest, okvRegCertificate

  • The objects created using SDK are not downloadable by okvutil as of today. Attempting to run the okvutil download command may show the warning WARNING: Could not store <Unique Identifier of the object>. This warning can be safely ignored as we are skipping the download of keys, secrets & objects created through SDK (if found) to the given wallet. Support for the same will be provided in future releases.

  • When a certificate, using SHA-DSA as the signature algorithm, is uploaded to Oracle Key Vault using CSDK, the certificate will be uploaded to Oracle Key Vault without any attributes. If a secret object containing such a certificate is uploaded using okvutil, the certificate will be uploaded without the cryptographic algorithm and cryptographic length attributes. If all attributes of such a certificate are required, the workaround will be to use JSDK to upload the certificate to Oracle Key Vault.

1.5 Oracle Key Vault Considerations

Below are details and changes of behavior of this release of Oracle Key Vault.

1.5.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.5.2 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.5.3 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.

Setting and rotating the TDE master encryption key are examples of update operations.

1.6 Supported Database Versions

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

  • 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.7 Critical Patch Updates Included in Release 21.5

Oracle Key Vault release 21.5 updated the underlying infrastructure to incorporate the July 2022 Release Update for Oracle Database (19.16 DB RU)" - July Release Update. Please sign in for full details.

https://www.oracle.com/security-alerts/cpujul2022.html

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

1.8 Known Issues

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

1.9 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.