Identity Management and Governance: No available certificate or key corresponds to the SSL cipher suites which are enabled.
Originally Published: 2016-01-06
Article Number
Applies To
Issue
Sometimes when changing certificates, the following error can be found in the aveksaserver.log. This error is caused due to the process of actions when replacing the certificate.
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.
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket(JSSESocketFactory.java:150)
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:309)
Resolution
This error appears when the CN or FQDN are not correct with the certificate. It can be caused when the certificate is removed from the aveksa.keystore before a replacement certificate has been generated.
The solution is to:
- Back-up aveksa.keystore
- Generate new certificate
- Restart ACM
- Delete old certificate
These steps are written in more detail below.
>This information is verified by the engineering team within Jira ACM-51476.
>These steps are also within the guides for previous versions, however, these suggest to delete the old certificate before generating the new one. If the old certificate is deleted before the new one is generated, further issues can be caused and therefore the documentation has been changed in v7.0.
Procedure:
1. As the “Oracle” user, go to the keystore directory:
cd /home/oracle/keystore
2. Back up the aveksa.keystore:
cp aveksa.keystore aveksa.keystore.backup
3. Generate a new server certificate:
keytool -genkeypair -keysize -validity <#days> -alias -dname <“domain-name”> -keyalg -file -storepass -keystore
For example:
keytool -genkeypair -keysize 2048 -validity 18000 -alias mycorpServer - dname "CN=acmserver.mycorp.com,OU=Aveksa,O=MyCorp,L=Waltham,S=Massachusetts,C=US" - keyalg RSA -keypass Av3k5a15num83r0n3 -storepass Av3k5a15num83r0n3 - keystore aveksa.keystore
Note: RSA is the recommended key algorithm. The above example defines in the FQDN a server on which RSA Via L&G is running, a key size of 2048, and how long the certificate is valid (18000 days or ~50 years). The alias is myCorpServer. The alias cannot be the same as the alias used by any existing certificate. Also the CN value must be the exact URL from which RSA Via L&G will be accessed; if RSA Via L&G is accessed from any other address, the certificate will not secure the connection. If it is accessed from multiple URLs on the same server, a separate certificate must be generated for each URL.
4. Restart RSA Via L&G:
acm restart
5. Verify that the new certificate is being used by RSA Via L&G. Enter
keytool -list -v -storepass Av3k5a15num83r0n3 -keystore aveksa.keystore
In the list of certificates that displays, verify that Certficate[1] uses the alias of the new certificate.
6. If Certificate[1] uses the alias of the old certificate, delete the old certificate. Enter
keytool -delete -alias -storepass Av3k5a15num83r0n3 - keystore aveksa.keystore
Related Articles
Checking the SSL ciphers suites used by RSA Authentication Manager 8.2-8.7 SP2 Number of Views Disabling weak ciphers using port 1813 in RSA Authentication Manager 8.3 patch 1 Number of Views Password authentication fails for unchallenged users on AIX after changing to SHA256 password hashing when RSA Authenticat… Number of Views How to disable weaker DHE cipher modes (Logjam) in RSA DLP? Number of Views Authentication Manager Log Messages (10251-10294) Number of Views
Trending Articles
Passwordless Authentication in Windows MFA Agent for Active Directory – Quick Setup Guide RSA Authentication Manager 8.9 Release Notes (January 2026) RSA Authentication Manager Upgrade Process RSA Authentication Manager 8.7 SP2 Setup and Configuration Guide An example of SSO using SAML and ADFS with RSA Identity Management and Governance 6.9.x
Don't see what you're looking for?
