These release notes list the new features for this release of Oracle Key Vault, how to download the latest product software and documentation, and how to address known issues in Oracle Key Vault.
1.1 Changes in This Release for Oracle Key Vault
Oracle Key Vault release introduces new features that enhance the use of Oracle Key Vault in a large enterprise.
- Oracle Key Vault Server Certificate Rotation
- Recover the Candidate Node If There Is a Failure or Error During Node Induction
- Upgrade Oracle Key Vault Server with HSM as Root of Trust Without the Need to Reverse Migrate
- Limit Reset of User Password to Recovery via Email Only
- Automatically Update Endpoint Configuration with changes to Reverse-SSH Tunnels in the Cluster
- HSM as Root of Trust Improvements
- New and Modified Alerts
- Endpoint Software Installation Logs Environment Variables For Later Diagnostics
- RESTful Services Improvements
- Refresh Cached Oracle Key Vault Configuration Periodically In Long Running Processes
In previous releases, the endpoint database'sgen0
process did not pick up newokvclient.ora
values periodically. - Auto-Expiring Persistent Cache on Endpoint Database Shutdown
Parent topic: Release Notes
1.1.1 Oracle Key Vault Server Certificate Rotation
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. When this happens, you must rotate the server certificate and re-enroll the endpoint. The rotation process handles the rotation for all certificates in one operation. To avoid this scenario, you can configure an alert to remind you to rotate the certificate before the 730-day limit is up. You can set how early to get the certificate expiration alert by editing the Oracle Key Vault Server Certificate Expiration setting on the Configure Alerts page in the Oracle Key Vault management console. 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.
The certificate rotation process captures all certificates in the Oracle Key Vault server. It does not capture third-party certificates.
If you have a primary-standby or multi-master cluster configuration, then Oracle Key Vault automatically synchronizes the certificates in both systems.
Parent topic: Changes in This Release for Oracle Key Vault
1.1.2 Recover the Candidate Node If There Is a Failure or Error During Node Induction
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 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.
Parent topic: Changes in This Release for Oracle Key Vault
1.1.3 Upgrade Oracle Key Vault Server with HSM as Root of Trust Without the Need to Reverse Migrate
Upgrading an Oracle Key Vault that was HSM-enabled would not proceed for several
reasons. First, if Oracle Key Vault was registered as a client of an HSM
that it had to contact via hostname, after rebooting, 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 Entrust (formerly 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. We now start 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.
Parent topic: Changes in This Release for Oracle Key Vault
1.1.4 Limit Reset of User Password to Recovery via Email Only
Oracle Key Vault prevents administrative users from manually changing passwords of other users when secure user management is enabled. Only an option to send a one time password to user's email address is provided.
Related Topics
Parent topic: Changes in This Release for Oracle Key Vault
1.1.5 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 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.
Parent topic: Changes in This Release for Oracle Key Vault
1.1.6 HSM as Root of Trust Improvements
This section describes Oracle Key Vault HSM as Root of Trust improvements .
1.1.6.1 Validate HSM Setup Periodically
In previous versions of Oracle Key Vault with HSM as Root of Trust, the connectivity to HSM was only validated during the Oracle Key Vault setup. 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.
Parent topic: HSM as Root of Trust Improvements
1.1.6.2 Improved Error Reporting for HSM Functionality
- Reverse migrating from HSM in 18.1 in standalone mode (not cluster and not primary-standby) with the same recovery passphrase for the "old" and "new" recovery passphrase fields displays an improper error message. 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.
Parent topic: HSM as Root of Trust Improvements
1.1.7.1 New Alerts Added In This Release
New alerts added in this release of Oracle Key Vault are:
- Validate HSM Setup Periodically: If HSM-enabled, verify that the HSM configuration is valid and working properly. If it is not working properly, an Invalid HSM Configuration alert is raised.
- Raise an Alert if Replication Lag Is Greater Than Configured Limit: For multi-master cluster setup, there is a new alert that tracks the replication lag from other nodes to the current node. This alert is raised when replication lag is greater than the specified threshold. The default is 60 seconds.
- Alerts Are Raised If the Alert Jobs Are Hitting Issues: In
previous versions of Oracle Key Vault, failures to check alert conditions in alert
jobs were logged to
syslog
only. Now, when an alert condition check fails, an alert is raised and an email, if configured, is sent. These alerts are cleaned up if the failed alert condition runs fine on subsequent evaluation.
Parent topic: New and Modified Alerts
1.1.7.2 Alerts Modified In This Release
- Retain Heartbeat Alerts for Defunct Nodes Until They Are Deleted: Alerts about a node not contacting another node for greater than the Maximum Disable Node Duration amount of time should not get deleted, even if contact is restored, because some records may have been lost despite restoring replication between the two nodes.
- Delete Alerts Associated with a Reverse-SSH Tunnel when the Tunnel Is Deleted: SSH tunnel alerts were not deleted when the SSH tunnel was deleted. The alerts are now deleted when the tunnel is deleted.
- Alerts Raised on Switchover Are Not Deleted When the Primary-Standby Are Unpaired: Alerts from primary-standby configurations could still be seen after unpairing. The alerts are now deleted after unpairing.
Parent topic: New and Modified Alerts
1.1.8 Endpoint Software Installation Logs Environment Variables For Later Diagnostics
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.
Parent topic: Changes in This Release for Oracle Key Vault
1.1.9 RESTful Services Improvements
This section describes improvements to RESTful services in Oracle Key Vault.
1.1.9.1 KMIP REST Locate Supports Filtering by Key Name
Given a human readable name of the KMIP object, users can find the KMIP identifier
associated with the object. 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.
Parent topic: RESTful Services Improvements
1.1.9.2 Re-Enroll All Endpoints With a Single RESTful Command
In Oracle Key Vault deployments with large number of endpoints, re-enrolling all
endpoints one by one, even with the RESTful API, may be time consuming.
Oracle Key Vault provides a single RESTful command to re-enroll all
endpoints. The new RESTful command is re_enroll_all
.
Parent topic: RESTful Services Improvements
1.1.9.3 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, it doesn't 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.
Parent topic: RESTful Services Improvements
1.1.10 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.
Parent topic: Changes in This Release for Oracle Key Vault
1.1.11 Auto-Expiring Persistent Cache on Endpoint Database Shutdown
Installing the OKVclient without a password configures the persistent cache as an auto-open wallet. Installing the OKVclient with a password applies this password also to the persistent cache. The new option to create an auto-expiring persistent cache protects the persistent cache with an automatically generated password that is not known to anyone, therefore it cannot be opened after database restart or OS restart.
Parent topic: Changes in This Release for Oracle Key Vault
1.2 Downloading the Oracle Key Vault Software and the Documentation
At any time, you can download the latest version of the Oracle Key Vault software and documentation.
1.2.1 Downloading the Oracle Key Vault Installation Software
For a fresh installation, you can download the Oracle Key Vault software from the Software Delivery Cloud. You cannot use this package to upgrade Oracle Key Vault. For an upgrade from an existing Oracle Key Vault 12.2 deployment, you can download the Oracle Key Vault upgrade software from the My Oracle Support website.
1.3 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.3.1 General Issues
This section describes general Oracle Key Vault issues.
- On HP-UX System, SELECT FROM V$ENCRYPTION_KEYS May Return ORA-28407 Occasionally
- OKV 12.2 BP1: User Gets Locked and Expired with Multiple Failed Logins
- OKV Alerts Still Show in the List After Fixing the Problem
- Private Keys Are Not Overwritten When a Java Keystore Is Uploaded Using the -o Option of the okvutil Utility
- HSM Credentials Are Asked While Creating Bundle Even When HSM Is Not Initialized
Parent topic: Known Issues
1.3.1.1 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
Parent topic: General Issues
1.3.1.2 OKV 12.2 BP1: User Gets Locked and Expired with Multiple Failed Logins
Issue: The current password policy locks the user account for a day if the user has incorrectly entered the password more than three consecutive times. Therefore, the user will be able to log in only after the 24-hour lockout period expires.
Workaround: Make a note of the password and keep it accessible and secure.
Bug Number: 23300720
Parent topic: General Issues
1.3.1.3 OKV Alerts Still Show in the List After Fixing the Problem
Issue: User password expiration alerts are still showing even after the user changes their password.
Workaround: In the Oracle Key Vault management console, select Reports and then Configure Reports. Then uncheck the User Password Expiration option. Alternatively, ignore the alert.
Bug Number: 27620622
Parent topic: General Issues
1.3.1.4 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
Parent topic: General Issues
1.3.1.5 HSM Credentials Are Asked While Creating Bundle Even When HSM Is Not Initialized
Issue: HSM credentials are not used nor necessary when creating the HSM bundle when Oracle Key Vault is not integrated with an HSM, however they are required from the UI regardless.
Workaround: Provide the most recent HSM credential when creating the HSM bundle even when the Oracle Key Vault is not integrated with an HSM.
Bug Number: 30539386
Parent topic: General Issues
1.3.2.1 Pre-Upgrade Script When Upgrading From 18.1 Incorrectly Determines If a Node Has a Read-Write Peer
cluster_preupgrade_181.sh
,
which is executed on Oracle Key Vault cluster nodes that are currently upgrading from
Oracle Key Vault version 18.1.0.0.0, tries to determine if the node on which it is being
executed currently has a read-write peer node. It determines this incorrectly if the
node previously had a read-write peer that was since deleted from the cluster (and not
replaced as the current node’s read-write peer). Executing the script results in the
following error
message:Blocking user operations on the UI... Stopping the downstream extract... Patching downstream extract parameter file... Restarting the downstream extract... Sleeping for 10 to let the extract finish starting... Error: finished applying files but failed to restart the downstream extract. Restart it by navigating to the monitoring page and pressing the "Restart Serivces" button.
Workaround: If you encounter this message, but the node on which you executed the pre-upgrade script does not currently have a read-write peer, the error message can be ignored, and you can proceed with the rest of the upgrade as usual. If you encounter this message on a node that does currently have a read-write peer, this message should not be ignored.
Bug Number: 32539731
Parent topic: Upgrade Issues
1.3.2.2 Unpair of Upgraded Primary-Standy OKV 18.2 Servers May Fail Due to Permission Issues
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
/var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
directory has
the right permissions using the steps below:
- Log into the primary Oracle Key Vault system as user
support
through ssh. - Switch to user
root
.su - root
- Check the permissions on directory
/var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
.ls -l /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb
The output should be similar to this output.drwxr-xr-x 2 root oinstall 4096 Apr 24 22:01 metadata_pv
- If the directory is owned by user
root
, as shown above, execute the following command:chown oracle:oinstall /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
List the file and verify that the owner is noworacle
.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
Parent topic: Upgrade Issues
1.3.2.3 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.
- Log into the primary Oracle Key Vault system as user
support
through ssh. - Switch to user
root
.su - root
- Check the owner and group on directory
/var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
.ls -l /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb
The output should be similar to this output.drwxr-xr-x 2 root oinstall 4096 Apr 24 22:01 metadata_pv
- If the directory is owned by user
root
, as shown above, execute the following command:chown oracle:oinstall /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
List the file and verify that the owner is noworacle
.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
- Switch to user
oracle
.su oracle
- Start SQL*Plus.
sqlplus / as sysdba
- Execute the following
statement:
show parameter db_unique_name;
- If the
DB_UNIQUE_NAME
is something other thanDBFWDB
, then execute the following statements:alter system set db_unique_name='DBFWDB' scope=spfile; exit
- As user
root
, execute the following commands:service dbfwdb stop service dbfwdb start
- Verify that the
DB_UNIQUE_NAME
parameter has changed.Start SQL*Plus.sqlplus / as sysdba
- 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
Parent topic: Upgrade Issues
1.3.3 Primary-Standby Issues
This section describes Oracle Key Vault issues specific to a primary-standby configuration.
- OKV 12.2 BP8: Audit Trail is not Sent To Remote Syslog on Switchover in HA Pair
- OKV 12.2 BP2: SSH Tunnel Status Shows as Disabled on Failover Case in HA
- Re-pair After Un-pair from HA 12.2 BP5 to new OKV Server Still Shows Standalone
- Failover Issues When Primary OKV Experiences a Controlled Shutdown
- HA Setup Succeeds with Different Primary & Standby RO Restricted Mode Config
Parent topic: Known Issues
1.3.3.1 OKV 12.2 BP8: Audit Trail is not Sent To Remote Syslog on Switchover in HA Pair
Description: With syslog configured on the primary, the audit logs are also written to the syslog. On switchover, the audit logs may not be written to the syslog. This is because the syslog has not been configured on the standby. Syslog needs to be configured on primary and standby separately.
Workaround: Configure the syslog on standby after switchover to enable write of audit logs to syslog.
Bug Number: 28790364
Parent topic: Primary-Standby Issues
1.3.3.2 OKV 12.2 BP2: SSH Tunnel Status Shows as Disabled on Failover Case in HA
Issue: After a failover operation, the new Oracle Key Vault primary server does not show the correct status of the SSH tunnel. It shows the SSH tunnel as disabled when the SSH tunnel is available. The dashboard also shows an alert, warning that the setup of an SSH tunnel failed. This is because after the failover operation, Oracle Key Vault tried to establish two SSH tunnels to the same database as a service endpoint, resulting in the incorrect status and dashboard alert. The second SSH tunnel to the database as a service endpoint does not affect connectivity between the Oracle Key Vault server and the database as a service endpoint. The first SSH tunnel to the database as a service endpoint is functional and available after the failover.
Workaround: After a failover, the new Oracle Key Vault primary server shows the correct SSH status as available and connected to the database as a service endpoints. You also can use the okvutil list
on the database as a service endpoint to check the status of the SSH tunnel.
Bug Number: 24679516
Parent topic: Primary-Standby Issues
1.3.3.3 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
Parent topic: Primary-Standby Issues
1.3.3.4 Failover Issues When Primary OKV Experiences a Controlled Shutdown
Issue: Periodically, the primary Oracle Key Vault server in a primary-standby
pair has a controlled shutdown. For example, a user performs the shutdown by pressing a
power off button in the user interface or executes the shutdown command from the
terminal. When this happens, there will be no failover operation and the standby Oracle
Key Vault server will not take over as the primary server. This can be predicted by the
existence of the file /var/lock/subsys/dbfwdb
on the primary Oracle Key
Vault server. If the file exists on the primary at the time of the controlled shutdown,
there will not be a failover. If it does not exist, then a failover should occur.
Note that failover still does occur in other situations such as power loss on the primary or database failure, regardless of the file's existence.
Workaround: If performing a controlled shutdown in an attempt to cause the standby to take over as the new primary, instead perform a switchover.
Bug Number: 29666606
Parent topic: Primary-Standby Issues
1.3.3.5 HA Setup Succeeds with Different Primary & Standby RO Restricted Mode Config
Issue: For a primary-standby configuration, if read-only restricted mode is enabled on one Oracle Key Vault server and not on the other Oracle Key Vault server, then the configuration succeeds. This mismatch can lead to issues and confusion in a primary-standby deployment.
Workaround: Use the Oracle Key Vault management console to ensure that both servers have the same read-only restricted mode state applied. To do so, select the System tab, then Primary-Standby. Select the Allow Read-Only Restricted Mode option. Only then apply the primary-standby configuration on each server.
Bug Number: 26536033
Parent topic: Primary-Standby Issues
1.3.4 Multi-Master Cluster Issues
This section describes Oracle Key Vault issues specific to a multi-master cluster configuration.
- Replication May Fail to Resume After Multiple System Failures in OKV Cluster
- System Settings Changed on an OKV System After Conversion to a Candidate Node Do Not Reflect On The Controller Node
- Read-Write Nodes in Read-Only Restricted Mode After a Reboot
- RMAN Automatically Cleans Up Archivelogs Still Necessary for OGG
- Oracle Key Vault Should Prevent Enabling From Finishing If Takes Longer Than MDND
- Certificate Must Be Rotated Before Converting To Cluster If Upgrading From 12.2 BP4 or Older
Parent topic: Known Issues
1.3.4.1 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
Parent topic: Multi-Master Cluster Issues
1.3.4.2 System Settings Changed on an OKV System After Conversion to a Candidate Node Do Not Reflect On The Controller Node
Issue: If system settings are changed on an Oracle Key Vault system after it has been converted to a candidate node, and after the controller node's initial attempt to verify the candidate node's settings has failed, the updated settings do not reflect on the controller node. The pairing process must be aborted and the candidate node re-installed.
Workaround: None. Verify that the Oracle Key Vault system's settings match with those of the cluster before attempting to convert it into a candidate node and induct it into a cluster.
Bug Number: 29430349
Parent topic: Multi-Master Cluster Issues
1.3.4.3 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 become 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
Parent topic: Multi-Master Cluster Issues
1.3.4.4 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/
.
Bug Number: 30558372
Parent topic: Multi-Master Cluster Issues
1.3.4.5 Oracle Key Vault Should Prevent Enabling From Finishing If 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
Parent topic: Multi-Master Cluster Issues
1.3.4.6 Certificate Must Be Rotated Before Converting To Cluster If Upgrading From 12.2 BP4 or Older
Issue: If you attempt to upgrade to Oracle Key Vault 18.2 from Oracle Key Vault 12.2 BP4 through 18.1 and do no generate a new certificate before the upgrade, 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: Generate a new certificate before attempting the upgrade to Oracle Key Vault 18.2.
Bug Number: 30673249
Parent topic: Multi-Master Cluster Issues
1.4 Oracle Key Vault Considerations
Below are details and changes of behavior of Oracle Key Vault 18.2.
1.4.1 Oracle TDE and Oracle Key Vault Integration
Depending on the Oracle Database version used and on the feature of TDE used, there might be a need to patch the Oracle database for smooth operations.
Refer to the MOS-NOTE with Doc ID 2535751.1 to ascertain if your deployment needs a database patch.
The MOS-NOTE lists known issues with Oracle Database Transparent Data Encryption (TDE) feature when it is configured to use Oracle Key Vault as the keystore. The document also lists the fixes that resolve the issues enabling smoother integration between Oracle Database TDE and Oracle Key Vault. The issues could be defects, reducing the user burden with simplified operations, or improving the integration between TDE and OKV. The document is for Database Administrators and others tasked with managing the TDE Master Keys with Oracle Key Vault.
Parent topic: Oracle Key Vault Considerations
1.4.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.
Parent topic: Oracle Key Vault Considerations
1.4.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.
Parent topic: Oracle Key Vault Considerations
1.5 Supported Database Versions
The following versions of Oracle Database are supported with Oracle Key Vault 18.2:
- 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
Parent topic: Release Notes
1.6 Critical Patch Updates Included in Release 18.2.0.0.0
Oracle Key Vault release 18.2 updated the underlying infrastructure to incorporate the October 2019 Release Update for Oracle Database 18 (18.8 DB RU) - October Release Update. Please log in for full details.
https://www.oracle.com/security-alerts/cpuoct2019.html
Oracle Key Vault release 18.2 also includes security and stability fixes for Java and Oracle Linux (OL) operating system.
Parent topic: Release Notes
1.7 Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
Parent topic: Release Notes
Oracle Key Vault Release Notes, Release 18.2
F25624-05
April 2021
Copyright © 2013, 2021, Oracle and/or its affiliates.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract. The terms governing the U.S. Government’s use of Oracle cloud services are defined by the applicable contract for such services. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc, and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.