Skip navigation

Log in to create and rate content, and to follow, bookmark, and share content with other members.

AnsweredAssumed Answered

SSLHandshakeException on RSA IG&L 7.1.1

Question asked by Jacques Adankon on Nov 20, 2020
Latest reply on Dec 3, 2020 by Ian Staines

Like • Show 0 Likes0
Comment • 10

Hello,

I'm trying to configure the Generic REST Connector on RSA IG&L 7.1.1 to implement a provisioning to Wallix endpoint.

When I run the test suite for the "login" capability, I get the error below.

Do you know how to solve this problem?

Thank you in advance for your help.

Login

Total number of processing errors = 1

Iteration 0

Parameter Name	Value

Error code = -1

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Cause:     


Stack Trace:

org.mule.transport.http.HttpClientMessageDispatcher.execute(HttpClientMessageDispatcher.java:151)

org.mule.transport.http.HttpClientMessageDispatcher.doSend(HttpClientMessageDispatcher.java:279)

org.mule.transport.AbstractMessageDispatcher.process(AbstractMessageDispatcher.java:84)

org.mule.transport.AbstractConnector$DispatcherMessageProcessor.process(AbstractConnector.java:2637)

org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24)

org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58)

org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44)

org.mule.processor.chain.SimpleMessageProcessorChain.doProcess(SimpleMessageProcessorChain.java:43)

org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67)

org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24)

org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44)

org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:102)

org.mule.endpoint.outbound.OutboundResponsePropertiesMessageProcessor.process(OutboundResponsePropertiesMessageProcessor.java:35)

org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24)

org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58)

org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44)

org.mule.processor.chain.SimpleMessageProcessorChain.doProcess(SimpleMessageProcessorChain.java:43)

org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67)

org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24)

org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44)

org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:102)

org.mule.processor.EndpointTransactionalInterceptingMessageProcessor$1.process(EndpointTransactionalInterceptingMessageProcessor.java:46)

org.mule.processor.EndpointTransactionalInterceptingMessageProcessor$1.process(EndpointTransactionalInterceptingMessageProcessor.java:43)

org.mule.execution.ExecuteCallbackInterceptor.execute(ExecuteCallbackInterceptor.java:16)

org.mule.execution.BeginAndResolveTransactionInterceptor.execute(BeginAndResolveTransactionInterceptor.java:54)

org.mule.execution.ResolvePreviousTransactionInterceptor.execute(ResolvePreviousTransactionInterceptor.java:44)

org.mule.execution.SuspendXaTransactionInterceptor.execute(SuspendXaTransactionInterceptor.java:50)

org.mule.execution.ValidateTransactionalStateInterceptor.execute(ValidateTransactionalStateInterceptor.java:40)

org.mule.execution.IsolateCurrentTransactionInterceptor.execute(IsolateCurrentTransactionInterceptor.java:41)

org.mule.execution.ExternalTransactionInterceptor.execute(ExternalTransactionInterceptor.java:48)

org.mule.execution.TransactionalExecutionTemplate.execute(TransactionalExecutionTemplate.java:65)

org.mule.processor.EndpointTransactionalInterceptingMessageProcessor.process(EndpointTransactionalInterceptingMessageProcessor.java:52)

org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24)

org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.ja...

Jacques Adankon Dec 3, 2020 5:48 AM

Correct Answer

Hello Ian,

As suggested, I have opened a support case to get some help. We have captured and analyzed SSL negotiation packets with the tcpdump tool.

By comparing with RSA 7.2.0 SSL packets, we noticed that the connection required more secured encryption algorithms, so we updated java jdk version and it solved the problem.

Thank you again.

See the reply in context

No one else had this question

Outcomes

10 Replies

Ian Staines Nov 23, 2020 3:40 PM
Mark Correct
Correct Answer
This looks like an RSA Identity Governance & Lifecycle question. I will move it one of the RSA Identity & Lifecycle groups so it gets more visibility.
Like • Show 1 Like1
Actions
- Ian Staines @ Ian Staines on Nov 23, 2020 3:51 PM
  Mark Correct
  Correct Answer
  This is likely an SSL issue similar to the following.
  
  000037971 - RSA Identity Governance & Lifecycle ServiceNow connector fails with "handshake_failure" hi
  
  This is an active failure where the endpoint is refusing the connection from IG&L because the java security settings on the server do not adhere to current standards. It is unlikely the endpoint will reduce security to allow this connection so you must increase the security on RSA IG&L.
  
  Likely you are running an older version of Java on this server. Upgrade java according to the method appropriate for the type of appliance you are using.
  
  Note that there are also dependencies between the version of Java that you use and the RSA IG&L version.
  1 person found this helpful
  Like • Show 1 Like1
  Actions
Ahmed Nofal Nov 24, 2020 6:10 AM
Mark Correct
Correct Answer
did you import the Wallix certificates to the java truststore that the AFX server is running on?
1 person found this helpful
Like • Show 0 Likes0
Actions
- Jacques Adankon @ Ahmed Nofal on Nov 24, 2020 11:02 AM
  Mark Correct
  Correct Answer
  Yes I did it but I got the same issue.
  Like • Show 0 Likes0
  Actions
  - Ian Staines @ Jacques Adankon on Nov 24, 2020 1:23 PM
    Mark Correct
    Correct Answer
    I recommend you get more detail about the actual SSL failure. This can be done in either of two ways.
    
    Turning on SSL debugging in the JVM using -Djavax.net.debug=ssl (Internal KB article 000033388)
    Capturing a tcpdump packet capture of the SSL negotiation on the REST port.
    
    Both of these are advanced techniques so if you need assistance with gathering or analyzing this information I recommend you open a Support case and quote this discussion.
    1 person found this helpful
    Like • Show 0 Likes0
    Actions
    - Jacques Adankon @ Ian Staines on Nov 30, 2020 4:32 AM
      Mark Correct
      Correct Answer
      Hello Ian,
      
      After I turn on the SSL debugging, which file should I look for to get detailed information?
      Like • Show 0 Likes0
      Actions
- Jacques Adankon @ Ahmed Nofal on Nov 30, 2020 4:31 AM
  Mark Correct
  Correct Answer
  Hello Ahmed,
  
  I have added the chain of certificates in the file $JAVA_HOME/jre/lib/security/cacerts.
  Is it the right file?
  Like • Show 0 Likes0
  Actions
  - Ian Staines @ Jacques Adankon on Nov 30, 2020 2:34 PM
    Mark Correct
    Correct Answer
    It depends on the application server, but SSL debug output goes to the aveksaserver.log file on Wildly. Be aware the output will be massive. Do not do this in production or it will bring your system down.
    Like • Show 1 Like1
    Actions
    - Jacques Adankon @ Ian Staines on Dec 3, 2020 5:48 AM
      Unmark Correct
      Correct Answer
      Hello Ian,
      
      As suggested, I have opened a support case to get some help. We have captured and analyzed SSL negotiation packets with the tcpdump tool.
      By comparing with RSA 7.2.0 SSL packets, we noticed that the connection required more secured encryption algorithms, so we updated java jdk version and it solved the problem.
      
      Thank you again.
      1 person found this helpful
      Like • Show 1 Like1
      Actions
      - Ian Staines @ Jacques Adankon on Dec 3, 2020 7:16 PM
        Mark Correct
        Correct Answer
        I also go to tcpdump before SSL tracing but each has its role. tcpdump will often tell you if there is a firewall involved where the SSL tracing will not.
        Like • Show 0 Likes0
        Actions

Recommended Content