By default, the standard Java implementation chooses the first alias it finds in the keystore for which there is a private key and a key of the right type for the chosen cipher suite. The selected alias does not necessarily correspond to the requested domain, which can cause certificate errors.

To overcome this limitation, you can configure a simple port strategy or an advanced port strategy that map each SSL host and port combination in Dynamic Data Masking to a specific alias. Each alias corresponds to a key entry with a private key and signed certificate in the keystore that Dynamic Data Masking uses for the SSL handshake with the client.

The following image shows the keystrategies configuration section of the

cfg/ddm.security

file:

Alias names must be unique for all keystores. If you do not give unique alias names, Dynamic Data Masking uses the key entry with the first found matching alias to handshake with the client.

You do not need to configure the keystrategy section when you have not configured the Dynamic Data Masking Server with a keystore, or when a keystore configured in the Dynamic Data Masking Server contains only one signed certificate.

If you have not configured the Dynamic Data Masking Server with a keystore, Dynamic Data Masking uses the self-signed certificate generated in the default Dynamic Data Masking keystore file

cfg/ddm.jceks

. This certificate is associated with the reversed alias name

ddm_self_signed

. Do not use this alias name in any other keystores.

In this scenario, the Dynamic Data Masking Server provides the self-signed certificate to the client.

If you have configured the Dynamic Data Masking Server with one keystore, defined in the file

jvm.params

or

cfg/ddm.security

, that contains only one signed certificate, Dynamic Data Masking uses that certificate.

The following table describes the keystore strategy requirements for both the Dynamic Data Masking Server and the administrative tools: