Flashes (Alerts)
Abstract
After applying the following IBM i Java Group PTF levels, IBM Java Development Kit (JDK) 8 64‑bit and 32‑bit VMs upgraded to SR8 FP55 may begin to fail with the error:
java.lang.RuntimeException: Could not generate ECDHEMLKEM keypair
Other IBM JDK versions (11, 17, 21) on IBM i are not affected—only Java 8 (64‑bit and 32‑bit) VMs.
This issue can also affect the IBM i Administration (ADMIN) server, Integrated Web Services (IWS), Integrated Web Application Server (IAS), WebSphere Application Server (Traditional and Liberty), Tomcat, and Web Query instances running on Java 8 SR8 FP55.
Affected IBM i Java Group PTF Levels Providing Java 8 SR8 FP55:
IBM i 7.6 - SF99965 level 4
IBM i 7.5 - SF99955 level 19
IBM i 7.4 - SF99665 level 31
IBM i 7.3 - SF99725 level 40
Content
IBM i 7.5 - SF99955 level 19
IBM i 7.4 - SF99665 level 31
IBM i 7.3 - SF99725 level 40
Caused by: java.lang.RuntimeException: Could not generate ECDHEMLKEM keypair
Caused by: java.security.NoSuchAlgorithmException: ML-KEM-768 KeyPairGenerator not available
IBM APARs IJ57463: THE IBMJCEPLUS PROVIDER FAILED TO GENERATE AN ECDHEMLKEM KEYPAIR ON THE IBMI PLATFORM & IJ57394: THE IBMJCEPLUS PROVIDER FAILED TO GENERATE AN ECDHEMLKEM KEYPAIR ON THE IBMI PLATFORM are now closed. The fix will be delivered in the IBM JDK 8 SR8 FP65 release for IBM i OS targeted for 2Q 2026 release.
The IBMJCEPlus version introduced with the IBM i HTTP Group Levels (7.3 - 40 / 7.4 - 31 / 7.5 - 19 / 7.6 - 4) added support for the ECDHEMLKEM algorithm; however, this support included a platform‑level runtime block on IBM i. IBMJCEPlus is a multi‑platform JCE implementation, but on IBM i the algorithm was permitted in the JVM configuration and was not explicitly blocked from being negotiated when requested by a peer system. As a result, the TLS negotiation could begin, but ultimately failed because the algorithm was not actually available to the IBM i JDK at runtime.
The PTFs listed below update the configuration to ensure that negotiation for this algorithm is never attempted on IBM i. A future IBMJCEPlus version—delivered with Java 8 SR8 FP65—will fully enable IBM i to use this algorithm. When that version becomes available, the current configuration block will be removed and the algorithm will be allowed for default use.
IBM i 7.5 - 5770JV1
- JDK 8 32‑bit: SJ08633
- JDK 8 64‑bit: SJ08630
JDK 8 32‑bit: SJ08632
- JDK 8 64‑bit: SJ08631
IBM i 5770JV1 PTFs can be immediately temporarily applied. Restart the IBM i JVM job to pick up the change.
NOTE: This PTF does not fully resolve IBM WebSphere Application Server TLSv1.3 connection issues. IBM recommends all WebSphere on IBM i users apply the specified Java option, jdk.tls.namedGroups="x25519,secp256r1,secp384r1,secp521r1,x448,ffdhe2048,ffdhe3072,ffdhe4096", as a workaround using any of these methods.
- Add the jdk.tls.namedGroups="x25519,secp256r1,secp384r1,secp521r1,x448,ffdhe2048,ffdhe3072,ffdhe4096" custom property under your WebSphere Application Server's JVM Process Definition's Custom Properties.
- Click , and either WebSphere application servers > server_name or WebSphere proxy servers > server_name. Then, under Server Infrastructure, click
- Add the jdk.tls.namedGroups="x25519,secp256r1,secp384r1,secp521r1,x448,ffdhe2048,ffdhe3072,ffdhe4096" Java option to your /home/QEJBSVR/SystemDefault.properties (WAS user scope) or /QIBM/UserData/Java400/SystemDefault.properties (IBM i OS scope) file.
Temporarily disable the problematic X25519MLKEM768 TLSv1.3 namedGroup by customizing the JVM’s jdk.tls.namedGroups property to remove this value.
Note: The commands below extend to the right. Scroll horizontally to view and copy the full command.
STRQSH
touch -C 819 /QIBM/UserData/Java400/SystemDefault.properties
echo "jdk.tls.namedGroups=x25519,secp256r1,secp384r1,secp521r1,x448,ffdhe2048,ffdhe3072,ffdhe4096" >> /QIBM/UserData/Java400/SystemDefault.properties
F12
WRKLNK '/QIBM/UserData/Java400/SystemDefault.properties'
Option 2 to edit.
Verify the jdk.tls.namedGroups Java option exists correctly in the file.
Press F3 twice to save and exit.
Restart your Java 8 JVM job to pick up the change.Force the JVM to use only TLSv1.2, as this protocol does not use the problematic TLSv1.3 X25519MLKEM768 namedGroup.
Add the following JVM option:
-Djdk.tls.client.protocols=TLSv1.2
CRTSAVF QGPL/JV1BASE
CRTSAVF QGPL/JV1OPT16
CRTSAVF QGPL/JV1OPT17
CRTSAVF QGPL/JV1OPT20
etc.
SAVLICPGM LICPGM(5770JV1) DEV(*SAVF) OPTION(16) SAVF(QGPL/JV1OPT16)
SAVLICPGM LICPGM(5770JV1) DEV(*SAVF) OPTION(17) SAVF(QGPL/JV1OPT17)
SAVLICPGM LICPGM(5770JV1) DEV(*SAVF) OPTION(20) SAVF(QGPL/JV1OPT20)
etc.
CRTSAVF QGPL/JV1OPT16_N
CRTSAVF QGPL/JV1OPT17_N
CRTSAVF QGPL/JV1OPT20_N
etc.
SAVLICPGM LICPGM(5770JV1) DEV(*SAVF) OPTION(16) SAVF(QGPL/JV1OPT16_N)
SAVLICPGM LICPGM(5770JV1) DEV(*SAVF) OPTION(17) SAVF(QGPL/JV1OPT17_N)
SAVLICPGM LICPGM(5770JV1) DEV(*SAVF) OPTION(20) SAVF(QGPL/JV1OPT20_N)
etc.
End all Java 8 64 bit VMs.
DLTLICPGM LICPGM(5770JV1) OPTION(17)
RSTLICPGM LICPGM(5770JV1) DEV(*SAVF) OPTION(17) SAVF(QGPL/JV1OPT17)
End all Java 8 64 bit VMs.
DLTLICPGM LICPGM(5770JV1) OPTION(17)
RSTLICPGM LICPGM(5770JV1) DEV(*SAVF) OPTION(17) SAVF(QGPL/JV1OPT17_N)
Related Information
Was this topic helpful?
Document Information
Modified date:
13 March 2026
UID
ibm17257559