How-to enable Certificate revocation List (CRL) validation with Talend ESB Runtime

When certificates are issued they usually have a lifetime of a few years. In some cases it is necessary to terminate the validity of a certificate before the planned end of life. For example if a private key was compromised a certificate should not be valid, as soon as possible.

X.509 certificates (the most common certificate type, used for most internet services) support two different types of certificate revocation:

1. Online Certificate Status Protocol (OCSP) RFC-6960
   The application that wants to validate a certificate sends a certificate identifier to the OCSP Server for revocation checking. The response tells the client if the certificate was revoked or is still OK to use.
2. Certificate Revocation List (CRL) RFC-5280
   The application downloads a file that contains a list of revoked certificates and checks if the current certificate is listed in that file.

As you can see already from the RFC number CRL is the older standard which is usually less performant and less up-to-date compared with OCSP. However in this bog post, I will only focus on the CRL approach.

By default most Java applications will not check for certificate revocations as not every certificate contains a revocation URI and it also has a negative performance impact. The same applies to the Talend runtime. However if you need to check for revocations it is easy to activate. All you need to do is to set two system properties:

com.sun.net.ssl.checkRevocation=true
com.sun.security.enableCRLDP=true

You can add these two lines at the end of the runtime/etc/system.properties configuration file.

If you are interested in the complete logging output you can add some debug system properties in the same file as well:

javax.net.debug=all
java.security.debug=all

In the rest of this article I will show you how to create your own certificates that contain a CRL URL to test and validate this setup.

If you are running on windows I can recommend the KeyStore Explorer to you, as it makes it very easy to handle any kind of certificates.

At first you need to create a root certificate authority (CA).

At first I was able to test my setup without a CRL URL in my root CA. But testing again today it was not working. I had to recreate the root ca, add the CRL URL and replace all my other issued keys. After that it was working again as needed.

Next you need to create your server certificate.

For the client certificate you need to do almost the same as for the server certificate, except that you do not need to set a subject alternative name and you need to select the TLS client usage instead of the TLS server usage on the extended key usage settings:

Save the keystore and create 3 copies of that file. Open each file and remove two key pairs from each, so that you end up with 3 files where each file contains a different key pair.

Export eachcertificate into a local file as we will need them later.

Now we can create a certificate revocation list.

Upload this file to your URL that you used earlier when setting the CRL URI in your certificate creation process.

For the root ca certificate you should create a dedicated truststore.

Now you can use your newly created certificates in your ESB runtime runtime/etc/org.ops4j.pax.web.cfg file

You can make the client authentication optional or mandatory by setting wanted (optional) or needed (mandatory) settings to true.

You also need to import the client certificate in your browser so that you can choose it when connecting to your runtime.

Now you are ready to test you setup. Strat your runtime and connect to the console. If you have done everything correct, you will see the following error.

Only certificates where the revocation status can be validated will be accepted now. Certificates without any CRL URLs will be rejected.