SAPJCE module is breaking JMX calls for SAP BOE 4.3 upgrade

114 views

Skip to first unread message

Randy Stephenson

unread,

Aug 20, 2024, 3:53:48 PM8/20/24

to WildFly

If anyone could offer advice on a solution or how to debug this it would be greatly appreciated.

On WildFly 18, a new module was added for SAP's BOE 4.3 upgrade. The app makes calls for Crystal Reports, and that is working fine.

But now the JMX calls from Zabbix to the Wildfly server for monitoring are failing on the SSL handshake. This error is generated every time a monitoring request is sent to the WildFly server. java.lang.NoClassDefFoundError: sun/security/internal/spec/TlsKeyMaterialParameterSpec

This upgrade required some new DLLs for the JRE, and also a new module.
...\modules\system\layers\base\com\sap\commoncryptolib\provider\main

<?xml version='1.0' encoding='UTF-8'?>

<module xmlns="urn:jboss:module:1.1" name="com.sap.commoncryptolib.provider">

<resources>
<resource-root path="sapjce-14.3.3.4433.jar"/>
</resources>

<dependencies>
<module name="javax.api"/>
<module name="org.apache.log4j"/>
</dependencies>
</module>

New DLLs in JVM lib:
sapcrypto.dll
slcryptokernel.dll
slcryptokernel.dll.sha256

The new SAPJCE classes are getting referenced in the call stack. So the JMX calls are referencing the SAP JCE provider, and I'm not sure if that's supposed to happen, since monitoring has nothing to do with SAP.

2024-06-07 00:00:22,736 ERROR [org.jboss.threads.errors] (management task-1) Thread Thread[management task-1,5,main] threw an uncaught exception: java.lang.NoClassDefFoundError: sun/security/internal/spec/TlsKeyMaterialParameterSpec
at com.sap.commoncryptolib.provider.TlsKeyMaterialKeyGenerator.engineInit(Unknown Source)

at javax.crypto.KeyGenerator.init(KeyGenerator.java:454)

at javax.crypto.KeyGenerator.init(KeyGenerator.java:430)

at sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:265)

at sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:115)

at sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:77)

at sun.security.ssl.ECDHClientKeyExchange$ECDHEClientKeyExchangeConsumer.consume(ECDHClientKeyExchange.java:532)

at sun.security.ssl.ClientKeyExchange$ClientKeyExchangeConsumer.consume(ClientKeyExchange.java:110)

at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:377)

at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)

at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:981)

at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:968)

at java.security.AccessController.doPrivileged(Native Method)

at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:915)

at io.undertow.protocols.ssl.SslConduit$5.run(SslConduit.java:1047)

at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)

at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)

at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)

at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)