120

Using JVM flag

-Djavax.net.debug=ssl

is producing a tremendous ammount of logging, the details for every SSL event on the server. Is there anyway to only have it log errors? or possibly there is some better subset of these flags that produce tidier output

all            turn on all debugging
ssl            turn on ssl debugging

The following can be used with ssl:

    record       enable per-record tracing
    handshake    print each handshake message
    keygen       print key generation data
    session      print session activity
    defaultctx   print default SSL initialization
    sslctx       print SSLContext tracing
    sessioncache print session cache tracing
    keymanager   print key manager tracing
    trustmanager print trust manager tracing
    pluggability print pluggability tracing

    handshake debugging can be widened with:
    data         hex dump of each handshake message
    verbose      verbose handshake message printing

    record debugging can be widened with:
    plaintext    hex dump of record plaintext
    packet       print raw SSL/TLS packets

Further reading

StackzOfZtuff
  • 2,534
  • 1
  • 28
  • 25
Steve Renyolds
  • 1,341
  • 2
  • 9
  • 10
  • 3
    I believe you get the errors for free by way of exceptions. No specials actions are necessary. – jww May 14 '14 at 22:43
  • This is specifically used for debugging. Hence the vast amount of logs. – barbiepylon Mar 19 '15 at 14:12
  • 1
    Setting it to `""` seems to show only a few warnings. – NateS Jan 24 '20 at 11:59
  • Might be related: [JDK-8044609 javax.net.debug "ssl" options are not working and documented as expected.](https://bugs.openjdk.java.net/browse/JDK-8044609) -- This ticket has been OPEN since 2014. – StackzOfZtuff Jan 24 '22 at 13:34

2 Answers2

111

The format for using the additional ssl flags is ssl:[flag] for example:

-Djavax.net.debug=ssl:record or -Djavax.net.debug=ssl:handshake.

Shashank Agrawal
  • 25,161
  • 11
  • 89
  • 121
Alan MacK
  • 1,366
  • 1
  • 9
  • 8
  • 4
    this is a highly-upvoted answer, but does it really work for people? It doesn't seem to be for me. There is also a [bug entry](https://bugs.openjdk.java.net/browse/JDK-8044609) that these options wouldn't actually work. – eis May 08 '17 at 09:19
  • 1
    @eis yes, it worked for me. Maybe you are not setting it properly and, if so, you should definitively ask a new question so we can help you out :) – Alfabravo Jul 26 '18 at 23:15
  • @Alfabravo so you're saying the bug entry is invalid and these work as expected? – eis Jul 27 '18 at 08:19
  • 1
    Well, it's from 2014, jdk7 and openjdk. Also, someone commented [here](https://bugs.openjdk.java.net/browse/JDK-7013776) that debug logging was improved, so there's that – Alfabravo Jul 27 '18 at 13:11
24

I also find that using -Djavax.net.debug=ssl (or even its filters) to be too cumbersome for debugging HTTPS issues.

It's a little bit involved, but what I prefer to do is setup mitmproxy on a cheap server somewhere and then configure my Java clients to proxy through it. This way I can comfortably inspect and replay HTTPS request/response flows on the proxy without having to comb through a bunch of logs.

If you are you interested, I've written a guide on how to get this going: Debugging SSL in Java using mitmproxy

capotej
  • 2,861
  • 3
  • 21
  • 16
  • 2
    I think your approach is useful for debugging traffic that's happening inside a TLS session and having every detail on it, being able to modify it, but it makes a lot less sense when investigating an issue happening at the level of the TLS session itself. You proxy will change and hide what is initially happening at that level. – jmd Jan 23 '20 at 12:37