I'm currently writing a network TCP server using SSL. In production, we'll finally require clients to authenticate with a certificate.
In order to revoke certificates in case of a emergency, we would also like to establish a CRL.
My question is: Does Java check CRLs (if provided with the certificate) out of the box or do I need to manually implement such checks?
For testing, I prepared a certificate with a CRL set but Java does not seem to try to validate it (I dropped it into a local web server and there's no access).
I only found the com.sun.net.ssl.checkRevocation=true VM option, but apparently it doesn't query the CRL. VM debugging set to java.security.debug=certpath does not generate any output, either...
Java seems to have related classes in its subsystems (e.g. java.security.cert.X509CRLSelector), but it does not come into play, obviously.
I wrote a small maven-style project using Apache Mina as client server that initializes a SSLContext based on key/truststores and self-signed certificates for client/server which can be downloaded here as ZIP archive: https://www.dropbox.com/s/3fqmd1v9mn2a5ve/ssltest.zip?dl=0
Notice that disabling revocation checking is a bad security practice. You can do it, but make sure you know the risk!
The currently accepted answer by @DoNuT works by setting
PKIXRevocationChecker.Option.SOFT_FAIL
, which causes the validator not to throw an exception even if revocation checking fails. The following answer disables revocation checking altogether, thus it is faster in case you don't want validation at all. This is because performing revocation checks needs contacting CRL distribution points or OCSP servers, and if you don't want that, you need not pay the price.You can simply use
setRevocationEnabled(false)
on an object of typePKIXBuilderParameters
.I figured how to enable CRL checking within a SSLContext without implementing a custom validator, as suggested in the comments.
It is mainly about properly initializing the SSLContext's TrustManagers with a revocation checker, only a few lines, no custom check logic and the CRL is now checked automatically as well as the verification path.
Here's a snippet...
That essentially did what I needed in my application, checking whether a certificate issued to a client is revoked in our CRL. Only checking the end entity and allowing the CRL check to fail is accepted because its all our infrastructure.
First of all, the revocation checking that you can configure in jcontrol (from 1.8) applies only for applet and WebStart downloads and signer certificate checks ! For a programmed https client you can use the PKIXRevocationChecker mentioned above, but by my experience the Oracle implementation doesnt support LDAP CDP downloads at all. When I had this problem I needed to implement the full certificate chain check with CRL and immediate CA cert downloads from LDAP, behind my custom TrustManager's checkXXXX functions...