Clovertech

JAVA/WS-Server – SSL Handshake Logging – Where is it?

› Clovertech Forums › Cloverleaf › JAVA/WS-Server – SSL Handshake Logging – Where is it?

Tagged: 

  • Creator
    Topic
  • February 15, 2022 at 5:20 am #119540
    Erik Mueller
    Participant

      Good morning,

       

      I am fairly new to java/ws-server threads but have configured one to use TLSv1.2.

      I have configured the Keystore File, Keystore Password and Keystore Type (PKCS12).

      I have configured the Truststore File, Trustore Password and the Truststore Type (JKS).

      Client Authentication Required and Client Authentication Wanted are both set to “true”.

      “Message logging Enabled” and Cloverleaf Log Exceptions is set to “true” in the RestProvider configuration.

       

      The Engine Log Configuration is set to “enable_all”.

       

      For testing purposes, I am using PostMan on a different server to post to the URL configured on my Cloverleaf thread and I am able to successfully send a message from Postman to my thread when Postman has the public key and public certificate.

       

      In Postman, if I remove the public key and public certificate, I get an error when trying to post to the URL configured on my Cloverleaf thread, which is expected.

       

      However, I do not see any logging of the SSL handshake in the Cloverleaf process log, when Postman can successfully communicate and I do not see any exceptions when Postman is unable to communicate with the Cloverleaf thread.

       

      Is there any way to log the SSL Handshake, if so, how?

      Or is there a different log file I should be looking at, if yes, which log file?

       

      I am running Cloverleaf v19.1.1.0 on Linux.

       

      Thanks in advance,

      Erik

    • Creator
      Topic
    Viewing 1 reply thread
    • Author
      Replies
      • February 15, 2022 at 9:21 am #119542
        Don Martin
        Participant

          If you add some or all of the following to the Additional JVM Options in the Java Driver tab of the process configuration, you should be able to see SSL handshake logging in your process log file.
          <p style=”margin: 0in; font-family: Calibri; font-size: 11.0pt;”>-Djavax.net.debug=all -Djdk.tls.client.protocols= -Dhttps.protocols=TLSv1.2,TLSv1.1 -Ddeployment.security.SSLv2Hello=false -Ddeployment.security.SSLv3=false -Ddeployment.security.TLSv1=false -Ddeployment.security.TLSv1.1=true -Ddeployment.security.TLSv1.2=true</p>

          • February 15, 2022 at 10:43 am #119543
            Erik Mueller
            Participant

              Hi,

              Thanks very much! That worked and is logging the SSL Handshake 🙂

              Out of curiosity how did you know to use those JVM options? Is it documented anywhere?

              Is there a list of other JVM options available?

              Thanks again,

              Erik

            • February 15, 2022 at 2:20 pm #119546
              Don Martin
              Participant

                For some reason, we seem to inherit these JVM Options in any new {{java protocol process}}.pni file on our cloverleaf site.  I’m not sure how that happened… maybe someone set it up in the Cloverleaf configuration before I got here.  I’m also not aware of any list of JVM Options to use in the process configuration, but maybe others on this forum will have some input.

                Glad this worked for you!

            • August 29, 2024 at 11:36 pm #121584
              Chris
              Participant

                Thanks Don. Arg -Djavax.net.debug=all, in particular, was sufficient for what I needed.

                P.S. — completely unrelated to the ws-server protocol but typing this out anyway — while working with the ws-client protocol, I encountered a “Certificate chaining error” erro,r indicating that the complete certificate chain was not present in my server’s truststore. In my case, comparing openssl outputs to the SSL debug output made it clear that I was missing a particular root CA cert (issuer of the cert presented by the target API). To avoid modifying this server’s truststore, I created a site-specific truststore and imported the full chain (including missing cert) via the keytool utility. However, even after updating the Conduit’s TLSv1.2 config to reference this new truststore, the error persisted.

                I eventually discovered that initializing the new truststore directly in the JVM (using the args below), instead of from the Conduit’s config, causes the truststore to be ‘applied’ as intended. Note, in addition to clearing out the Conduit’s TLS config, it is essential to disable the ‘Use TLS’ checkbox.

                -Djavax.net.debug=all
                -Dhttps.protocols=TLSv1.2,TLSv1.1
                -Ddeployment.security.TLSv1.2=true
                -Djavax.net.ssl.trustStore=/path/to/store.jks
                -Djavax.net.ssl.trustStorePassword=XXX

                On a broader note, it is disappointing to find how poorly documented the CAA-WS add-on is after all this time. I recognize that there are example sites in CL installs, and I could be missing formal docs, but AFAIK there is not even even basic info regarding (for ex.) basic ws-client TLS config.

            • Author
              Replies
            Viewing 1 reply thread
            • You must be logged in to reply to this topic.