000016755 - Access Manager servers are slow to start up.

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000016755
Applies ToRSA Access Manager 6.1
Red Hat Linux Enterprise
VMWare ESX Server
RSA Access Manager is configured for ANON or AUTH SSL.
IssueAccess 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
CauseThis 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
 
ResolutionThis 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. 
Legacy Article IDa60168

Attachments

    Outcomes