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

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

Tagged: 

  • Creator
    Topic
  • #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

Viewing 1 reply thread
  • Author
    Replies
    • #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>

      • #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

      • #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!

    • #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.

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

Forum Statistics

Registered Users
5,117
Forums
28
Topics
9,292
Replies
34,432
Topic Tags
286
Empty Topic Tags
10