Snaplex nodes running with customer signed SSL certificate - default SnapLogic SSL certificate selected and returned by server during SSL handshake

[PSAmmirata]

We have configured our Snaplex nodes to run with a customer signed SSL certificate. We use the FQDN in the certificate. The default SnapLogic SSL certificate is not in the JCC’s keystore (jcc.serverkeys.jks). However, when we test the server (Snaplex node) is returning the default SnapLogic SSL certificate to the client during the SSL handshake instead of returning the customer signed SSL certificate. We did some additional investigation and it appears that if the client has the Server Name Indicator (SNI) TLS extension enabled the server selects and returns the default SnapLogic SSL certificate. However, if the SNI TLS extension is disabled the server selects and returns the customer signed SSL certificate that’s in the JCC’s keystore. We tested the following:

“openssl s_client -connect node.example.com:8081” does not use the SNI TLS extension (i.e. server name is not in the client hello message) and the server selects and returns the company signed SSL certificate chain.

“openssl s_client -connect node.example.com:8081 -servername node.example.com” uses the SNI TLS extension (i.e. server name is in the client hello message) and the server selects and returns the default SnapLogic certificate.

“./java -Djavax.net.debug=ssl SSLPoke node.example.com 8081” uses the SNI TLS extension (i.e. server name is in the client hello message) and the server selects and returns the default SnapLogic certificate.

“./java -Djavax.net.debug=ssl -Djsse.enableSNIExtension=false SSLPoke node.example.com 8081” does not use the SNI TLS extension (i.e. server name is not in the client hello message) and the server selects and returns the company signed SSL certificate chain.

We also tested via browser and curl - they use the SNI TLS extension by default (i.e. server name is in the client hello message) and the server selects and returns the default SnapLogic certificate. I didn’t find a way to disable the extention when using a browser or curl (we’re using version 7.27.0 of curl)

Has anyone else encounter this behavior and been able to resolve it?

[christwr]

Ahh… I’m working on the HTTPS port (8081) for regular triggered task API, not feedmaster API port. Looks like different areas this stuff would be configured.

[PSAmmirata]

I apologize @christwr. I didn’t mean to create confusion. When I created this post I was working on triggered tasks, and when I resumed work on it recently I was working on ultra pipeline tasks. I didn’t realize I had changed trains of thought. Regardless, we didn’t need to reconfigure the ciphers in either case. I haven’t tested triggered tasks, but since ultra pipeline tasks are working I’m making a leap of faith and assume that the triggered tasks will work now as well.