Error calling an EJB from java client after update from 25 to 37

[T. Wiedenmann]

Hello there,

i try to get my application running after the update from Wildfly 25.0.1 to 37.0.0 for several days now and start loosing hope...

The client application invokes the remote session beans on the server via HTTPS using a self signed certificate configured at the server and which is in the truststore of the client.
This worked perfect with Wildfly 25.0.1Final using the lib wildfly-client-all-25.0.1.Final.jar on the client.

The same setup now for Wildfly 37.0.0Final and wildfly-client-all-37.0.0.Final.jar works for plain HTTP invocation, but when I use SSL there is a  jakarta.ejb.EJBException: java.nio.channels.ClosedChannelException

Using "-Djavax.net.debug=SSL" for the java client, there is an error 
javax.net.ssl|ERROR|E2|XNIO-1 task-1|2025-08-28 13:58:07.980 CEST|TransportContext.java:375|Fatal (CERTIFICATE_UNKNOWN): No subject alternative names present

Really confusing is now: When i run the java client with the same code and to the same server (37.0.0) using wildfly-client-all-25.0.1.Final.jar it works. 
I tested some other versions and up to wildfly-client-all-27.0.1.Final.jar it works, starting from 28.x.x there is the error.

Does anybody know what I need to do to get it working using the current version of the client libs?
I didn't find any hint or info what has changed.

Thanks for your time and help!
Timo

[Bartosz Baranowski]

Do you use IP in URL? If so, did you try regenerating certifcate to include IP in SAN? https://intranetssl.net/faqs/how-to-create-csr-with-san-values-using-openssl  (thats csr, but... )

If not, would it be possible to provide some reproducer?

[T. Wiedenmann]

Thanks for your reply!

Our application is running on different infrastructure (docker containers, customer network, etc.) where the IP can change, we don't know the IP or until now didn't issue a certificate per IP.
So it would be great to find out why it doesn't work anymore or if there is another way to have SSL connections from a java client to a wildfly server.

I checked the commits in the wildfly-http-client that might cause the changed behavior and found this: https://github.com/wildfly/wildfly-http-client/pull/97  

In my current setup, the WF server runs in a docker container locally and has its own hostname - so calling it with "localhost" might lead to the error.

I will try to provide a reproducible demo these days.