CRL Generation

A new CA should always issue an (empty) CRL and this is done when the CA is created.

Expired certificates are normally removed from CRLs in accordance with RFC5280. This behavior is configurable, see the setting for Keep Expired Certificates on CRL in CA Fields.

Generating a CRL

Manually

CRLs can be generated using Basic functions in the Admin GUI, or using the CLI by running the following command:

bin/ejbca.sh ca createcrl <CA name>

For more information on how to configure CRL periods, CRL Distribution Points and CRL Issuers, see CA Fields and Managing Certificate Profiles.

Automatically

Use one of the following ways to make EJBCA automatically create updated CRLs:

Using the CRL Update Service Worker

In the Admin GUI, go to Edit Services and add a new service. Edit the service and select the CRL Updater worker and the interval to use. Make sure to set the service to Active.

This service checks, at the selected interval, if it is required to regenerate the current CRL (due to being expired or within the expiration threshold), and generates a new CRL if needed.

For more information on the CRL Updater service, see Services.

Using Unix Cron

CRLs can also be generated by having a cron job or equivalent call bin/ejbca.sh ca createcrl. The createcrl command checks all active CAs and if an update of their CRLs is required.

To force CRL generation for a CA, use bin/ejbca.sh ca createcrl caname.

An example crontab entry:

PATH=$PATH:/usr/java/jdk1.6.0_24/bin
@daily cd /home/ejbca;/home/ejbca/bin/ejbca.sh ca createcrl;

where /usr/java/jdk1.6.0_24/bin is the path to where java can be found and /home/ejbca is where ejbca is installed.

The following displays a sample crontab to be installed with crontab -e:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
CLASSPATH=$CLASSPATH:/root/ejbca
APPSRV_HOME=/usr/local/jboss
#m h dom mon dow command
00 0 * * * cd /root/ejbca;./bin/ejbca.sh ca createcrl

Delta CRLs

EJBCA can issue delta CRLs. In the CA configuration, set Delta CRL Period to the amount of time your delta CRLs will be valid if delta CRLs are issued. Command line interface and CRL Update service will generate delta CRLs if Delta CRL Period is larger than 0.

Retrieving CRLs

EJBCA stores all generated CRLs, unless you manually remove them from the database.

You can retrieve CRLs (either the latest CRL or a CRL with a specific CRL number) using the command line interface, the Public Web or the RA Web:

  • To retrieve CRLs using the command line interface:

bin/ejbca.sh ca getcrl --help
  • To retrieve CRLs using the Public Web, select Public Web>Fetch CA CRLs and use the additional parameter crlnumber=<crl number>.

  • To retrieve CRLs using the RA Web, select RA Web>CA Certificates and CRLs and use the additional parameter crlnumber=<crl number>.

CRL Generation Efficiency

In order to generate a CRL, index the following database queries to be efficient:

SELECT MAX(a.crlNumber) FROM CRLData a WHERE a.issuerDN=:issuerDN AND a.deltaCRLIndicator=-1 (or >0)
SELECT a FROM CRLData a WHERE a.issuerDN=:issuerDN AND a.crlNumber=:crlNumber
SELECT a FROM CerttificateData a WHERE a.issuerDN=:issuerDN AND a.status=:status
SELECT a FROM NoConflictCertificateData a WHERE a.issuerDN=:issuerDN AND a.status=:status

Ensuring that these queries are efficient over time, with a growing database, implies adding indexes to your database, as laid out on the file doc/sql-scripts/create-index-ejbca.sql. In particular:

  • crldata_idx3

  • crldata_idx4

  • certificatedata_idx6

Large CRLs

It is not possible to name a maximum size of CRLs, since this depends on the system used and there are users generating CRLs with millions of entries. In general, generating large CRLs requires:

  • Good database indexes in order to look up all revoked certificates.

  • Enough RAM memory allocated to JBoss in order to construct the CRL.

  • Depending on exactly how large it is, some timeout tweaking may be needed as well, if it takes a long time to generate CRLs.

  • Database tuning may be needed to run very large queries and for storing the resulting CRL, that can be hundreds of MB, in the database (an example is the max_allowed_packet setting in MariaDB/MySQL).

To generate really large CRLs, you can use a dedicated node for CRL generation in order to not affect issuance nodes while a large CRL is being generated.

To test large CRLs, you can use the clientToolBox Web Service stress test Revoke mode to revoke certificates issued, allowing you to quickly generate hundreds of thousands of revoked certificates. The revoked certificates can be issued from a dedicated test CA, enabling the database to be cleaned easily (although backup/restore before and after the test is most effective). The test allows you to generate a hundred thousand entries first, create a CRL, then generate 2 hundred, 5 hundred, 1 million and at the same time keep an overview of how the time to generate the CRL increases and the size of the generated CRL.

To view command usage instructions, run:

./ejbcaClientToolBox.sh EjbcaWsRaCli stress

If run with the mode REVOKE, certificates will be issued and then revoked, producing revoked certificate entries that will be on the next CRL generated.