Presenting EJBCA 6.9.0: Delegated Keypair Generation, Validation and CAA

Greetings to all, and welcome back after a long summer. Just in time for CAA to go live on September 8th, we'd like to present to you all the release of EJBCA 6.9.0. All in all we've fixes about 90 issues during the summer, but we'd like to highlight the four major features of this release: 

Delegated Keypair Generation

As requested by some customers running EJBCA instances as RAs over Peers, this feature is similar to the key recovery feature long used in EJBCA in that it stores generated soft keys encrypted in the database, but with the purpose that the soft keys are generated on the RA (instead of on the CA). The purpose of this is security - where the owner of the RA doesn't wish for the keys to ever be transmitted to the CA but merely be signed. 

Since this feature requires an EJBCA instance running as RA, it only applies to Enterprise customers. 

Validators

In EJBCA 6.9.0 we've introduced the concept of Validators, an API that can perform content validation during certificate creation. To explore this new functionality, look under CA Functions -> Validators

Once there, the Validators management screen should be familiar to most EJBCA users:

All Validators have some common options, as seen at the bottom of each configuration screen:

This allows for setting a description, restricting application of the Validator to certain certificate profiles and to define behavior in cases where the Validator fails (to abort issuance or to merely log and warn), or if the Validator was applied to a value it couldn't validate (such as an RSA validator on an ECC key). 

RSA/ECC Key Validation

Foremost we've implemented Key Validators, which can be applied to a CA to reject incoming signing requests based on inadequate key length or poorly chosen exponents. Both of these validators are quite powerful. Looking at the RSA Validator:

We can see immediately that the Validator gives control over exponent size and modulus, as well as restricting key sizes to either a custom list, to those set by the Certificate Profile or to the CA/B-Forum recommendations. 

Exploring the ECC Validator, we find a similar level of control there:

Lastly, both Key Validators can be restricted to certain time periods, which allows for enforcement of standards from or up until a certain date:

BlackList Validators

We've also developed an API for blacklisting signing requests based on known information. In EJBCA 6.9.0 we've implemented a Key Blacklist Validator, which will check incoming certificate requests against a user defined blacklist of known bad keys. 

Keys can be added to the blacklist using the EJBCA CLI:

This command can also be used to upload a complete list of blacklisted keys. PrimeKey Solutions can provide list of known bad keys as compiled by the metasploit project, contact us for more info. 

Certificate Authority Authentication (CAA) Validation

Last and absolutely not least, EJBCA 6.9.0 can perform CAA checks during or after certificate issuance, as I wrote about last spring. We have implemented CAA support in two methods, the first being a manual CLI tool that can be used to manually verify CAA records:

The second is in the form of a Validator:

This Validator allows specification of issuer, DNS Resolver and whether to validate DNSSEC for results, as well as options for how to handle IODEF statements. Note that EJBCA doesn't support WebService IODEF calls (RFC 5070) yet.

CAA support is an Enterprise only feature. 

Cheers!
Mike Agrenius Kushner,
Product Owner EJBCA