Certificate revocation checks are normally done when a connection is negotiated between a client such as an Edge Java SDK application and a server such as the ThingWorx Platform. The Edge Java SDK does not implement certificate revocation directly, but will support client implementations of certificate revocation. As of v.7.0.1 of the Edge Java SDK, the SDK performs periodic certificate expiration checks. If a certificate has expired, the connection to the ThingWorx Platform is closed.

A client can assume a server certificate has not been revoked. This is the most efficient process, as no further checks other than certificate validation need to happen. It is assumed by many that this is what most browsers do.

A client can check for certificate revocation during certificate verification. This check involves retrieving the certificate revocation list from the server’s certificate issuer and seeing if the server’s certificate is on the list. For completeness, this check can also be done for each of the intermediate certificate authorities between the server certificate and the root authority. Alternatively, an Online Certificate Status Protocol (OCSP) server can be queried about the revocation state of a certificate. Either way, there is a time and bandwidth penalty incurred when doing certificate revocation checks.

Performing explicit certificate revocation checks increases the security posture on Edge SDK-enabled applications. If the platform becomes compromised, its certificate can be revoked, and Edge SDK-enabled applications can safely disconnect.

Performing certificate revocation checks periodically during long-standing AlwaysOn connections allows for communication between a SDK-enabled edge application and a server to stop when a certificate’s revocation status changes, rather than having to wait for an AlwaysOn connection to be torn down and reestablished.

Certificate revocation checks add processing overhead to establishing and maintaining an AlwaysOn connection. These checks require communication with one or more certificate authorities to download the certificate revocation list(s) (RFC 5280), or communicating with an OCSP responder (RFC 6960). Customers using cellular modems to communicate with a server may not want to incur such costs.

These checks also add storage overhead because they require the SDK-enabled edge application to hold onto the server certificate. This is not an issue if periodic certificate validation is implemented. As mentioned previously, certificate revocation checks require the downloading of certificate revocation lists, which consume memory, and uses extra network bandwidth, or interacting with an OCSP responder, which uses extra network bandwidth.

You can configure certificate revocation checks on websocket negotiation and periodically when a session is active.

The duty cycle thread re-validates the presented server certificate to ensure that it has not expired while the connection is established.

For certificate revocation, use OCSP. For information about using OCSP, refer to Client-Driven OCSP and OCSP Stapling in the Oracle Java Documentation.