Application EJB calls hang using SSL

[Michael Pritt]

I'm having trouble moving from remote+http to remote+https.  I'm using a basic java application and the default applicationSSC that comes with the wildfly installation.  I'm using wildfly 26.  I'm using the SecuredEJB.java from the wildfly security examples but made it open (unsecured).  

Note that my application works using the remote+http protocol (using the same user in my InitialContext).  I'm using the org.wildfly.naming.client.WildFlyInitialContextFactory in my application for the initial context factory.  

So, here is what I've done to use the remote+https protocol...I've first created the http-connector under the jboss:domain:remoting section:  

            <http-connector name="https-remoting-connector" connector-ref="https" sasl-authentication-factory="application-sasl-authentication"/>

I don't have to create a new security context because I'm using the default one that came with wildfly (i.e. applicationSSC), so that part for SSL should still work.  

I start my java application and allow it to trust the default keystore (application.keystore) using the VM arguments:  
-Djavax.net.ssl.keyStore=${CLIENT_CERT} -Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.trustStore=${CLIENT_CERT} -Djavax.net.ssl.trustStorePassword=password

Connection is made, the principal recognized, certificates verified, but the EJB call that is made, it never returns unless I terminate the server.  It just hangs on that EJB call.  Once I stop the server control is returned to my application.

Is there something missing in my configuration or some additional setup I need in the InitialContext?  All I'm doing in setting up the context is the following:
      jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
      jndiProperties.put(Context.PROVIDER_URL, "remote+https://localhost:8443");

jndiProperties.put(Context.SECURITY_PRINCIPAL, "USERNAME");

jndiProperties.put(Context.SECURITY_CREDENTIALS, "password");

Also is there some additional trace that I can turn on to see what more is happening on the server and why it is hanging?  

I'm providing both my standalone xml file and the logging output using the TRACE statements I've enabled.  

[Michael Pritt]

Here is the full trace output (the other trace output had a different username/password than I had detailed earlier).

[Michael Pritt]

Here is the code to do the EJB lookup and method call (it hangs on the reference.getSecurityInfo() method call):

            Hashtable<String, String> env = new Hashtable<>();
            env.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
            env.put(Context.PROVIDER_URL, "remote+https://localhost:8443");
            env.put(Context.SECURITY_PRINCIPAL, "USERNAME");
            env.put(Context.SECURITY_CREDENTIALS, "password");
            Context ctx = new InitialContext(env);
            SecuredEJBRemote reference = (SecuredEJBRemote) ctx.lookup(className);
            System.out.println("\n\n\n* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *\n\n");
            String info = reference.getSecurityInfo();
            System.out.println("Successfully called secured bean, caller principal " + info);

Please, any help trying to figure this out would be a great help!

[Farah Juma]

Are you trying to use one-way or two-way SSL?

Looks like the client is presenting its certificate but I don't see any corresponding trust-manager configuration on the server side.

There are some SSL related exceptions in your log file, not sure if that was from a previous call or this one.

When the server is hanging, are you able to get a thread dump?

[Michael Pritt]

I've tried both one-way and two-way SSL.  Right now I'm only having the client present it's certificate.  

Yes there are some exceptions earlier in the full log file that I provided - those were management logging exceptions - I've ignored those because they were not dealing with the application and occurred when starting up the server (i.e. before I even launched the client application).

So when I mean the server is hanging, it seems that the task to actually invoke the session bean is not being handed off to the thread.  The reason I say this is because when using the "remote+http" protocol the  EJBServerChannel's handleMessage function is called.  However that line of code is never hit when I changed back to using SSL ('remote+https').  So the client is waiting for the response to the request, but the server is never passing on handling the request to a thread after the authentication/authorization occurs therefore the client is hung waiting.   So I have no good thread dump to give you (I've double checked all the threads by suspending the server to see if there was something out of the ordinary but all threads were in like a 'wait for work' kind of state).

[Michael Pritt]

I ended up entering a jira ticket ELY-2309 and Ricardo was able to point out that I didn't add the https-remoting-connector to the ejb3 as well.  That solves the issue with the hanging and my application works with the keystores specified on the command-line.  

[Cameron Rodriguez]

Hey Michael,

I wanted to share this blog post I wrote about implementing two-way SSL, hopefully it will be helpful with any other issues you might be running into. Let me know if you have any questions.