com.sun.net.ssl.checkRevocation Java System Property

Default Value

false

By default the JDK does not check whether a server (or client) certificate has been revoked when validating a TLS certificate chain.

Overview of com.sun.net.ssl.checkRevocation

When the com.sun.net.ssl.checkRevocation system property is set to true, the default X509TrustManager provided by the SunJSSE provider will enable revocation checking on the PKIX certificate path validation performed during a the TLS handshake. Internally the property is read by sun.security.validator.PKIXValidator, which calls PKIXParameters.setRevocationEnabled() with its value for TLS client and TLS server validation.

Because the value is read into a static field, it should be set on the command line (for example -Dcom.sun.net.ssl.checkRevocation=true) or very early in application startup, before any TLS connections are made.

Revocation Checking Requires Additional Settings

Setting com.sun.net.ssl.checkRevocation=true on its own turns on revocation checking, but the JDK also needs to know how to obtain revocation information:

• Client-driven OCSP - set the ocsp.enable security property to true. Per Oracle's documentation: "Both steps are necessary. The ocsp.enable setting has no effect unless revocation checking is enabled."
• CRL Distribution Points - set the com.sun.security.enableCRLDP system property to true to allow the JDK to download CRLs from the URLs listed in a certificate's CRL Distribution Points extension.
• OCSP Stapling - when the server staples an OCSP response (requested by the client via the jdk.tls.client.enableStatusRequestExtension system property), the stapled response is only used in certificate validation if revocation checking is enabled. Otherwise, "the connection will be allowed to proceed regardless of the presence or status of the revocation information."

If revocation checking is enabled and the revocation status of a certificate cannot be determined (for example, the OCSP responder or CRL server is unreachable), the certificate validation will fail and the TLS handshake will not complete.

The blocked.certs File

Independent of the com.sun.net.ssl.checkRevocation setting, the JDK ships with a list of distrusted certificates in the $JDK_HOME/lib/security/blocked.certs file (named blacklisted.certs in JDK 8). Certificates in this file are always rejected, even when revocation checking is disabled.

The blocked.certs file contains certificates that have been compromised in high profile incidents. For example, the October 2026 OpenJDK vulnerability advisory (CVE-2026-91403) concerns eight compromised eMudhra intermediate CA certificates, which were added to the blocked.certs file.

The file is updated with JDK releases, but you can also download the latest version and replace your local $JDK_HOME/lib/security/blocked.certs file:

• Windows: https://ops.java/windows/blocked.certs
• Other operating systems: https://ops.java/unix/blocked.certs

For JDK 8, rename the downloaded blocked.certs file to blacklisted.certs, the file location is the same.

Because blocked.certs only covers specific certificates that have been added to it, the advisory also recommends enabling revocation checking with -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true.

Other Networking System Properties

Here are some other networking Java system properties:

• com.sun.security.enableCRLDP
• http.agent
• http.keepAlive
• http.maxConnections
• http.nonProxyHosts
• http.proxyHost
• http.proxyPort
• https.protocols
• https.proxyHost
• https.proxyPort
• java.net.preferIPv4Stack
• java.net.preferIPv6Addresses
• java.net.useSystemProxies
• javax.net.debug
• javax.net.ssl.trustStore
• jdk.http.maxHeaderSize
• jdk.net.hosts.file
• jdk.tls.client.protocols
• jdk.tls.server.newSessionTicketCount
• jdk.crypto.disabledAlgorithms
• jdk.tls.disabledAlgorithms
• networkaddress.cache.negative.ttl
• networkaddress.cache.ttl
• ocsp.enable
• sun.net.client.defaultConnectTimeout
• sun.net.client.defaultReadTimeout
• sun.net.inetaddr.ttl

References

• Client-Driven OCSP and OCSP Stapling - Java 8 Documentation
• PKIXValidator.java - OpenJDK Source
• OpenJDK Vulnerability Advisory 2026-10-21

Supported Since

Java has supported the com.sun.net.ssl.checkRevocation system property since at least Java 8.

Setting com.sun.net.ssl.checkRevocation on Startup

You can set the com.sun.net.ssl.checkRevocation java system property during startup of the java runtime using the -D command line argument:

java -Dcom.sun.net.ssl.checkRevocation=true MyAppMain

You may also be able to specify com.sun.net.ssl.checkRevocation via the JAVA_TOOL_OPTIONS environment variable:

JAVA_TOOL_OPTIONS=-Dcom.sun.net.ssl.checkRevocation=true

Setting / Reading com.sun.net.ssl.checkRevocation at Runtime

You can set com.sun.net.ssl.checkRevocation at runtime with the following Java code:

System.setProperty("com.sun.net.ssl.checkRevocation", "true");

WARNING: Depending on the property and JVM version using setProperty may or may not work if the JDK Java class that uses this variable has already been loaded. The value of the com.sun.net.ssl.checkRevocation system property may be cached within an internal private static variable of the implementing class.

To read the value of com.sun.net.ssl.checkRevocation at runtime, you can use this Java code:

String propertyValue = System.getProperty("com.sun.net.ssl.checkRevocation");
if (propertyValue != null) {
    System.out.println("com.sun.net.ssl.checkRevocation = " + propertyValue);
} else {
    System.out.println("com.sun.net.ssl.checkRevocation was null");
}