[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Jetty 9.4.44, Java 11 and own Keystore in SslContextFactory$Server lead to SSL_ERROR_INTERNAL_ERROR_ALERT
|
Hi,
On Mon, Feb 28, 2022 at 7:54 PM Lothar Kimmeringer <job@xxxxxxxxxxxxxx> wrote:
> 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.
Jetty uses the JDK implementation, so the system property is effective.
> 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.
Not sure what to tell you either. This is out of Jetty's control too,
probably some strange interaction between JDK's TLS implementation and
BC.
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
