0 Replies Latest reply on Jul 12, 2018 4:01 AM by Josef Straub

    Getting XNIO UpgradeFailedException Invalid response code 200 when using remote+https

    Josef Straub Newbie

      Hi guys,


      I try to migrate my deployment running currently on Wildfly 9 to run on Wildfly 13.

      The clients are using for remote EJB and JMS connections the "https-remoting" protocol secured with a self signed certificate and with security realm user .

      The WebServices and Angular SAPs are secured with Oauth2.

      Now, I have upgraded my standalone-full.xml to use the new elytron security on WF 13 and I still have problems getting my remote EJB and JMS calls working.

      The server starts and my ear is deployed and if I use the new protocol "remote+http", I can invoke my EJBs and exchange JMS messages.

      Anyhow, it seems that there is no authentication applied, because on client side the org.wildfly.security category shows me always that the "anonymous" principal is used and not my user, what I have specified.

      I have tried this with and without the wildfly-config.xml and even with a programmmatic approach.

      Also, I have to use an encrypted communication and therefore not the http protocol, so I don't think that this is my solution.


      Now, when I go for the "remote+https", the XNIO throws org.xnio.http.UpgradeFailedException: Invalid response code 200.

      As I checked the code of that, it seems to await 101, 301 and so on, but it gets 200 from Wildfly. I have checked this and Wildlfy returns OK (200) to the HTTPS request.

      The lookup beforehand seems to work, but when the EJB is to be invoked, the above exception occurs.

      After checking a lot of threads, discussions, blogs and tutorials, I found on the internet, I still have the same issue.


      Therefore, I took today the unchanged Wildfly 13 then the Quickstart project from GITHub and tried that out.

      I have concentrated only the "ejb-remote" and "ejb-security" modules to just try them out as described in the docs by using the "cli commands", "Java classes" and "config files" from those.

      Unluckily I have the same outcome: the "remote+http" works but the "remote+https" brings the same exception.

      I have tried to connect with and without a "wildfly-config.xml" and even with the programmmatic approach I found in the "ejb-security-programmatic-auth".


      First I didn't want to upload tones of stack-traces and files, so please ask for what you want to check or know.

      I would really appreciate  if someone could help me !





      UPDATED on 12-July-2018:

      Both Quickstart example (configured for SSL & self signed certificate) and my product deployement (also 2 withSSL & same self signed certificate) works now when I use the next ProviderURL:



      Anyhow, both don't work anymore when I reconfigure WF-13 to use 443 and then I use https://host:443/wildfly-services


      Some details on these:

      when using port 8443:

      on first https call, the server returns 401 (Unauthorized) and in the response header the WWW-Authenticate = Digest realm="ApplicationRealm", ......

      on further https (EJB /jndi/JMS ) invocations the server makes the job and returns 200 (OK)


      when using port 443:

      on first https call, the server returns also 401 and in the response header the WWW-Authenticate = Digest realm="ApplicationRealm", ......  so same behavior, but

      on next https call the server returns 400 (Bad request) and the client side throws naturally the next javax.ejb.EJBException: java.io.IOException: WFHTTP000005: Invalid response code 400 .


      Even the used request URL is same as used for port 8443 (Excepting the port) and the header contains the "authorization" like in the next example:

      Digest username="my_user_configured in_wildfly-config.xml",

      uri="https://localhost:443/wildfly-services/naming/v1/lookup/jms%252FRemoteConnectionFactory", realm="ApplicationRealm", nc=00000001, cnonce="-jA9Qiy3XzWbYNahR3hx1gQTIdUAYWjhydGqfE7o", algorithm=MD5, nonce="AAAAAgADE9gmEHYK9kCAExxMlRYyr8ZYtEt4KL7EGBeA6j1LCGKS0JtEd5Q=", opaque="00000000000000000000000000000000", qop=auth, response="a4e07dbe2e2dad442d7526dd9f887dc5"


      the server shows a different behavior and returns 400 !


      Using ProviderURL=remote+https://host:8443  just doesn't work as with 443 and server returns 200 (OK) as I stated in the title of this discussion.