IBM JCE FIPS Null Pointer Error using OpenJDK 11.0.5

[steigerwalda]

SSL connections established using the IBM JCE FIPS provider contained in the ibmjcefips.jar version Implementation-Version: 1.71 build_20180712 (from the JAR's manifest file) fail with a null pointer exception in OpenJDK 11.0.5. They have never failed this way before in OpenJDK 11.0.4 or earlier versions.

The following is a partial SSL debug stack trace:

javax.net.ssl|DEBUG|0C|ActiveMQ Transport: ssl://localhost/127.0.0.1:61617|2019-11-14 18:03:02.829 UTC|SSLSocketOutputRecord.java:241|WRITE: TLS12 handshake, length = 1353 javax.net.ssl|DEBUG|0C|ActiveMQ Transport: ssl://localhost/127.0.0.1:61617|2019-11-14 18:03:02.858 UTC|ECDHClientKeyExchange.java:399|Produced ECDHE ClientKeyExchange handshake message ( "ECDH ClientKeyExchange": { "ecdh public": { 0000: 04 16 05 33 E5 4E FD B1 F5 F3 EC 5A 74 6E 0E 17 ...3.N.....Ztn.. 0010: 50 49 BC 65 D6 95 D3 ED 76 21 0B 59 DC 20 32 00 PI.e....v!.Y. 2. 0020: D6 C5 EA 5A 04 41 9E 7C 66 5A 66 C3 12 42 0F FF ...Z.A..fZf..B.. 0030: 98 ED 10 39 C6 52 7D 6F 15 57 A0 C1 4C 2B 30 58 ...9.R.o.W..L+0X 0040: 47 G }, } ) javax.net.ssl|DEBUG|0C|ActiveMQ Transport: ssl://localhost/127.0.0.1:61617|2019-11-14 18:03:02.858 UTC|SSLSocketOutputRecord.java:241|WRITE: TLS12 handshake, length = 70 javax.net.ssl|WARNING|0C|ActiveMQ Transport: ssl://localhost/127.0.0.1:61617|2019-11-14 18:03:02.879 UTC|SSLSocketImpl.java:1288|handling exception ( "throwable" : { java.lang.NullPointerException at com.ibm.crypto.fips.provider.RSAPSSSignature.b(Unknown Source) at com.ibm.crypto.fips.provider.RSAPSSSignature.c(Unknown Source) at com.ibm.crypto.fips.provider.RSAPSSSignature.engineSign(Unknown Source) at java.base/java.security.Signature$Delegate.engineSign(Signature.java:1404) at java.base/java.security.Signature.sign(Signature.java:713) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.(CertificateVerify.java:582) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:740) at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182) at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)

[ibmfjk]

I met the same issue, do anyone know how to fix it?

[yeekangc]

@shellberg, can you please chime in?

[yeekangc]

Hi @steigerwalda @ibmfjk. Are you working with particular set of IBM products here?

Are you trying to take IBM JCE FIPS provider from an IBM Java SDK and trying to get it to work with OpenJDK 11?

Cc @mstoodle

[ibmfjk]

my issue if fixed in in https://www.ibm.com/support/pages/node/6422887

[shellberg]

In the context of IBM's WebSphere Application Server, then APAR PH34651 (supporting the above cited technote) would apply.

The reference to Apache's 'ActiveMQ Transport' in the partial SSL debug trace reported might suggest this is experienced outside of an IBM Product, although there are some which embed Apache ActiveMQ.

Furthermore, there are going to be two ends to an SSL communication! By virtue of this question being raised in the context of FIPS operation, one of those ends is likely to be in FIPS mode: probably the 'server' side of this transaction? That could well be an IBM Java (JRE) instance, which likely includes ibmjcefips.jar. The SSL debug (above) is likely captured at that end. The other end, the 'client' might represent the OpenJDK 11 referenced? It would be good to obtain clarification. (Embedding an ibmjcefips.jar with an OpenJDK 11 implementation, and its corresponding configuration files, is not a tested/designed combination! I'd expect to experience more usage problems trying that integration!)

Still, outside of the context of WAS (and APAR PH34651), it might be worth considering why RSAPPS should be disabled with FIPS at all for more general consumption/application to troubleshoot the above experiences. And, without referencing current FIPS-related documentation (see NIST Special Publications) on presently acceptable ciphers, my concern with RSAPPS (or RSASSA-PSS) is peaked simply by reference to its default use of SHA-1. SHA-1 is considered insufficiently secure, that is compromisable, in the current cybersecurity arms race. Therefore, by default, RSAPPS is likely inadequate, and you would likely need to ensure it is consistently re-configured (including associated certificates/digital signatures) with a minimum of SHA-256 (better would be SHA-384 or SHA-512) in use everywhere with respect to RSAPPS. That is, the RSAPPS algorithm is not absolutely rejected for use with FIPS, but likely just not in its default configuration. FIPS compliance enforces such things as bit lengths, size of primes, etc. used within cryptographic related calculations, and whilst the encryption algorithm (e.g. RSAPPS) may potentially be acceptable, if attempts to use it with inadequate key lengths, for example, would result in a failure to establish the secure FIPS-compliant communications. (The failure in the above SSL debug trace essentially means that there was found no provider in FIPS mode for the negotiated cipher, which in the case of RSAPPS needs to be supported by parameters communicated separately; usually with the certificate exchanged. Should the client-side certificate offered be based on SHA-1, then it would render the digital signature with insufficient key lengths, etc. and no 'SHA-1-based provider for RSAPPS' would be found in FIPS compliant mode, leading to the NPE reported by the server. Sorry, FIPS-mode failures are simply harder to describe with 'useful' easily-interpretable error messages! That is because of the places in the implementation code that current FIPS bounds are enforced. Its as if those not privy to the security apparatus make it harder by obscurity to troubleshoot writing applications that meet its standards.)

@yeekangc Hopefully some helpful commentary. Thanks for the referral.

[yeekangc]

Glad to hear that your issue is resolved, @ibmfjk.

@steigerwalda, does the above discussion/elaboration help with what you have? Please let us know if you have additional questions.