Forum Discussion

PSAmmirata's avatar
PSAmmirata
Employee
8 years ago

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

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?

General Information

11 Replies

  • christwr's avatar
    christwr
    Contributor III
    8 years ago

    @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.

  • PSAmmirata's avatar
    PSAmmirata
    Employee
    8 years ago

    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's avatar
    christwr
    Contributor III
    8 years ago

    Hi Paul - Did you ever find a solution for this? I’ve been looking into switching out the default self-signed certificates on our groundplex nodes with our own CA-signed certificate, so was curious about this topic.

    • PSAmmirata's avatar
      PSAmmirata
      Employee
      8 years ago

      Hi Chris - The short answer is “no”. I have an open ticket with SnapLogic and our TAM told me that there is a SnapLogic bug, but I don’t know anymore than that at this time. I’ll update this post when I find out more.

  • christwr's avatar
    christwr
    Contributor III
    8 years ago

    Hi Paul - Did you ever get this resolved? If so, any good lessons learned?

  • christwr's avatar
    christwr
    Contributor III
    8 years ago

    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's avatar
      PSAmmirata
      Employee
      8 years ago

      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's avatar
    christwr
    Contributor III
    8 years ago

    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's avatar
      PSAmmirata
      Employee
      8 years ago

      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.