Sentinel cryptographic errors in log files

When looking in the log files for Sentinel an error message regarding cryptography used to connect the Sentinel components is thrown from time to time.  Examples of the error messages are in the Additional Information section of the document but most of them show up as part of the com.esecurity.common.communication.strategy Java class in the exception.

This is often caused by a rogue Sentinel component installed on some machine that is trying to connect to the message bus and sending messages to DAS using the wrong encryption key.  There are two likely causes of this scenario:
1. The encryption key (in $ESEC_HOME/config/.keystore) was modified on Sentinel Server, but was not copied to some other machine that is running a component that needs it (such as a Collector Manager).
2. The "Sentinel Service" component was accidentally installed on some machine (because the parent node was not deselected in the installer).  This resulted in an unnecessary service being installed which does not have the proper encryption key.

The first thing to do is get a list of all machines that are connecting to the message bus by utilizing the $ESEC_HOME/bin/list_broker_connections script.  Check each machine that is connecting to make sure:
1. It really needs to be connecting (i.e., not an unnecessary service).
2. It is using the correct encryption key.

To run the list_broker_connections.sh script do the following:
Change to the directory where the script is located.
cd $ESEC_HOME/bin

Run the script specifying the IP/DNS information of the server running the Communications (JMS) service followed by the primary communications port (10012 by default):
./list_broker_connection.sh 192.168.1.1 10012

The resulting information includes the connected machines and the queues to which they are connected.

Wed Jan 28 02:01:12 CET 2009|SEVERE|JMS Session Delivery Thread|com.esecurity.common.communication.strategy.EncryptionInterceptor.unconvert
    DecryptionModule: Failed to decrypt message; Exception Given final block not properly padded; javax.crypto.BadPaddingException;


Wed Jan 28 02:01:12 CET 2009|SEVERE|JMS Session Delivery Thread|com.esecurity.common.communication.strategy.EncryptionInterceptor.unconvert
    javax.crypto.BadPaddingException: Given final block not properly padded
        at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
        at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
        at com.sun.crypto.provider.AESCipher.engineDoFinal(DashoA12275)
        at javax.crypto.Cipher.doFinal(DashoA12275)
        at com.esecurity.crypto.CipherToken.doFinal(CipherToken.java:81)
        at com.esecurity.common.communication.strategy.EncryptionInterceptor.unconvert(EncryptionInterceptor.java:166)
        at com.esecurity.common.communication.strategy.sonicstrategy.SonicListener.runInterceptors(SonicListener.java:437)
        at com.esecurity.common.communication.strategy.sonicstrategy.SonicListener.onMessage(SonicListener.java:274)
        at progress.message.jimpl.Session.deliver(Unknown Source)
        at progress.message.jimpl.Session.run(Unknown Source)
        at progress.message.jimpl.Session$SessionThread.run(Unknown Source)


Wed Jan 28 02:01:12 CET 2009|SEVERE|JMS Session Delivery Thread|com.esecurity.common.communication.strategy.sonicstrategy.BaseSonicStrategy.traceException
    Error: java.lang.RuntimeException: javax.crypto.BadPaddingException: Given final block not properly padded; 
    Caused by: javax.crypto.BadPaddingException: Given final block not properly padded: