CA Database Pruning - dogtagpki/pki GitHub Wiki

Overview

This page describes the CA database pruning functionality in PKI 11.3.

Background

Normally the CA keeps track of enrollment/renewal requests and issued certificates by creating request records and certificate records in LDAP database.

Prior to PKI 11.3 there was no supported method to prune these records, so the database could continue to grow without limit, and that will potentially cause issues such as excessive storage requirement, performance degradation, and increased costs.

While it’s possible to remove the records directly from the database, it’s not a procedure that can be guaranteed to work safely with legacy serial number generators (i.e. sequential or RSNv1). These generators rely on a range management system to avoid serial number collisions in a cluster environment. This system is complex and fragile since it maintains its state in memory, in the local configuration file, and in the database at the same time, and occasionally redistributes the range among other servers in the cluster.

If records are removed directly from the database without considering the state stored in memory and in the configuration file, there is a risk that the range management system could enter an inconsistent state, and the CA might stop issuing certificates. The recovery procedure if this happens is not well tested/documented, so it’s highly recommended to avoid this situation in the first place, especially in large/complex deployments.

Solution

In order to remove the records safely, the CA needs to use the RSNv3 to generate the certificate serial numbers and enrollment/renewal request IDs. RSNv3 works by generating large random numbers which mathematically have a negligible risk of collisions, so it does not need the range management system anymore. This way the CA can generate unique serial numbers without depending on existing records in the database.

The CA in PKI 11.3 provides a pruning job that will remove:

  • certificates that have expired for some time

  • completed requests corresponding to the expired certificates

  • incomplete requests that have been idle for some time

This job will need to be scheduled to run regularly to remove a certain number of records each time it runs. The remaining records will be removed in the subsequent runs. In large deployments it will be possible to distribute the job among the servers in the cluster.

See Also

⚠️ **GitHub.com Fallback** ⚠️