Problem description

 Low SSL decryption level is occurring. 

Solutions checklist

Version: DC RUM 17.x

Any of the following actions could resolve the problem. The process begins with the most likely solution and we recommend that you perform the following steps in provided sequence. If none of the steps resolve the problem, we urge you to contact our support team.

1. Verify why SSL sessions are not decrypted 




 

The main reason of low SSL traffic decryption are unsupported ciphers where keys are found and matched with certificates.

 

  - The very first step to diagnose how much traffic on which AMD     is not decrypted

  - To do that please go to your-CAS – Main menu – Diagnostic         Secure Traffic Diagnostics

You need to simply choose the AMD you are interested in and click “Filted by selected data”

Servers with failed sessions

By clicking on Percentage of not decrypted sessions you are able to drill down to the detailed view with all servers with failed session and ckicking on server ip address you can go even further to Session failure details where you have detailed explanation what exactly couldn’t be decrypted and what is the root cause.

Session failure details

-All the Handshake issues are usually related to lost packets coming to the AMD server
-The rest are the errors related to no data exchange etc.

Sessions failure details

By drilling down to the server ip address you can also verify that this particular server is not decrypted due to unsupported ciphers and which exact Software Services are affected by this.

Alternative (lowest level) way to verify ciphers

Go to rcon and run:

show ssldecr ciphers 

which should return similar list:

 

 

The "+" sign preceding every line, means that the AMD supports decoding of given SSL encoding algorithm. The "-" sign means that it does not.
The "ref" value at the end of every line indicates the number of sessions encoded with a given SSL algorithm.

AMD does not decode any Diffie-Hellman ciphering algorithms (all above lines prefixed with "DH" or "EDH").

List of Supported SSL algorithm we can find here: SSL Support

2. Verify AMD SSL configuration.




To verify AMD SSL configuration please follow the steps below:

1. SSL software installed and SSL card initialized?

If you don't have any hardware SSL cards, the OpenSSL software should already be installed on your AMD during the AMD software installation. No card initialization is required for OpenSSL. For installation and card initialization information specific to your SSL card, please check the "AMD Installation Guide" document.

2. User logged in to the card?

For certain SSL cards, like Nitrox FIPS, the "USER" user must be logged in to the card at all times in order for the AMD to decrypt SSL traffic. On system restart, the "USER" user gets automatically logged out. To fix this, Log in to the AMD, run the SSL card configuration utility (i.e. ./nitrox-setup), and select the correct option(s) to make sure that the "USER" user is logged in.


Note: Not all cards require a user to be logged in to decrypt traffic. For some cards, like the nCipher nShield, this step is not necessary and can be skipped.


3. SSL private key in the proper format?

The AMD only accepts SSL private keys in PEM-encoded format. Before loading the SSL key on the card, run the command

openssl rsa -in <ssl key filename> -text

on the AMD to make sure that the key is in the correct PEM format. This command should display information on the key, like the bit size, algorithym used, etc. If you get an error message after executing this command, then the file might not be in the correct PEM format. Try to re-convert the original SSL key to PEM format. Instructions on how to convert a specific type of SSL key to PEM-encoded format below:

openssl pkcs12 -nocerts -in <.pfx key file name> -out <.pem key file name> -nodes

This will prompt for the passphrase used during the export of the key on the IIS host, and will create a new file in .pem format without encryption. The .pem file can then be copied to the AMD keys directory and added to the keylist.

Note: If the KPA daemon is in use for encrypted SSL keys and this new .pem format key file needs to be encrypted, use the same command, adding -des3 to the command line. The program will then also prompt you for the passphrase to encrypt the new .pem file with. This does not have to be the same passphrase used to decrypt the .pfx file. To verify if coverted key is in proper format please follow this method:

How to verify that the SSL private key matches the Certificate seen on the wire - method 2

4. SSL private key added to your card and/or keylist file?

Once the key is confirmed to be in the proper format, check if this key is loaded to the card and/or added to the keylist file. By default, the AMD looks for the "keylist" file located in /usr/adlex/config/keys in order to load keys from that directory (openssl) or the SSL card. The keylist file is a plain-text file that contains line entries for each SSL key. The format is as follows:

key_type, key_identifier, comment

key_type specifies whether the private key is contained in a PEM-encoded file or in a hardware SSL card token. There are 2 options for this field.
file: means that the private key is stored in a PEM-encoded file
token: means that the private key is stored in a hardware SSL card

key_identifier identifies the key. For keys stored in files, it is the name of the PEM-encoded file that contains the SSL private key. For keys stored on the SSL card, it is the key identifier as given by the utility (i.e. ./nitrox-setup) that lists the keys. For CryptoSwift and nCipher SSL cards, the identifier is an 8-digit hexadecimal value. For a NITROX XL FIPS SSL card, the length of the identifier can vary.

5. SSL private key being used?

On the AMD, run the command "rcmd show ssldecr keys" and search through the output for the SSL key in question. The "status:" of the SSL key should be "matched", if the AMD is seeing traffic for the SSL server and is able to decrypt it. Otherwise, if the "status:" is "read", then run the command "rcmd show ssldecr servers" and see if you can find an entry for the SSL server in question. If there's an entry for the SSL server showing the SSL certificate, then the SSL private key installed on the AMD might not be for this server. In this case, you need to obtain the correct SSL key for this server and configure it on the AMD. In case the output of the "rcmd show ssldecr servers" command doesn't show an entry for the SSL server, then this means that the AMD is not seeing traffic for this SSL server. In this case, please check your network spans to make sure this traffic is being sent to the AMD.

Note: In case you get any errors from the "rcmd show ssldecr keys" as shown below, you need to repeat step 3 to make sure the SSL key is in the correct (supported) format. In some cases, restarting the RTM process by issuing the AMD command "service rtm restart" might resolve the issue of a missing key from the list.


7. Key protected by a passphrase or invalid RSA format.L private key being used?

When importing the key to the ncipher card zou maz encounter the  following error.

ERROR: Tcl_Eval of 'acquire' failed: nfgk_pem_decode_rsaprivatekey_file /usr/adlex/config/KEYS/bhswebapps.pem: InvalidData

nfgk_operate: SoftwareFailed

First check if the key is not protected by passphrase. A protected key always contains the following string:

Proc-Type: 4,ENCRYPTED

If so you may remove the paraphrase using the following command:

openssl rsa -in key.pem -out new_key.pem

If the key was exported to an unknown format which caused error during import you may use the same command to change to a valid RSA format.

What to do next

If none of the provided solutions resolved the issue please provide our Support team with output of the following commands:

On the AMD, execute the following, one-line, long command:

and provide generated /tmp/ssl-decr-status-all_XXXXX.log file.