9

A google reveals a bug in jdk11.0.2 but I upgraded to jdk11.0.3 and this still exists for me. Steps to reproduce

  1. git clone https://github.com/deanhiller/webpieces.git
  2. add the line "org.gradle.java.home=/Library/Java/JavaVirtualMachines/jdk-11.0.3.jdk/Contents/Home" to ~/.gradle/gradle.properties to set jdk to 11.0.3
  3. run ./gradlew :core:core-asyncserver:test from webpieces directory

The test case hangs and in the logs, it shows

Caused by: javax.net.ssl.SSLHandshakeException: No available authentication scheme
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255)
    at java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:945)
    at java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:934)
    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)
    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.webpieces.ssl.impl.AsyncSSLEngine2Impl.createRunnable(AsyncSSLEngine2Impl.java:94)
    ... 12 common frames omitted

Should I file another JDK bug, or does anyone have any thought?

JDK bug that is resolved/related: https://bugs.openjdk.java.net/browse/JDK-8211426

Note that this fixes it for some reason: System.setProperty("jdk.tls.server.protocols", "TLSv1.2");

hmmm, anyone know how to generate a self-signed certificate that works for TLSv1.2 and TLSv1.3?

Sébastien Le Callonnec
  • 26,254
  • 8
  • 67
  • 80
Dean Hiller
  • 19,235
  • 25
  • 129
  • 212
  • 3
    The bug you linked as related has resolution "Won't Fix" so it's not fixed. There is a [comment](https://bugs.openjdk.java.net/browse/JDK-8211426?focusedCommentId=14218233&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14218233) showing how to work around the issue by not using TLS 1.3 but "downgrading" to TLS 1.2. Check if that solves your problem – Misantorp Apr 25 '19 at 17:47
  • yeah, I guess I have to figure out how to upgrade the certs to TLS 1.3 BUT so they still work in TLS 1.2 with jdk 8, 9, 10, etc. hopefully the new cert works in all 5 versions jdk 8 to jdk 12. – Dean Hiller Apr 25 '19 at 18:17
  • 1
    *"...generate a self-signed certificate that works for TLSv1.2 and TLSv1.3..."* - certificates are mostly independent of the TLS protocol version. Except that DSA certificates will not work with TLS 1.3 - but who is using DSA anyway today. Please use an ECC key or RSA key inside the certificate. So the question is more how you've created this self-signed certificate in the first place and how does it look like. – Steffen Ullrich Apr 25 '19 at 19:30

1 Answers1

8

Assuming it is the issue that is linked and not another issue around TLS 1.3.

Your certificate is using the DSA algorithm, which has been deprecated a while ago in favor of RSA and is not supported at all in TLS1.3. Make sure to create RSA certificates instead.

It seems that not-so-old versions of the java keytool might have created DSA certificates by default... an unfortunate default. You can use this command to verify a certificate type.

openssl x509 -in certificate.crt -text

Certificate:
    ...
    Signature Algorithm: dsa_with_SHA256
        ...
        Subject Public Key Info:
            Public Key Algorithm: dsaEncryption
user5994461
  • 5,301
  • 1
  • 36
  • 57
  • When using Java, `keytool -printcert -file $file` or `keytool -list -keystore $ksfile [-alias $name] -v` also displays this information. (And the former works on both PEM and DER files without change, while `openssl` needs `-inform der` or abbreviated `-inform d`).) – dave_thompson_085 Nov 02 '20 at 18:32
  • 1
    SHA-1 signature algorithms are also not available in TLSv1.3 in Java. Explained in https://tools.ietf.org/html/rfc8446#section-4.4.2.4 "SHA-1 is deprecated, and it is RECOMMENDED that any endpoint receiving any certificate which it would need to validate using any signature algorithm using a SHA-1 hash abort the handshake with a "bad_certificate" alert." – Lari Hotari Nov 17 '20 at 05:09
  • Downgrading to TLSv1.2 also does not help in my case, it shows empty client certificate list although the certificate is present in KeyStore. Any help? – Pankaj Goyal Mar 09 '22 at 22:15