[OPENDJ-5761] java.security.InvalidKeyException during SSL Handshake with keys in SoftHSM Created: 29/Nov/18  Updated: 20/Aug/20

Status: Dev backlog
Project: OpenDJ
Component/s: security
Affects Version/s: 7.0.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ondrej Fuchsik Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

jdk11


Issue Links:
Relates
is related to OPENIDM-13935 SSLError("bad handshake: 'Unexpected ... Closed
is related to OPENIDM-15304 PyForge: fix user_authenticates_with_... Resolved

 Description   

This issue occurs only when using jdk11 and the same test works with jdk8.

The core of the test is a configuration of DJ and SoftHSM and check that we can do an ldapsearch on secured port with SSL.

The configuration is done in the following steps:

1. Initialization of token

./softhsm-2.4.0/softhsm-product/bin/softhsm2-util --init-token --slot 0 --label "My token 1" --pin password --so-pin password

 

2. Generation of the config file with the slot number from point 1 (1472140508) and sofHsm library path

name = SoftHSM
library = /pyforge/results/20181129-142130/security_group/HardwareSecurityModule/HSM1/softhsm-2.4.0/softhsm-product/lib/softhsm/libsofthsm2.so
slot = 1472140508
attributes(generate, *, *) = {
CKA_TOKEN = true
}
attributes(generate, CKO_CERTIFICATE, *) = {
CKA_PRIVATE = false
}
attributes(generate, CKO_PUBLIC_KEY, *) = {
CKA_PRIVATE = false
}
attributes(*, CKO_SECRET_KEY, *) = {
CKA_PRIVATE = false
CKA_EXTRACTABLE = false
}

3. Generation of key-pair

/usr/lib/jvm/openjdk11/bin/keytool -genkey -alias server-cert -keyalg RSA -keysize 2048 -ext "san=dns:pyforge.example.com" -dname "CN=opendj.example.com,O=Example Corp,C=FR" -keystore NONE -storetype PKCS11 -storepass password -providerClass sun.security.pkcs11.SunPKCS11 -providerArg /pyforge/results/20181129-142130/security_group/HardwareSecurityModule/HSM1/softhsm-2.4.0/conf/hsm.conf

 

4. Self-sign of the cert

/usr/lib/jvm/openjdk11/bin/keytool -selfcert -alias server-cert -keystore NONE -storetype PKCS11 -storepass password -providerClass sun.security.pkcs11.SunPKCS11 -providerArg /pyforge/results/20181129-142130/security_group/HardwareSecurityModule/HSM1/softhsm-2.4.0/conf/hsm.conf

 

5. Modification of java.properties with security.provider

start-ds.java-args= -Djava.security.properties=file:///pyforge/results/20181129-142130/security_group/DJ1/opendj/config/java.security -server

 

6. DS restart

/pyforge/results/20181129-142130/security_group/DJ1/opendj/bin/stop-ds -R

 

7. Creation of key manager provider

 

/pyforge/results/20181129-142130/security_group/DJ1/opendj/bin/dsconfig -h pyforge.example.com -p 4444 -D "cn=Directory Manager" -w password -X create-key-manager-provider --provider-name SoftHSM --type pkcs11 --set enabled:true --set key-store-pin:password -n

 

8. Setting LDAPS connection handler

 

/pyforge/results/20181129-142130/security_group/DJ1/opendj/bin/dsconfig -h pyforge.example.com -p 4444 -D "cn=Directory Manager" -w password -X set-connection-handler-prop --handler-name "LDAPS" --set listen-port:1636 --set enabled:true --set use-ssl:true --set key-manager-provider:SoftHSM -n

 

 

The final step is following ldapsearch*:*

 

/home/fuchsik/forks/pyforge/results/20181129-142130/security_group/DJ1/opendj/bin/ldapsearch -h pyforge.example.com -p 1636 -D "cn=Directory Manager" -w password -b "dc=com" --useSSL -X "(uid=dmiller)" cn	

 

The result is:

-- rc -- 
returned 91, expected to be in [0] 
-- stdout -- 
-- stderr -- 
Unable to connect to the server: 91 (Connect Error) Additional Information: The LDAP connection has failed because an error occurred during the SSL handshake: java.io.EOFException

With debug info enabled I was able to get the handshake error:

javax.net.ssl|ERROR|2B|LDAPS 0.0.0.0 port 1636(2) SelectorRunner|2018-11-29 09:13:35.274 CET|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Cannot produce CertificateVerify signature (
"throwable" : {
java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey
at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1163)
at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1204)
at java.base/java.security.Signature.initSign(Signature.java:546)
at java.base/sun.security.ssl.SignatureScheme.getSignature(SignatureScheme.java:473)
at java.base/sun.security.ssl.CertificateVerify$T13CertificateVerifyMessage.<init>(CertificateVerify.java:895)
at java.base/sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.onProduceCertificateVerify(CertificateVerify.java:1077)
at java.base/sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.produce(CertificateVerify.java:1070)
at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1189)
at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1125)
at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:831)
at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:792)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1065)
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1052)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:999)
at org.glassfish.grizzly.ssl.SSLUtils.executeDelegatedTask(SSLUtils.java:274)
at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:709)
at org.glassfish.grizzly.ssl.SSLFilter.doHandshakeStep(SSLFilter.java:332)
at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:623)
at org.glassfish.grizzly.ssl.SSLBaseFilter.handleRead(SSLBaseFilter.java:335)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.SameThreadIOStrategy.executeIoEvent(SameThreadIOStrategy.java:103)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89)
at org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:415)
at org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:384)
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:348)
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:279)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573)
at java.base/java.lang.Thread.run(Thread.java:834)}
)

I can attach full debug info if needed.

As said before this works fine with jdk1.8.


This issue is reproducible with:

 

python3 run-pybot -s security_group.hardwareSecurityModule -v dj

Please make sure that config.cfg contains correct path to your jdk11.

It's useful to let instances run after the test finish with -n option:

python3 run-pybot -s security_group.hardwareSecurityModule -v -n dj

In such a case, it's possible to stop DS, edit the java.properties to log SSL handshake info to server.out and start it again. After that, run the ldapsearch from report.html and see details of the handshake.

 



 Comments   
Comment by Fabio Pistolesi [ 16/Jan/19 ]

Long debug session... It all boils down to SoftHSM apparently not exposing PSS for RSA signatures.
A small program exemplifies this:

import java.security.*;

public class jce
{
	public static void main(String[] args)
	{
		for (Provider provider: Security.getProviders()) {
			System.out.println(provider.getName());
				for (String key: provider.stringPropertyNames())
					System.out.println("\t" + key + "\t" + provider.getProperty(key));
		}
	}
}

gives:

# java -Djava.security.properties=file:///path/to/opendj/config/java.security jce | awk '/PSS/ {print} /^[a-zA-Z]/ {print}'
SUN
SunRsaSign
	Alg.Alias.KeyPairGenerator.OID.1.2.840.113549.1.1.10	RSASSA-PSS
	Alg.Alias.Signature.OID.1.2.840.113549.1.1.10	RSASSA-PSS
	KeyFactory.RSASSA-PSS	sun.security.rsa.RSAKeyFactory$PSS
	Signature.RSASSA-PSS SupportedKeyClasses	java.security.interfaces.RSAPublicKey|java.security.interfaces.RSAPrivateKey
	Alg.Alias.AlgorithmParameters.1.2.840.113549.1.1.10	RSASSA-PSS
	Alg.Alias.KeyFactory.OID.1.2.840.113549.1.1.10	RSASSA-PSS
	Alg.Alias.KeyPairGenerator.1.2.840.113549.1.1.10	RSASSA-PSS
	KeyPairGenerator.RSASSA-PSS	sun.security.rsa.RSAKeyPairGenerator$PSS
	Signature.RSASSA-PSS	sun.security.rsa.RSAPSSSignature
	AlgorithmParameters.RSASSA-PSS	sun.security.rsa.PSSParameters
	Alg.Alias.AlgorithmParameters.OID.1.2.840.113549.1.1.10	RSASSA-PSS
	Alg.Alias.Signature.1.2.840.113549.1.1.10	RSASSA-PSS
	Alg.Alias.KeyFactory.1.2.840.113549.1.1.10	RSASSA-PSS
SunEC
SunJSSE
SunJCE
SunJGSS
SunSASL
XMLDSig
SunPCSC
JdkLDAP
JdkSASL
Apple
SunPKCS11
SunPKCS11-SoftHSM

(the program prints all algorithms for a provider)
While RSA is known:

# java -Djava.security.properties=file:///path/to/opendj/config/java.security jce | awk '/RSA/ {print} /^[a-zA-Z]/ {print}'
...
SunJGSS
SunSASL
XMLDSig
SunPCSC
JdkLDAP
JdkSASL
Apple
SunPKCS11
SunPKCS11-SoftHSM
	Alg.Alias.Signature.OID.1.2.840.113549.1.1.12	SHA384withRSA
	Alg.Alias.Signature.OID.1.2.840.113549.1.1.11	SHA256withRSA
	Alg.Alias.Signature.OID.1.2.840.113549.1.1.14	SHA224withRSA
	Alg.Alias.Signature.OID.1.2.840.113549.1.1.13	SHA512withRSA
	Cipher.RSA/ECB/NoPadding	sun.security.pkcs11.P11RSACipher
	KeyPairGenerator.RSA	sun.security.pkcs11.P11KeyPairGenerator
	Signature.SHA1withRSA	sun.security.pkcs11.P11Signature
	Signature.MD5withRSA	sun.security.pkcs11.P11Signature
	Cipher.RSA/ECB/PKCS1Padding	sun.security.pkcs11.P11RSACipher
	Signature.SHA512withRSA	sun.security.pkcs11.P11Signature
	Signature.SHA384withRSA	sun.security.pkcs11.P11Signature
	Signature.SHA256withRSA	sun.security.pkcs11.P11Signature
	Signature.MD2withRSA	sun.security.pkcs11.P11Signature
	Alg.Alias.Signature.1.2.840.113549.1.1.2	MD2withRSA
	Alg.Alias.Signature.1.2.840.113549.1.1.5	SHA1withRSA
	Alg.Alias.Signature.1.2.840.113549.1.1.4	MD5withRSA
	Signature.SHA224withRSA	sun.security.pkcs11.P11Signature
	Alg.Alias.Cipher.RSA	RSA/ECB/PKCS1Padding
	Alg.Alias.Signature.OID.1.2.840.113549.1.1.2	MD2withRSA
	Alg.Alias.Signature.1.3.14.3.2.29	SHA1withRSA
	KeyFactory.RSA	sun.security.pkcs11.P11RSAKeyFactory
	Alg.Alias.Signature.1.2.840.113549.1.1.11	SHA256withRSA
	Alg.Alias.Signature.1.2.840.113549.1.1.12	SHA384withRSA
	Alg.Alias.Signature.1.2.840.113549.1.1.13	SHA512withRSA
	Alg.Alias.Signature.1.2.840.113549.1.1.14	SHA224withRSA
	Alg.Alias.Signature.OID.1.2.840.113549.1.1.5	SHA1withRSA
	Alg.Alias.Signature.OID.1.2.840.113549.1.1.4	MD5withRSA

JDK 11 implements them as fix for https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8146293, but I have not found a way to tell keytool to generate a certificate without using PSS.
This is linked to TLSv1.3, I think, as using a client using a lower version works. Or for example,

...
# openssl s_client -connect localhost:1638
---
SSL handshake has read 12329 bytes and written 340 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: DDB11AD4FAA8D55105EB400ED118D98A274BE638AFA0169C3DE262EF4F66915F
    Session-ID-ctx:
    Master-Key: 04843517EA06F0B3EDD0A1916F82DFF4E1B6A52C20CADF6ABF3253881C0889A3BD5F3BEB0AC33AE1597BD5E406355C99
    Key-Arg   : None
    Start Time: 1547631689
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
^C

Not too sure what to do here, probably generate the self signed certificate with openssl instead?

Comment by Fabio Pistolesi [ 16/Jan/19 ]

Turns out it is from the handshake, not the certificate in this case.
dumping the handshake, with reference to https://tools.ietf.org/html/rfc8446#section-4.2.3:

              extension type signature_algorithms, length [40] = {
   0: 00 26 04 03  05 03 06 03  08 04 08 05  08 06 08 09  | .&..............
  10: 08 0a 08 0b  04 01 05 01  06 01 04 02  03 03 03 01  | ................
  20: 03 02 02 03  02 01 02 02                            | ........
              }
              extension type signature_algorithms_cert, length [40] = {
   0: 00 26 04 03  05 03 06 03  08 04 08 05  08 06 08 09  | .&..............
  10: 08 0a 08 0b  04 01 05 01  06 01 04 02  03 03 03 01  | ................
  20: 03 02 02 03  02 01 02 02                            | ........
              }

which in both cases is a list of 19 algorithms, 3 ECDSA + 6 RSA-PSS + 3 RSA PKCS1-v1_5 + 7 legacy, obsolete and reserved algorithms (https://tools.ietf.org/html/rfc8446#appendix-B.3.1.3).
signature_algorithms_cert is new in TLSv1.3.

TLS 1.2, on the other hand sends

              extension type signature_algorithms, length [28] = {
   0: 00 1a 06 03  06 01 05 03  05 01 04 03  04 01 04 02  | ................
  10: 03 03 03 01  03 02 02 03  02 01 02 02               | ............
              }

which only contains 13 hash/signature combinations.
TLSv1.3 only uses the extension only for a CertificateVerify message and only uses RSA-PSS.
RSA PKCS-v1_5 "values refer solely to signatures which appear in certificates (see Section 4.4.2.2) and are not defined for use in signed TLS handshake messages, although they MAY appear in "signature_algorithms""

The stack I see where the SoftHSM provider is missing (compared to TLSv1.2) is

chooseProvider:1117, Signature$Delegate (java.security)
engineInitSign:1204, Signature$Delegate (java.security)
initSign:546, Signature (java.security)
getSignature:473, SignatureScheme (sun.security.ssl)
<init>:895, CertificateVerify$T13CertificateVerifyMessage (sun.security.ssl)
onProduceCertificateVerify:1077, CertificateVerify$T13CertificateVerifyProducer (sun.security.ssl)
produce:1070, CertificateVerify$T13CertificateVerifyProducer (sun.security.ssl)
produce:436, SSLHandshake (sun.security.ssl)
goServerHello:1224, ClientHello$T13ClientHelloConsumer (sun.security.ssl)
consume:1160, ClientHello$T13ClientHelloConsumer (sun.security.ssl)
onClientHello:849, ClientHello$ClientHelloConsumer (sun.security.ssl)
consume:810, ClientHello$ClientHelloConsumer (sun.security.ssl)
consume:392, SSLHandshake (sun.security.ssl)
dispatch:444, HandshakeContext (sun.security.ssl)
run:1065, SSLEngineImpl$DelegatedTask$DelegatedAction (sun.security.ssl)
run:1052, SSLEngineImpl$DelegatedTask$DelegatedAction (sun.security.ssl)
doPrivileged:-1, AccessController (java.security)
run:999, SSLEngineImpl$DelegatedTask (sun.security.ssl)
executeDelegatedTask:274, SSLUtils (org.glassfish.grizzly.ssl)
doHandshakeStep:709, SSLBaseFilter (org.glassfish.grizzly.ssl)
doHandshakeStep:332, SSLFilter (org.glassfish.grizzly.ssl)
doHandshakeStep:623, SSLBaseFilter (org.glassfish.grizzly.ssl)
handleRead:335, SSLBaseFilter (org.glassfish.grizzly.ssl)
execute:119, ExecutorResolver$9 (org.glassfish.grizzly.filterchain)
executeFilter:284, DefaultFilterChain (org.glassfish.grizzly.filterchain)
executeChainPart:201, DefaultFilterChain (org.glassfish.grizzly.filterchain)
execute:133, DefaultFilterChain (org.glassfish.grizzly.filterchain)
process:112, DefaultFilterChain (org.glassfish.grizzly.filterchain)
execute:77, ProcessorExecutor (org.glassfish.grizzly)
fireIOEvent:539, TCPNIOTransport (org.glassfish.grizzly.nio.transport)
fireIOEvent:112, AbstractIOStrategy (org.glassfish.grizzly.strategies)
executeIoEvent:103, SameThreadIOStrategy (org.glassfish.grizzly.strategies)
executeIoEvent:89, AbstractIOStrategy (org.glassfish.grizzly.strategies)
iterateKeyEvents:415, SelectorRunner (org.glassfish.grizzly.nio)
iterateKeys:384, SelectorRunner (org.glassfish.grizzly.nio)
doSelect:348, SelectorRunner (org.glassfish.grizzly.nio)
run:279, SelectorRunner (org.glassfish.grizzly.nio)
doWork:593, AbstractThreadPool$Worker (org.glassfish.grizzly.threadpool)
run:573, AbstractThreadPool$Worker (org.glassfish.grizzly.threadpool)
run:834, Thread (java.lang)

That is, it is initing a CertificateVerify message object (for later on, I think) for key SunPKCS11-SoftHSM RSA private key, 2048 bits (id 2, token object, not sensitive, unextractable). But the module is not listed as supporting RSA-PSS, and as the key is in PKCS11 noone else can do it...

Comment by Fabio Pistolesi [ 17/Jan/19 ]

Matthew Swift suggested use of EC, which works with jdk8, but fails miserably with jdk11 regardless of the TLS protocol.

java.lang.ClassCastException: class sun.security.pkcs11.P11Key$P11PrivateKey cannot be cast to class java.security.interfaces.ECPrivateKey (sun.security.pkcs11.P11Key$P11PrivateKey is in module jdk.crypto.cryptoki of loader 'platform'; java.security.interfaces.ECPrivateKey is in module java.base of loader 'bootstrap')
	at java.base/sun.security.ssl.SignatureScheme.getPreferableAlgorithm(SignatureScheme.java:436)
	at java.base/sun.security.ssl.CertificateVerify$T13CertificateVerifyMessage.<init>(CertificateVerify.java:867)
	at java.base/sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.onProduceCertificateVerify(CertificateVerify.java:1077)
	at java.base/sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.produce(CertificateVerify.java:1070)
	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
	at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1224)
	at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1160)
	at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:849)
	at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:810)
Comment by Fabio Pistolesi [ 17/Jan/19 ]

Looking for an alternate software only PKCS11 module, otherwise I suggest to skip test for the time being on jdk11.

Comment by Jean-Noël Rouvignac [ 17/Jan/19 ]

Nice! ClassCastException in the JDK code!

Comment by Matthew Swift [ 17/Jan/19 ]

Wow! Is this a bug in JDK11? Does it mean that it's not possible to use HSM based EC certs with TLSv1.3?

Comment by Fabio Pistolesi [ 18/Jan/19 ]

Just tried with NSS 3.41 (latest version) and got same results as with SoftHSM...

Comment by Fabio Pistolesi [ 18/Jan/19 ]

Vaguely related bug: https://bugs.openjdk.java.net/browse/JDK-8216039

Comment by Fabio Pistolesi [ 21/Jan/19 ]

After asking Neil Madden, he suggested filing JDK bugs for both problems.

We will review your report and have assigned it an internal review ID : 9059049.
We will review your report and have assigned it an internal review ID : 9059050.

Comment by Fabio Pistolesi [ 21/Jan/19 ]

If it is a real limitation/bug in JDK11, it would be good to mention it in the release notes.
"When using a PKCS11 module with jdk11, do not use TLSv1.3 nor EC keys"...

Comment by Chris Ridd [ 21/Jan/19 ]

I suggest we wait for OpenJDK to accept these bug reports (I'm not sure of their processes) and then we can write a cross-product KB article called something like "Combination of TLS1.3 with Java 11 and HSMs Does Not Work"

Comment by Dom Reed [ 21/Jan/19 ]

Will write a KB if/when OpenJDK accept these bugs - IMO, it should also be stated up front in the RN 

Comment by Ludovic Poitou [ 21/Jan/19 ]

I’m not sure RN are the right place. This is not a product issue but a Java issue that impact all ForgeRock products and possibly anyone running Java with HSMs.

Comment by Fabio Pistolesi [ 23/Jan/19 ]

JDK bugs:

https://bugs.openjdk.java.net/browse/JDK-8217610
https://bugs.openjdk.java.net/browse/JDK-8217611

too bad they're P3...

Comment by Matthew Swift [ 23/Jan/19 ]

Thanks for the update Fabio. To summarize, an application using JDK11 and TLS will not work out of the box with a PKCS11 HSM, since TLS1.3 is the default protocol. Do you agree?

Comment by Dom Reed [ 23/Jan/19 ]

There is a KB for this issue now:

TLS 1.3 does not work with Java 11 in HSMs and fails with a SSLHandshakeException or ClassCastException in ForgeRock products

 

Comment by Fabio Pistolesi [ 23/Jan/19 ]

Matthew Swift Yes, that is my understanding.

Comment by Matthew Swift [ 29/Jan/20 ]

Note that JDK8u242 has a fix for https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8080462 which includes, among other things, RSASSA-PSS support.

Generated at Mon Sep 21 16:08:23 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.