Access Manager servers are slow to start up.
3 years ago
Originally Published: 2012-11-22
Article Number
000051858
Applies To
RSA Access Manager 6.1
Red Hat Linux Enterprise
VMWare ESX Server
RSA Access Manager is configured for ANON or AUTH SSL.
Issue
Access Manager servers are slow to start up.
The RSA Access Manager servers are slow to start up.  There are no error messages logged.  The problem appears to be intermittent and the time to startup is sometimes a minute, sometimes as long as 10 minutes.  The pause seems to occur during creation of the servers listen port. 
If the servers is started with -DDEBUG_FULL you can see that there is a pause during the SSL initialization.
2012/11/21 15:15:12:206 [ssl] [main (sirrus.util.net.SSLSocketFactory.setEnabledCipherSuites)] - Available Ciphers:
2012/11/21 15:47:30:593 [ssl] [main (sirrus.util.net.SSLSocketFactory.printCiphers)] -       Cipher[0]: SSL_RSA_WITH_RC4_128_MD5

Cause
This is a problem that occurs during the initialization of the crypto providers for the SSL socket factory on some machines.  During the first invocation of the JAVA security libraries a call is made to the SecureRandom method to obtain a random number to seed the cryptographic routines. On systems with low entropy the call must wait until sufficient randomness before it returns a result.  On Linux operating system, specifically when it is virtualized it may take considerable time for the required randomness to be observed.  This is not specifically an RSA Access Manager issue but occurs for all Java applications run on these platforms. 
The following articles provide more information:
6521844 : SecureRandom hangs on Linux Systems
 

Resolution
This is not specifically a defect, but is designed to ensure that the SSL libraries are started securely.  If the system is slow to start you can attempt to use various hardware solutions to introduce randomness to the machine such as attaching a keyboard or mouse to the computer.
An alternative is to direct the crypto libraries to use an alternate source for the randomness.   Linux has an alternate file called urandom that can be used for this purpose.  Note that potentially using a random source with less entropy could reduce the robustness of some crypto features.
You can either modify the global java security.properties file and add the following line:
securerandom.source=file:/dev/./urandom
Or you modify the server startup batch files to pass the following parameter to each instance of the JVM that is started.
-Djava.security.egd=file:/dev/./urandom
Note that the security.properties file may already have a line that says "securerandom.source=file:/dev/urandom" which is similar to the example above but with a path that does not contain a dot.  Due to the way file handles are passed to JAVA by some operating systems this setting is ignored in this format.  You must include a "." (dot) in the path for the setting to be effective. 

Don't see what you're looking for?