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?

[PSAmmirata]

We had encountered this issue in release 4.13. A patch (4.13 patch 2 (master-3379)) was released in mid June. I never got a chance to test it and had to drop this topic due to other priorities. Just coming back to it now and when we test with release 4.14 the issue is resolved (presumably because the patch was rolled into 4.14.)

[christwr]

Cool, thanks for the update Paul!

Did you guys also reconfigure the ciphers? I had a case open with SL a while back about it, with a response to tweak the jcc.ssl.excluded_ciphers property, but personally hadn’t messed with it yet.

[PSAmmirata]

We didn’t need to use the jcc.ssl.excluded_ciphers property. By default the FeedMaster uses port 8089 for the message broker. This conflicted with Splunk so we needed to change the port number for the message broker. This is documented in the Snaplex configuration options documentation.

jcc.broker_service_uri = ssl: //0.0.0.0:8089?transport.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2&transport.enabledCipherSuites=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA

[christwr]

@dmiller - I think it would be super useful if there was a guide from SnapLogic on how to configure the certificates, protocols, and ciphers for the HTTPS API URL on groundplex nodes.

[dmiller]

@christwr, I submitted a ticket to the doc team.