Alert log from Oracle Key Vault Server shows the following error message.

SSL Client: Server DN does not contain expected SID name

Probable Cause

These messages are from earlier SSL configurations.

Solution

Ignore these messages.

This problem scenario applies to values that were created from an Oracle Key Vault version 21.2.0.0.0 or earlier. Retrieving an integer type custom attribute created by RESTful services utility using C or Java SDK may return an invalid value. It is also possible that a custom attribute results in an invalid value.

Probable Cause

In Oracle Key Vault versions 21.2.0.0.0 or earlier, when an integer type custom attribute is added or modified using RESTful services utility, the attribute value is stored in a representation that is different from the representation that is used by other interfaces, for example, C or JAVA SDK, and KMIP.

This means that a value created or modified using the RESTful service utility cannot be retrieved correctly with C or JAVA SDK and KMIP interfaces. Likewise, a value created or modified using C or JAVA SDK and KMIP interfaces could not be retrieved correctly using RESTful service utility and the Oracle Key Vault management console.

The correct value is returned when the value is created and retrieved using the same interface.

In a multi-master cluster, Oracle Key Vault version in this section refers to the cluster version of the deployment.

Solution

To identify the values that are suspect and establish a correct value for them use the following procedure after the upgrade to Oracle Key Vault version 21.3.0.0.0 or later. A value for the custom attribute of integer type is considered suspect for cross utility use if it was created prior to Oracle Key Vault 21.3.0.0.0. This includes the values that may already be stored using the correct representation. Because from the value itself, it is not feasible to determine the representation, all such values are considered suspect and must be corrected.

1. Identify suspect values for the custom attributes of integer type:
   1. Log in to the Oracle Key Vault server through SSH as user support, then switch user su to root.

      ssh support@okv_server_IP_address 
      su - root
      

   2. Run the script to generate a report with the suspected values:

      /usr/bin/su - okv -c
            /usr/local/okv/bin/gen_custom_attr_suspect_values

      A report with the list of suspected values is generated:

      /tmp/suspect_values_for_custom_attribute_integer_type.txt

      For each entry in the report, following values are shown:

      • Creating Endpoint: Endpoint that created the value.
      • Unique ID of Object: Unique ID (UUID) of the object.
      • Custom Attribute Name: Name of the custom attribute.
      • Index: Index of the value.
      • SDK Value: Value as retrieved by the C/JAVA SDK interfaces.
      • REST Value: Value as retrieved by the RESTful services utility.

      Between SDK and REST values, one of the values will be the correct value.

2. Update the suspect value with the chosen correct value.
   For each suspect entry:

   1. Review the SDK and REST values.
   2. Determine the correct value of the custom attribute from the two possible values. One of the values will be the correct value of the custom attribute.

      In some cases, a ‘-‘ may be shown for one of the values. In such cases, the correct value would be the one that is shown as the integer value.

   3. Update the custom attribute with the chosen correct value. You can use any interface to update this value.

      You must update the custom attribute value even when one of the value is shown as ‘-‘.

      This step may require the coordination between the root user and the Oracle Key Vault users who can update the suspect values. A user who has the Key Administrator role can update all suspect values. In addition, a user or an endpoint who has read/write access on an object can modify the suspect custom attribute value for that object. You can determine such users using the endpoint information shown under ‘Creating Endpoint’.

It is recommended to complete this procedure by establishing the correct value for all suspect values in one iteration. However, in case if it becomes necessary, above procedure could be repeated and then it will include only the remaining suspect values in the report.

It is recommended to verify the completion of this procedure by executing Step 1 again and ensuring that the generated report does not contain any suspect value entries.

Probable Cause

Requires restart of tomcat service

Solution

1. Login to the Oracle Key Vault server or node through ssh and switch user to root.
2. Restart tomcat service.

   $service tomcat status 
   $service tomcat stop 
   $service tomcat start

3. Verify if the tomcat service is up and running.

   $service tomcat status
   ps -eaf | grep tomcat

4. Send a test email and see if the email is received.