Persistent Storage of Certificate Transparency SCT Responses
Persistent caching of Certificate Transparency SCTs (Signed Certificate Timestamps), in the form of a database-backed storage, has been added in addition to the existing in-memory caching. This reduces the number of requests to the CT log server and increases the performance in the following ways:
- The database-backed storage will be used after a restart when the in-memory cache is empty.
- The in-memory storage has a limit of 100 000 certificates by default, and will only keep the SCTs for the most recently requested certificates. The database-backed storage has no such limit and will be used for SCTs for less frequently requested certificates.
- The database-backed storage will store partial results for a certificate, allowing EJBCA to retry a submission efficiently at a later point.
Additionally, the default configuration was changed to rate-limit connections to logs that are down or return error codes. This reduces the load on both log servers and
EJBCA. For example, if a CT log rate-limits EJBCA, then EJBCA will back off for 1 second by default.
Crypto Token and CA Management REST API
The EJBCA REST API has so far been limited to Certificate Management operations. We've now extended the REST API, adding resources for CA administration as well. This allows simpler remote integration and management as an option to the GUI. New endpoints support Crypto Token and CA Management including:
- CA activation and deactivation.
- Crypto Token activation and deactivation.
- Key generation and removal.
New REST end points in Swagger-UI |
Expect more news from us this autumn!
Cheers,
the PrimeKey EJBCA Team