1

[UPDATE]
I ran the openssl command from a couple servers and my local machine. It seems like port 9443 is not remaining consistent. The cipher on server1:9443 remained the same from the first server (RHEL5) I queried from. However, querying from my local machine (Win7) and a VM (RHEL6.9) result in a 0000 cipher.

I don't think the outage is related to my port cipher difference, because additional tests are showing the application is back online using similar environment settings as the end user. I was reading an article that the F5 balancer could potentially cause issues. So I'll investigate that route with the admins.

But I'd still like to know why the ports are reflecting different ciphers and how to correct it. [/UPDATE]

I have two servers, both have two instances of application servers on them. Each application server instance is configured to use the same SSL protocols and cipher.

From the configs:

sslProtocols = "TLSv1,TLSv1.1,TLSv1.2"
ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
    TLS_RSA_WITH_AES_128_CBC_SHA256,
    TLS_RSA_WITH_AES_128_CBC_SHA,
    TLS_RSA_WITH_AES_256_CBC_SHA256,
    TLS_RSA_WITH_AES_256_CBC_SHA"

Clients reported an outage in certain cases for Server1:9443

I ran from the commandline: openssl s_client -connect server:port

Server1:8443

Protocol  : TLSv1
Cipher    : AES128-SHA

Server1:9443

Protocol  : TLSv1
Cipher    : DHE-RSA-AES256-SHA

Server2:8443

Protocol  : TLSv1
Cipher    : AES128-SHA

Server2:9443

Protocol  : TLSv1
Cipher    : AES128-SHA

Why would server1:9443 reflect differently?

Both servers are on RHEL 5.11.

[EDIT]
From the commandline netstat -tupln

Server1:

tcp        0      0 0.0.0.0:9443                0.0.0.0:*                   LISTEN      9709/java

Server2:

tcp        0      0 0.0.0.0:9443                0.0.0.0:*                   LISTEN      718/java
tcp        0      0 0.0.0.0:8443                0.0.0.0:*                   LISTEN      5900/java    

Server1 /etc/services lists 8443 as pcsync-https. Verified by running the command sudo netstat -t -l -p |grep pcsync-https on server1.

tcp        0      0 *:pcsync-https                *:*                   LISTEN      7037/java

[/EDIT]

  • Are they definitely all the same instance of the ssh server? You could try netstat -tupln and check PIDs to confirm – ishigoya Nov 7 '17 at 19:47
  • I ran netstat and posted the results. – Ian Nov 7 '17 at 20:47
  • 1
    You don't mention the application server, but if you run it from Apache you may run into the issue that additional configuration settings are included with the Include and IncludeOptional directives and/or .htaccess files. Also it is an allowed syntax to have a SSLProtocol directive for each VirtualHost, but unless you have IP VirtualHosts in practice the settings from the first occurrence of the SSLProtocol directive are used for the whole server or all name-based VirtualHosts : serverfault.com/q/637344/37681 – HBruijn Nov 7 '17 at 20:47
  • it's running JBoss GA and EAP. Neither instances are using a virtual host – Ian Nov 7 '17 at 20:50
  • Have you tried to made openssl s_connect from affected server, to ensure that there is no issue with balancer? – Alexander Tolkachev Nov 16 '17 at 6:30
0

So it wasn't the cipher, but the redirect port... one the clients weren't using and was shutoff on one server, but not the other.

 <Connector port="8080" address="${jboss.bind.address}"
     maxThreads="250" maxHttpHeaderSize="8192"
     emptySessionPath="true" protocol="HTTP/1.1"
     enableLookups="false" redirectPort="8443" acceptCount="100"
     connectionTimeout="20000" disableUploadTimeout="true" />

Once we commented out this block from the JBoss server.xml file and restarted the service, things started working as intended. Each port on both servers are now reflecting the same, server-client cipher.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.