|Applies To||Affected Versions: 6.x; 5.x|
After following the keytool certificate commands to generate a CSR, and importing the CA response file (ie the signed Certificate request) to the aveksa.keystore file, we are now seeing java errors in the aveksaServer.log and we still are not able to access the ACM UI 'securely'. How do we resolve this error?
The errors seen in the aveksaServer.log are:
06/08/2012 10:37:31.925 ERROR (http-0.0.0.0-8443-Acceptor-0) [org.apache.tomcat.util.net.JIoEndpoint] Socket accept failed java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
This error is typically a result of missing data from the aveksa.keystore file. When searching for similar errors on the internet, a command response found is: "A likely explanation is that the server cannot find the alias for the server key within the specified keystore. Check that the correct keystore File and keyAlias are specified in the <Connector> element in the <server> configuration file. REMINDER - keyAlias values may be case sensitive."
Review of our documentation shows that it does not clearly define a 'sequence' for the certificate commands to be executed to correctly insert the signed certificate. What some customers are doing is something like the following:
1) generating the CSR
2) Importing the 'signed' CSR, by following the steps outlined under 'Replacing the certificate'
a. Remove the existing server certificate:
b. Import the new server certificate:
The error is a result of deleting the existing 'server' alias key from the aveksa.keystore file.
|Resolution||The correct sequence would be to only execute the command listed in 2.b shown above, assuming that the file referenced as <myServerCert> is the signed server certificate response file created by the CSR generation, also shown above. The key referenced by -alias in the CSR creation should NOT be deleted before importing the signed certificate response file.|
If a different FQDN is going to be used for the URL for the Aveksa Application, then a NEW certificate key should be created, rather than making use of the current default, known by the alias of 'server'.