NATS uses cookies to ensure you get the best experience on our website. Continuing to use this site assumes compliance with our Privacy Policy.

Using OCSP Stapling with the NATS Java Library

Scott Fauerbach — July 6, 2021

You already know that the NATS Java library can connect to the NATS Server with TLS. The NATS Server now supports OCSP Stapling. To that end, I have built an example on how to set up the SSLContext to use with the NATS Java Library. Mileage may vary, and you will need to incorporate your own certificates and key stores, but this OCSP Example will get you most of the way there.

OCSP Stapling SSLContext

OCSP Stapling has been supported in Java since JDK 8. This excellent document from Oracle, Client-Driven OCSP and OCSP Stapling , describes it in detail.

Examples

Example of creating the SSLContext can be found in the OCSP Example Class These are the methods of interest…

DescriptionMethod
Standard TLScreateStandardContext()
Vm Wide Check RevocationcreateVmWideOcspCheckRevocationContext()
Vm Wide Don’t Check RevocationcreateVmWideOcspDontCheckRevocationContext()
Siloed Check RevocationcreateSiloedContextCheckRevocation()

Entire VM Approach

It’s trivial to turn on Client Side OCSP revocation checking. It’s as simple as this code, adding system properties:

System.setProperty("jdk.tls.client.enableStatusRequestExtension", "true");
System.setProperty("com.sun.net.ssl.checkRevocation", "true");

The caveat here is that these properties apply to every single SSLContext running in that VM. These properties are checked at runtime, each time a TLS handshake is made, so it cannot be turned on to create an SSLContext then turned off. If it is turned off, revocation checking will not happen.

Siloed Approach

If it’s that easy to turn on OCSP stapling with revocation, why do we need the example?

Consider 3 different types of connections.

  1. Standard TLS
  2. OCSP with revocation checking
  3. OCSP without revocation checking

It appears that setting the system properties does not affect Standard TLS certificate handshakes. But if you need both OCSP with revocation checking and OCSP without, you cannot use the com.sun.net.ssl.checkRevocation property, so you must use the siloed implementation for the context that will check revocation. Find your configuration in this table to see if you have to set the system properties and which OCSP context implementation to use.

Have Standard TLS?Have OCSP With Revocation?Have OCSP Without Revocation?Enable Status Request Extension Flag?Check Revocation Flag?Use Context Implementations
YesNoNofalsefalseStandard TLS
YesYesNotruetrueStandard TLS and Vm Wide Check Revocation
YesNoYestruefalseStandard TLS and Vm Wide Don’t Check Revocation
YesYesYestruefalseStandard TLS, Siloed Check Revocation and Vm Wide Don’t Check Revocation
NoNoNofalsefalseNone
NoYesNotruetrueVm Wide Check Revocation
NoNoYestruefalseVm Wide Don’t Check Revocation
NoYesYestruefalseSiloed Check Revocation and Vm Wide Don’t Check Revocation

Please note, there are a few examples on the internet that guided development examples, in fact the siloed version is almost identical to those, but none of them set the enableStatusRequestExtension flag. As far as we can tell it simply does not work without setting the flag.

About the Author

Scott Fauerbach is a member of the engineering team at Synadia Communications .


Back to Blog