When I configure EAP to use openssl based http encryption and try to access it via Chrome 54 or Firefox 49, web request fails as client terminates the connection and tells me ERR_SPDY_INADEQUATE_TARNSPORT_SECURITY or NS_ERROR_NET_INADEQUATE_SECURITY for Firefox respectively. Access via 'curl' works just fine as it is not so strict about used ciphers.

How to reproduce:

1. unzip EAP
2. ./bin/standalone.sh
3. /core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol,value=openssl.TLS)
4. navigate via Chrome or Firefox to https://localhost:8443, add exception for self-signed certificate and see error message from client

I looked into the communication via wireshark (jboss-eap-7.1.0.DR7-openssl.TLS.pcapng) and I can see that client provides bunch of ciphers to server. EAP server chose TLS_RSA_WITH_AES_128_GCM_SHA256 for communication. When I tried with JSSE based encryption, then server chose TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for communication and all worked well, wireshark capture is here - jboss-eap-7.1.0.DR7-TLS.pcapng.

$ openssl ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:PSK-AES256-CBC-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA

I also tried with openssl-1.1.0b (in this case I had to use newer wildfly-openssl from master which is able to work with openssl-1.1.0). When I navigated to the https://localhost:8443, all worked just fine and when I looked into wireshark capture (jboss-eap-7.1.0.DR7-openssl.TLS-openssl-1.1.0b.pcapng), I can see that server chose TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher for communication.

It seems that for openssl-1.0.2j TLS only ciphers are preferred over ECDHE ones?

Also what seems strange to me is why Chrome and Firefox provide server set of ciphers which, if chosen by server, they mark as "inadequate security"? Only thing what comes to my mind is that those ciphers are good enough for HTTP1.1 but not for HTTP2? Thus if server would choose HTTP1.1 for communication it would work... But that does not make sense to me... Maybe I miss something else here?