EJBCA Development - Moving towards Continuous Delivery (finally...)

So a slightly more informal post from me, but I'd like to talk about a few of the changes we've been making in our development process here in the EJBCA team, and how they affect you as our customers.
I officially took on the role as Product Owner of EJBCA a bit less than a year ago without it really existing beforehand. How we got to that point is mostly historical and tied to our roots as an open source project. Tomas, EJBCAs founder and PrimeKey's current CTO was (and still is) EJBCA's face to the world, and with a small and tight development team around him responsibility for features, product cycles and roadmap was mostly ad-hoc, and this is where I came in nigh eight years ago as a developer.
In the time that has passed since then we've grown quite a bit and our user base has grown even more; as we mature from being a scrappy little FOSS project to what will hopefully be seen as a solid and well built software suite that can contend with the best of them.

Changes are coming, some which you all may notice directly and others that hopefully will be felt by us being quicker to adapt, better att keeping our deadlines and delivering better quality on the first try. One of the changes which has been silently in place for a while, but which I feel brave enough to advertise now is that we've moved towards continuous delivery:

A snapshot of our public repository. 

Since a while back the EJBCA team has been running on three week sprints, and with some tinkering we've finally gotten to the point where we can reliably produce a deliverable at the end of each sprint. Pictured above is the first Alpha of EJBCA 6.11.0, which we released at the end of the sprint on Wednesday. On Wednesday in three weeks it'll be joined by the next Alpha, and so forth until the release.
These Alpha releases are available for download for all Enterprise customers, the purpose of which is primarily for you guys to be able to evaluate and give feedback on ongoing development. In the future I'll also to try figure out a good way of showcasing the contents of each Alpha, while also making sure that there is some form of VM available for those of you who don't have a testing environment ready to deploy to.

EJBCA 6.10.0.1 Patch Release

Just a quick note, we just released a patch release of EJBCA 6.10.0. In it we've fixed a couple of corner cases for CAA, as well a library used in the CMP Proxy which we had missed renaming in our configuration files.

Presenting EJBCA 6.10: Customized RA Layouts and CMP Keypair Generation

Happy halloween to all, we the Plucky Khobolds of PKI have been toiling away at another release.

Customized RA Layouts

Speaking of costumes and dressing up, EJBCA 6.10 introduces an extremely neat feature to the RA web: not only the ability to upload custom stylesheets and logos on the CA web to be used in the RA, and not only setting these per role, but having these transmitted to a remote RA over the Peers protocol. This means that the look-and-feel of an RA placed in an entirely different country than the CA can be modified CA-side without even  requiring a restart of the RA, and it can be done for multiple users depending on their role.

Adding a custom style is trivial, just go to System Configuration and click on the Custom RA Styles-tab. From there simply upload an archive containing a modified copy of the RA's stylesheets and/or a custom logo, and then give it a name.

Thereafter you may simply go to the Administrator Roles-screen, where there now is a new column to set a custom stylesheet for each role if one wishes.

ROCA

On the theme of scares and frights, we're sure that nobody missed the ROCA vulnerability that was made public this month, as written about here. While EJBCA has never used Infineon libraries for key generation (and to the best of our knowledge, none of our supported HSM vendors do either), we've still been capable of signing weak keys submitted from other sources. Fortunately since we introduced the RSA Key Validator back in EJBCA 6.9, adding a ROCA check there as well was trivial. For those of you running or planning on running RSA Key validation, we strongly recommend activating checking for ROCA weak keys.

Central Keypair Generation over CMP

On the CMP side we've added the concept of Central Key Generation which allows for a request for a keypair generated CA side to be transmitted and returned over CMP.

Other Fixes

Certificate Transparency has been given the ability to specify, apart from the minimum number of required logs, which logs which are considered mandatory to write to - this in anticipation of new requirements from Chrome coming in 2018. We've also kept working on our CAA validator, hammering out various corner cases and parallelising DNS lookups for certificates containing multiple DNSNames.

From an upgrade perspective we're happy to see many legacy installations (EJBCA 4.0 and older) beginning to upgrade towards more modern versions of EJBCA, and have received some bug reports specific to older deployments which we've fixed in this release. Currently we support upgrading directly from EJBCA 5.0.16 or later. EJBCA 6.10 introduces no database changes, so upgrading from 6.9.x doesn't involve any automatic or manual upgrade steps.