Question
Self
IN
Last activity: 5 Apr 2024 10:53 EDT
Pega 8.8.2 with WebSphere 8.5.5 is not supporting ECDHE_RSA_AES_256_GCM_SHA384 cipher
Hi All,
Pega 8.8.2 with WebSphere 8.5.5 .23 is not supporting ECDHE_RSA_AES_256_GCM_SHA384 cipher, not able to connect to MQ getting below error
Could not connect to MQ server located at mq-sit1.nam.nsroot.net MQJE001: Completion Code '2', Reason '2400'. - Unsupported CipherSuite: 1. Check the CipherSuite specified by the application. 2. Check that JSSE is correctly installed. com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2400'. at com.ibm.mq.MQManagedConnectionJ11.constructMQCD(MQManagedConnectionJ11.java:1442) ~[com.ibm.mq.jar:?]
***Edited by Moderator Marije to add Case INC-A23657 ***
Accepted Solution
Updated: 5 Apr 2024 10:53 EDT
Pegasystems Inc.
GB
@Prashanthks INC-A23657 has been closed temporarily as per your request January 19th:
This was the analysis on February 2nd:.
JMS Listener is unable to connect to new tibco server which contains strong ciphers
Notes:
- In lower environments (DEV, QA etc..) the issue does NOT occur. The pega application is able to connect to the new tibco server (strong ciphers)
- Client has confirmed that configuration is identiical, but in PROD we are observing the No appropriate protocol (protocol is disabled or cipher suites are inappropriate) error
- Pega Level DEBUG loggers are enabled but are not printing to the logs.
- Client is unable to make -Djavax.net.debug JVM level changes to enable SSL debug
Next steps:
Client to enabled at the JVM level and provide server logs with -Djavax.net.debug from both production and lower environment for comparison
Update after further investigation:
The Tibco jars were included in the production system by importing them in the standard fashion. They were also included in the WAR deployment, but weren't picked up from the WAR path because of the fact the jars were loaded to the database.
In lower environments the Tibco jars were only provided in the WAR deployment, and with slightly different Tibco optional jars included.
@Prashanthks INC-A23657 has been closed temporarily as per your request January 19th:
This was the analysis on February 2nd:.
JMS Listener is unable to connect to new tibco server which contains strong ciphers
Notes:
- In lower environments (DEV, QA etc..) the issue does NOT occur. The pega application is able to connect to the new tibco server (strong ciphers)
- Client has confirmed that configuration is identiical, but in PROD we are observing the No appropriate protocol (protocol is disabled or cipher suites are inappropriate) error
- Pega Level DEBUG loggers are enabled but are not printing to the logs.
- Client is unable to make -Djavax.net.debug JVM level changes to enable SSL debug
Next steps:
Client to enabled at the JVM level and provide server logs with -Djavax.net.debug from both production and lower environment for comparison
Update after further investigation:
The Tibco jars were included in the production system by importing them in the standard fashion. They were also included in the WAR deployment, but weren't picked up from the WAR path because of the fact the jars were loaded to the database.
In lower environments the Tibco jars were only provided in the WAR deployment, and with slightly different Tibco optional jars included.
After deleting the Tibco jars from the production database, clearing the Pega temporary directories and restarting, we were able to point the JVM JDK version to latest java and the JMS connectivity looks good
Pegasystems Inc.
US
Are you using a non-IBM JRE? If yes, then you can try to use the following setting
-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
more details available here:
The error commonly occurs if using a non-IBM JRE (like Oracle JRE)
Updated: 29 Dec 2023 9:46 EST
Self
IN
Hi @PhilipShannon,
Thank you for the response, we using IBM JRE only below is the version.
Java version = 1.8.0_351, Java Runtime Version = Proprietary information hidden
Pegasystems Inc.
US
@Prashanthks Next I would try the latest IBM version which seems to be ibm-java-jre-8.0-8.15
This article from IBM could provide a method to collect more details: How can I verify that an application is over-riding Websphere's default JSSE socket factory? (ibm.com)
Self
IN
With ibm-java-jre-8.0-8.15, i am getting different error like below, but queue manger is up and running.,
Could not connect to MQ server located at mq-sit1.nam.nsroot.net MQJE001: Completion Code '2', Reason '2059'. - Queue manager is not available for connection.
With ibm java Proprietary information hidden getting logs with java call stack.
With ibm-java-jre-8.0-8.15, i am getting different error like below, but queue manger is up and running.,
Could not connect to MQ server located at mq-sit1.nam.nsroot.net MQJE001: Completion Code '2', Reason '2059'. - Queue manager is not available for connection.
With ibm java Proprietary information hidden getting logs with java call stack.
13:00:27.103 0x6120a00 j9trc_aux.0 - jstacktrace: 13:00:27.103 0x6120a00 j9trc_aux.1 - [1] com.ibm.jsse2.SSLSocketFactoryImpl.createSocket (SSLSocketFactoryImpl.java:12) 13:00:27.103 0x6120a00 j9trc_aux.1 - [2] com.tibco.tibjms.TibjmsxLinkSSL.connect (TibjmsxLinkSSL.java:652) 13:00:27.103 0x6120a00 j9trc_aux.1 - [3] com.tibco.tibjms.TibjmsConnection._create (TibjmsConnection.java:1419) 13:00:27.103 0x6120a00 j9trc_aux.1 - [4] com.tibco.tibjms.TibjmsConnection.<init> (TibjmsConnection.java:4438) 13:00:27.103 0x6120a00 j9trc_aux.1 - [5] com.tibco.tibjms.TibjmsQueueConnection.<init> (TibjmsQueueConnection.java:39) 13:00:27.103 0x6120a00 j9trc_aux.1 - [6] com.tibco.tibjms.TibjmsxCFImpl._createImpl (TibjmsxCFImpl.java:202) 13:00:27.103 0x6120a00 j9trc_aux.1 - [7] com.tibco.tibjms.TibjmsxCFImpl._createConnection (TibjmsxCFImpl.java:255)
Updated: 5 Feb 2024 5:23 EST
Pegasystems Inc.
GB
@Prashanthks you have an open support ticket - please use the MSP to continue working with GCS on INC-A23657
As @shanp correctly pointed out, please use the supported stack.
The error 'MQJE001: Completion Code '2', Reason '2059' typically indicates that the queue manager is not available for connection. This could be due to various reasons such as the queue manager being down, network issues, or incorrect connection parameters. However, without more specific information, it's hard to provide a definitive answer.
Received MQ message Exception: MQJE001: Completion Code '2', Reason '2033'
@Prashanthks you have an open support ticket - please use the MSP to continue working with GCS on INC-A23657
As @shanp correctly pointed out, please use the supported stack.
The error 'MQJE001: Completion Code '2', Reason '2059' typically indicates that the queue manager is not available for connection. This could be due to various reasons such as the queue manager being down, network issues, or incorrect connection parameters. However, without more specific information, it's hard to provide a definitive answer.
Received MQ message Exception: MQJE001: Completion Code '2', Reason '2033'
I can see that you logged support tickets for this issue:
CLOSED:
1. INC-253586 (MQ server connectivity is failing INC-241716)
At the time our GCS team tried to help you further but they received no response. They requested :
1) Provide Application server, Mq Server version details and also Java version that application is using? 2) What are the MQ jars you are using, How you are loading these Mq jars into classpath? 3) Are you using Jvm argument: -Dcom.ibm.mq.cfg.useIBMCipherMappings? If yes what is the value set? 4) Set Jvm argument -Djavax.net.debug=ssl,handshake Restart server, capture server logs then respoduce the issue and share the logs with us
2. INC-257135 (MQ server connectivity is failing with strong ciphers)
Root cause due to infrastructure: [1/19/23 1:20:39:826 CST] 000000ad SystemOut O 2023-01-19 01:20:39,775 [ WebContainer : 10] [TABTHREAD2] [ ] [ Disputes:01.01.09] ( messaging.mq.MQUtils) ERROR gtcrd-pegla03d.nam.nsroot.net|gtcrd-pegla03d.nam.nsroot.net ps53083.dev - Could not connect to MQ server located at mq-sit2.nam.nsroot.net MQJE001: Completion Code '2', Reason '2400'. - Unsupported CipherSuite: 1. Check the CipherSuite specified by the application. 2. Check that JSSE is correctly installed. com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2400'.
Solution description: Client should check the JVM JCE files.
3. INC-A29760 (MQ connection issues in Pega 8.8.2)
this issue occurred when DB connection is being made with a user who does not have privileges to query the pr_engineclasses table in the rules schema. solution was to recheck the privileges to the table that you modifying? ·
OPEN:
4. INC-A23657 (JMS connectivity is failing after latest cipher update)
GCS checked you java.security files and a week ago contacted you to provide their analysis:
There is a difference in the property "crypto.policy" in working and non-working environment. Can you confirm why there is a difference? Also, can you confirm that the jars present in their jre/lib/security matching in both working and non working environments?
---> Again, GCS is waiting for your response. Please continue to work on the open ticket via the MSP, (not the PSC).
******************UPDATE 5 FEBURARY:***************************
Ticket was closed due to inactivity:
Notes:
- In lower environments (DEV, QA etc..) the issue does NOT occur. The pega application is able to connect to the new tibco server (strong ciphers)
- Client has confirmed that configuration is identitical, but in PROD we are observing the No appropriate protocol (protocol is disabled or cipher suites are inappropriate) error
- Pega Level DEBUG loggers are enabled but are not printing to the logs.
- Due to production freeze client is unable to make -Djavax.net.debug JVM level changes to enable SSL debug
Next steps:
We are currently blocked because we need net.debug logs enabled at the JVM level.
Client to speak with manager to enable net.debug in production
We can then compare the logs with the working connectivity in lower environment to identify the fail over
Please contact GCS via MSP ticket to provide server logs with -Djavax.net.debug enabled from both production and lower environment for comparison
Self
IN
Accepted Solution
Updated: 5 Apr 2024 10:53 EDT
Pegasystems Inc.
GB
@Prashanthks INC-A23657 has been closed temporarily as per your request January 19th:
This was the analysis on February 2nd:.
JMS Listener is unable to connect to new tibco server which contains strong ciphers
Notes:
- In lower environments (DEV, QA etc..) the issue does NOT occur. The pega application is able to connect to the new tibco server (strong ciphers)
- Client has confirmed that configuration is identiical, but in PROD we are observing the No appropriate protocol (protocol is disabled or cipher suites are inappropriate) error
- Pega Level DEBUG loggers are enabled but are not printing to the logs.
- Client is unable to make -Djavax.net.debug JVM level changes to enable SSL debug
Next steps:
Client to enabled at the JVM level and provide server logs with -Djavax.net.debug from both production and lower environment for comparison
Update after further investigation:
The Tibco jars were included in the production system by importing them in the standard fashion. They were also included in the WAR deployment, but weren't picked up from the WAR path because of the fact the jars were loaded to the database.
In lower environments the Tibco jars were only provided in the WAR deployment, and with slightly different Tibco optional jars included.
@Prashanthks INC-A23657 has been closed temporarily as per your request January 19th:
This was the analysis on February 2nd:.
JMS Listener is unable to connect to new tibco server which contains strong ciphers
Notes:
- In lower environments (DEV, QA etc..) the issue does NOT occur. The pega application is able to connect to the new tibco server (strong ciphers)
- Client has confirmed that configuration is identiical, but in PROD we are observing the No appropriate protocol (protocol is disabled or cipher suites are inappropriate) error
- Pega Level DEBUG loggers are enabled but are not printing to the logs.
- Client is unable to make -Djavax.net.debug JVM level changes to enable SSL debug
Next steps:
Client to enabled at the JVM level and provide server logs with -Djavax.net.debug from both production and lower environment for comparison
Update after further investigation:
The Tibco jars were included in the production system by importing them in the standard fashion. They were also included in the WAR deployment, but weren't picked up from the WAR path because of the fact the jars were loaded to the database.
In lower environments the Tibco jars were only provided in the WAR deployment, and with slightly different Tibco optional jars included.
After deleting the Tibco jars from the production database, clearing the Pega temporary directories and restarting, we were able to point the JVM JDK version to latest java and the JMS connectivity looks good