Unable to create provider - encryptText (Asym) taking too long

I have a serious problem connecting to a CUCM 10.5(2.1) server using JTAPI from machines running Redhat ES 7.2.

The same server is ok with clients running on Redhat ES 6, using exactly the same JTAPI jar file and user.

I have installed the 64-bit jtapi SDK (CiscoJTAPIx64-Linux) and am using the supplied Jtrace application. Essentially when trying to get the provider it is failing and returning null.

From looking at jtapi logfiles, it looks as though the client connects but then doesn't send the ProviderOpenRequest within the 5 seconds allowed by the server, before the server times out and disconnects the link. It seems as though the client is stuck within the encryptText (Asym) function and doesn't return quickly enough.

Here's a trace file from a successful connection to same CUCM from 64-bit Redhat 6 machine;

Older RedHat 6.x machine manages the encryptText (Asym) function in less than a second

31: Jul 19 15:16:46.655 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Entering encryptText)

32: Jul 19 15:16:47.044 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Exiting encryptText)

33: Jul 19 15:16:47.044 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Entering encryptText (Asym) function ====>)

34: Jul 19 15:16:47.056 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Exiting encryptText (Asym))

35: Jul 19 15:16:47.057 BST %JTAPI-PROTOCOL-7-UNK:(P1-192.168.28.23) [main] sending: com.cisco.cti.protocol.ProviderOpenRequest {

In contrast, here's the logging from Redhat 7.2 client which doesn't work. The server times out after 5 seconds

31: Jul 20 09:16:08.333 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Entering encryptText)

32: Jul 20 09:16:08.649 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Exiting encryptText)

33: Jul 20 09:16:08.649 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Entering encryptText (Asym) function ====>)

34: Jul 20 09:16:13.326 BST %JTAPI-PROTOCOL-7-UNK:(P1-192.168.28.23) received Event: com.cisco.cti.protocol.ProviderClosedEvent {

We've seen that on Redhat 7.2 it does work ever so rarely, maybe 1 in 30 attempts, and i've included the logfile below. You can see it took about 2.5 seconds to return from the encryption call.

31: Jul 20 09:16:45.673 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Entering encryptText)

32: Jul 20 09:16:45.992 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Exiting encryptText)

33: Jul 20 09:16:45.992 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Entering encryptText (Asym) function ====>)

34: Jul 20 09:16:48.528 BST %JTAPI-CTIIMPL-7-UNK:(P1-192.168.28.23) Provider.info(Exiting encryptText (Asym))

35: Jul 20 09:16:48.530 BST %JTAPI-PROTOCOL-7-UNK:(P1-192.168.28.23) [main] sending: com.cisco.cti.protocol.ProviderOpenRequest

I've tried changing java versions on the 7.2 machine but it makes no difference. The versions used are shown below.

/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.91-2.6.2.3.el7.x86_64/jre/bin/java

/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre/bin/java

/usr/java/jre1.8.0_91/bin/java (Latest)

*THE PROBLEM*
In order to encrypt the username / password using the Public Key and NONCE the CUCM provided - the Asymmetric encryption routine adds random salt using /dev/random but this does not populate enough random data within the 5 second window and therefore the CUCM disconnects the JTAPI client

*THE SOLUTION*
http://web.theurbanpenguin.com/centos-7-rngd-will-not-start/
https://www.certdepot.net/rhel7-get-started-random-number-generator/
The problem is the rngd.service is configured to add hardware event generated entropy to the /dev/random but Virtual machines don’t typically get constant hardware events (rngd will default to /dev/hwrandom which does not exist)
To fix it and use urandom entropy for populating random entropy:
systemctl status rngd
vi /usr/lib/systemd/system/rngd.service
Change line from
ExecStart=/sbin/rngd -f
to
ExecStart=/sbin/rngd -f -r /dev/urandom
systemctl daemon-reload
systemctl start rngd
systemctl status rngd

Caution: This is a pseudo solution because you fill in the /dev/random device with data from the /dev/urandom device: the quality of the pseudo random numbers delivered by the /dev/urandom device is simply lower. This can be a real problem if these numbers produce SSH keys for example.