Re: [jetty-users] Jetty 9.4.44, Java 11 and own Keystore in SslContextFa

[Lothar Kimmeringer <job@xxxxxxxxxxxxxx>]

Am 28.02.2022 um 19:22 schrieb Brian Reichert:
> On Mon, Feb 28, 2022 at 05:01:23PM +0100, Lothar Kimmeringer wrote:
>
> > I've got a HSM with a certificate and private key that I pass as
> > a KeyStore to an SslContextFactory:
>
> I'm arm-waving here; Java 11's security engine might be constraining
> cipher suites differently than Java 8, and your server may feel that
> there are no compatible matches to the ClientHello.

Hm, I have doubts. In addition to a connector using a ssl context
factory with a KeyStore set by setKeyStore, I've got another
one that uses my own implementation of a context factory that
reads certificates from a database. That connector just works
fine independent from the Java version in use.

The certificate can be loaded successfully

2022-02-28 16:27:32 INFO: x509=X509@35e3f3b8(testhsmcert,h=[localhost, laptop-61ekf6f2],w=[]) for SslContextFactory@13bf5fd(null,null)
2022-02-28 16:27:33 INFO: Started ServerConnector@1dc2c13c{SSL,[ssl, http/1.1]}{0.0.0.0:14433}

and is used in the Certificate-packet after the ServerHello

> Maybe re-testing Jetty with appropriate -Djavax.net.debug flags will
> better inform you.

I thought that Jetty uses its own TLS implementation and that the system
property has no effect (which is why I've defined the jetty debug log
property -Dorg.eclipse.jetty.util.log.DEBUG=true.

When using Java 8 the browser creates a TLS-connection using
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. That's a recent enough
cipher that I would expect this to be available in Java 11 as well.

But your suggestion with -Djavax.net.debug helped, I'm not sure what
to make out of it:

javax.net.ssl|DEBUG|B3|qtp1592099291-179|2022-02-28 19:45:22.062 CET|ServerHello.java:364|Produced ServerHello handshake message (
"ServerHello": {
  "server version"      : "TLSv1.2",
[...]
  "cipher suite"        : "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030)",

Same cipher, so what I expected, but then there is an exception:

  java.security.InvalidKeyException: Supplied key is not a RSAPrivateKey instance
        at org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi.engineInitSign(PSSSignatureSpi.java:137)
        at org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi.engineInitSign(PSSSignatureSpi.java:128)
        at java.base/java.security.SignatureSpi.engineInitSign(SignatureSpi.java:162)
        at java.base/java.security.Signature$Delegate.tryOperation(Signature.java:1314)
        at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1257)
        at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1382)
        at java.base/java.security.Signature.initSign(Signature.java:684)
        at java.base/java.security.Signature$1.initSign(Signature.java:146)
        at java.base/sun.security.util.SignatureUtil.initSignWithParam(SignatureUtil.java:169)
        at java.base/sun.security.ssl.SignatureScheme.getSignature(SignatureScheme.java:478)
        at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.<init>(ECDHServerKeyExchange.java:155)
        at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeProducer.produce(ECDHServerKeyExchange.java:499)
        at java.base/sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(ClientHello.java:1102)
        at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:854)
        at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
        at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
        at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1048)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:995)
        at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:654)
        at org.eclipse.jetty.server.HttpConnection.fillRequestBuffer(HttpConnection.java:350)
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
        at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:555)
        at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:410)
        at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:164)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
        at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
        at java.base/java.lang.Thread.run(Thread.java:834)}

Not sure where this exception get's "lost", personally I think that something like
that should be logged into the server log. Also, I don't know how I can "fix" that
as it seems to be out of my control. I'll check what private keys are returned with
Java 8 and Java 11. BC Version being used here is 1.65 BTW.


Thanks and cheers, Lothar