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
Additional EMC Storage Documentation Number of Views Checking the SSL ciphers suites used by RSA Authentication Manager 8.2-8.7 SP2 Number of Views How to enable strong TLS/SSL cipher algorithms in RSA Identity Governance & Lifecycle Number of Views Secure Connection Between Identity Router and Identity Source (AD/LDAP) Fails When DHE Cipher Suites are Used Number of Views RSA SecurID 3.0 Software Token Quick Start Guide (Italian) Number of Views
Trending Articles
RSA Authentication Manager 8.7 SP2 Setup and Configuration Guide How to Download OTP Token Seed Files from myRSA RSA MFA Agent 2.3.6 for Microsoft Windows Installation and Administration Guide Microsoft Entra ID External MFA - Relying Party Configuration Using OIDC - RSA Ready Implementation Guide Module "SecurIDModule" could not be found message displayed in the web browser
Don't see what you're looking for?
