Re: Error connecting to a java process with TLSv1.3

--===============1502563308616911405==
Content-Type: multipart/alternative; boundary="000000000000358128064b27a28c"

--000000000000358128064b27a28c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 19, 2026 at 1:08=E2=80=AFAM Daniel Santos via curl-users <
[email protected]> wrote:

> Hi,
>
> I have a Jetty Java application server configured with SSL/TLS in which
> one of the versions it does is TLS v1.3.
> It runs on Java 17 graalvm-ce-17.
>
> This is the output of the version command on the curl I am using (MacOS X
> Tahoe, home-brew version)
>
> dlsa@besta facialrecognition % /opt/homebrew/opt/curl/bin/curl -V
> curl 8.18.0 (aarch64-apple-darwin25.2.0) libcurl/8.18.0 OpenSSL/3.6.1
> zlib/1.2.12 brotli/1.2.0 zstd/1.5.7 AppleIDN libssh2/1.11.1 nghttp2/1.68.=
0
> ngtcp2/1.20.0 nghttp3/1.15.0 mit-krb5/1.7-prerelease OpenLDAP/2.4.28/Appl=
e
> Release-Date: 2026-01-07
> 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 AppleSecTrust AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3
> HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM SPNEGO SSL threadsafe
> TLS-SRP UnixSockets zstd
>
> The command I run is :
>
> dlsa@besta facialrecognition % /opt/homebrew/opt/curl/bin/curl
> --trace-ascii httpreq.log --tlsv1.3 --cacert
> jettyhttpscerts/jettyhttpscertbundle.pem '
> https://localhost:9433/auth/authorize'
> curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof
> while reading
>
> The contents of the call=E2=80=99s log file is attached.
>
> In the log file there is the last bit that is sent before the disconnect =
:
>
> =3D> Send SSL data, 5 bytes (0x5)
> 0000: .....
> * TLSv1.3 (OUT), TLS alert, decode error (562):
>
> Which I suspected that, because the java server has a certificate signed
> through a CA certificate that I generated,
> Curl needs the option --cacert jettyhttpscerts/jettyhttpscertbundle.pem t=
o
> tell it to use the certificate in the trust chain
> That is coming from the server.
>
> If not it will throw the decode error. That was what was happening also
> before I put the =E2=80=94caret option.
> But with the option I get the same error.
> So I am not sure if its related to the server certificate being generated
> by me.
>
> Could anyone shed some light into this ?


It sounds like (to me) the server at localhost:9433 is _not_ serving pages
over TLS.  The TLS handshake is not occuring, and ASCII data from http is
being served.  Can you connect to localhost:9433 using https with a browser=
?

Jeff

--000000000000358128064b27a28c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 19,=
 2026 at 1:08=E2=80=AFAM Daniel Santos via curl-users &lt;<a href=3D"mailto=
:[email protected]">[email protected]</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I have a Jetty Java application server configured with SSL/TLS in which one=
 of the versions it does is TLS v1.3.<br>
It runs on Java 17 graalvm-ce-17.<br>
<br>
This is the output of the version command on the curl I am using (MacOS X T=
ahoe, home-brew version)<br>
<br>
dlsa@besta facialrecognition % /opt/homebrew/opt/curl/bin/curl -V<br>
curl 8.18.0 (aarch64-apple-darwin25.2.0) libcurl/8.18.0 OpenSSL/3.6.1 zlib/=
1.2.12 brotli/1.2.0 zstd/1.5.7 AppleIDN libssh2/1.11.1 nghttp2/1.68.0 ngtcp=
2/1.20.0 nghttp3/1.15.0 mit-krb5/1.7-prerelease OpenLDAP/2.4.28/Apple<br>
Release-Date: 2026-01-07<br>
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipn=
s ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp =
ws wss<br>
Features: alt-svc AppleSecTrust AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3 H=
TTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM SPNEGO SSL threadsafe TLS-=
SRP UnixSockets zstd<br>
<br>
The command I run is : <br>
<br>
dlsa@besta facialrecognition % /opt/homebrew/opt/curl/bin/curl --trace-asci=
i httpreq.log --tlsv1.3 --cacert jettyhttpscerts/jettyhttpscertbundle.pem &=
#39;<a href=3D"https://localhost:9433/auth/authorize" rel=3D"noreferrer" ta=
rget=3D"_blank">https://localhost:9433/auth/authorize</a>&#39;<br>
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof w=
hile reading<br>
<br>
The contents of the call=E2=80=99s log file is attached.<br>
<br>
In the log file there is the last bit that is sent before the disconnect :<=
br>
<br>
=3D&gt; Send SSL data, 5 bytes (0x5)<br>
0000: .....<br>
* TLSv1.3 (OUT), TLS alert, decode error (562):<br>
<br>
Which I suspected that, because the java server has a certificate signed th=
rough a CA certificate that I generated,<br>
Curl needs the option --cacert jettyhttpscerts/jettyhttpscertbundle.pem to =
tell it to use the certificate in the trust chain<br>
That is coming from the server.<br>
<br>
If not it will throw the decode error. That was what was happening also bef=
ore I put the =E2=80=94caret option.<br>
But with the option I get the same error.<br>
So I am not sure if its related to the server certificate being generated b=
y me.<br>
<br>
Could anyone shed some light into this ?</blockquote><div><br></div><div>It=
 sounds like (to me) the server at localhost:9433 is _not_ serving pages ov=
er TLS.=C2=A0 The TLS=C2=A0handshake is not occuring, and ASCII data from h=
ttp is being served.=C2=A0 Can you connect to localhost:9433 using https wi=
th a browser?</div><div><br></div><div>Jeff</div></div></div>

--000000000000358128064b27a28c--

--===============1502563308616911405==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette:   https://curl.se/mail/etiquette.html

--===============1502563308616911405==--