"javax.net.ssl.SSLHandshakeException: (handshake_failure) No available authentication scheme" without an explanation

[cowwoc]

Jetty Version
12.0.16

Jetty Environment
core

Java Version

openjdk 23.0.2 2025-01-21 LTS
OpenJDK Runtime Environment (build 23.0.2+9-LTS)
OpenJDK 64-Bit Server VM (build 23.0.2+9-LTS, mixed mode)

Question
I am attempting to deploy a server into a Kubernetes cluster. When I invoke wget https://web-server.licensed.svc.cluster.local:443 I get:

--2025-02-17 19:19:16--  https://web-server.licensed.svc.cluster.local/
Resolving web-server.licensed.svc.cluster.local (web-server.licensed.svc.cluster.local)... 10.43.211.64
Connecting to web-server.licensed.svc.cluster.local (web-server.licensed.svc.cluster.local)|10.43.211.64|:443... connected.
OpenSSL: error:0A000126:SSL routines::unexpected eof while reading
Unable to establish SSL connection.

On the server-side, I get this attached log file with DEBUG-level logging enabled org.eclipse.jetty:
server.log

The point I am trying to make is that there is no obvious warning or error logged by Jetty before I end up with:

javax.net.ssl.SSLHandshakeException: (handshake_failure) No available authentication scheme
    at java.base/sun.security.ssl.Alert.createSSLException(Unknown Source)

I will eventually figure out what is wrong, but shouldn't Jetty provide some sort of hint of a misconfiguration or keystore problem in this case? For the record, I am feeding Jetty a test certificate generated by LetsEncrypt. I fully expect the client to reject it, but I am not expecting the server to reject it (at least, not without an error indicating as such).

[joakime]

Sounds like your wget doesn't support the same set of TLS features as the server.
Also, what are your SNI settings in that Jetty server?

[cowwoc]

I am using:

GNU Wget 1.21.4 built on mingw32.

+cares +digest +gpgme +https +ipv6 +iri +large-file +metalink -nls
+ntlm +opie +psl +ssl/openssl

For the record, using:

curl 8.12.1 (x86_64-w64-mingw32) libcurl/8.12.1 LibreSSL/4.0.0 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 WinIDN libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.64.0 ngtcp2/1.10.0 nghttp3/1.7.0
Release-Date: 2025-02-13
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli CAcert HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL SSLS-EXPORT SSPI threadsafe UnixSockets zstd

I get:

curl https://web-server.licensed.svc.cluster.local:443
curl: (35) TLS connect error: error:00000000:lib(0):func(0):reason(0)

Regarding SNI, the code invokes SslContextFactory.Server.setSniRequired(true) and SecureRequestCustomizer(sniRequired=true, sniHostCheck=true, stsMaxAgeSeconds=-1, stsIncludeSubdomains=true).

You are right that the SNI does not match. The certificate domain is for licensed.app which doesn't match the request URL of web-server.licensed.svc.cluster.local but notice that the Jetty logs don't even mention SNI. I don't think we're reaching that validation...

[cowwoc]

Disabling SNI required in SslContextFactory.Server and SecureRequestCustomizer did not help. Given that I am using the latest version of wget, I assume that it is unlikely that it does not support the same TLS features as the server. I am investigating further...