Monday, April 9, 2018

EJBCA 6.12 - Brand New Documentation and Auditing Capabilities Galore!

The PrimeKey EJBCA team is pleased to announce the feature release EJBCA 6.12, and a small step but important step forward in the development of EJBCA. The first changes I'd like to divulge are organisational, we added some very important personell to our team. PrimeKey has hired a dedicated tech writer, Annica, who will be helping both the EJBCA and SignServer teams to get our much maligned documentation in order. Secondly, we've started taking in some outside help for development work, integrating them into our core team in order to increase throughput. So, what is new with this release?

Revamped Documentation

Having listened to all your calls of woe and distress over the state of the documentation (and I may add, much of our own), our tech writer Annica has performed a Herculean effort in shifting the entire thing over to Confluence instead of the ancient xdoc format.
Naturally, this is just a first step towards a far more organized, updated and user friendly documentation. You may notice a sense of chaos and disarray in the current structure, and while we agree with you fully, that is merely a consequence of the already existent structure coming to light. Major changes to take notice to that the release notes (this document), change log and upgrade instructions have all been moved in here as well. They're still available offline from within the doc folder in the release zip, but are now also published both online and deployed with EJBCA to the application server.

Configurable OCSP Extensions

We've put quite a bit of work into OCSP Extensions. Those of you familiar with OCSP Extensions will probably remember configuring them through configuration file.

In order to make extension configuration simpler and more precise we've moved it to the UI, and set it up to act per keybinding instead. Any existing extensions defined in the configuration files will automatically be added to existing OCSP keybinding configurations, but please read more about that and more in the upgrade notes.

Additional Proxying Capabilities in the RA

As response to external demand, we've added two new features to the RA:
  1. The ability to proxy SCEP requests, much as is done with CMP and EST already
  2. We added forwarding of revocation and revocation status requests over SOAP. The full list of methods in the EJBCA WS that can be proxied via the RA are:
  • certificateRequest
  • checkRevokationStatus
  • getLastCertChain
  • keyRecover
  • keyRecoverEnroll
  • revokeCert

The ConfigDump Export and Audit Tool

Some of you may be previously familiar with our StateDump tool, an application for exporting and importing installations. While this has solved many problems for us and some of our customers in our past, a very common deficiency in the tool has always been that the XML based dumps are difficult to read, edit and manage, and that the data therein has never been human readable. We have thus decided to venture on remaking this tool from the ground up, and making the first iteration (which is only export capable) publicly available. It is built and run from the command line:
This results in a neat structure of export files sorted by type:
Which are serialized and normalized as yaml objects. Any UID references are replaced with their human-readable names.
We very much hope that you'll find this tool useful in the future for change handling and auditing.
Mike Agrenius Kushner
Product Owner EJBCA

Tuesday, February 13, 2018

Roadmap Update: EJBCA 7 and What Lies in Store

Getting roadmap information out of me is usually about as rewarding as mining obscure crypto currencies, but for once I feel that this is a very good opportunity to talk a bit about the roadmap in the next half year, about EJBCA 7 and what is to come.

Technology Leap

Now, the easy announcement is that EJBCA 7 will be released before the end of Q2 of 2018, and the most marked technology leap will be dropping support för JDK7 and JEE6, so those of you who haven't migrated to JDK8 or greater yet should start planning to do so very soon. Things to have in mind:

  • JDK7 had its final support release over a year ago, which is one reason we've chosen to move on.
  • This means that your application server will have to be JBoss EAP 6.3.3 or later.
  • From EJBCA 7 and beyond we'll being using JDK8 features in the source, meaning that you will have to upgrade your JDK/AS before then. In any case we very much recommend upgrading to the latest version of EJBCA as well if you haven't done so yet.

User Interface Changes 

The primary changes you'll be seeing is that we're going to start optimizing and improving workflow in the existing UI. For that reason we'll be removing a lot of pages which have turned redundant or which are too antiquated to maintain.

Public Web

This is going to be the biggest change for many of you, and one of the most dramatic ones: the Public Web is going to be considered deprecated. The reasons for doing so are many, but foremost the fact that the new RA Web does (or nearly, but will do) everything the Public Web does, but better. While I hope that most of you have had a chance to explore and hopefully even start using the RA Web, this is a very good time to start migrating your workflows. If this leaves you with any sense of dread, fret not: we have documented how workflows translate between the Public Web and the RA Web here and here

Note that we won't be removing the Public Web initially but simply not link to, refer to or update it anymore, so there will be an overlap period. 

Admin Web/CA Web

The first major change is a simple one: a question of branding. We have traditionally, both in code and in UI misused the terms Administrator and Administration. In the line of defining an administrator as somebody who performs administrative tasks (which doesn't cover all users of the UI) we'll be renaming the current Admin Web as the CA Web to reflect the fact that its purpose mainly covers setting up CAs and profiles, while the RA Web covers all aspects of of end entity creation and lifecycle management. 

The introduction of the RA Web may have raised some questions about the overlap between the two interfaces, such as the ability to create end entities in both. Naturally, our end goal is to eliminate these overlaps in order to make workflow feel natural an intuitive. For that reason, we'll be deprecating some pages in the CA Web by removing links and references, though as with the Public Web we'll let the pages exist for some time to allow for some overlap. The pages in the CA Web that are going to disappear are (sorted by category):

  • RA Functions
    • Add End Entity
    • Search End Entities
  • Supervision Functions
    • Approve Actions
All of these pages have superior analogues on the RA Web, and it's our goal that our workflows become so intuitive that there will be no need to switch between the two. 

What Comes Next? 

In addition to this, I'd like to let you know a bit about workflows in the UI. Currently the workflows are what could generously be called unintuitive, which is something we're looking to remedy come 2018 and beyond. The design currently largely mirrors the architecture, which while straight forward from a developer's perspective requires way too much domain knowledge from a user's point of view. Our ambition is to start refining and redefining workflows during the coming year to make more sense from what one is trying to accomplish, but we'll be doing so gently and properly documenting and motivating all changes.

We hope you're looking forward to these changes as much as we are!

Mike Agrenius Kushner
Product Owner EJBCA

Friday, January 12, 2018

Feature Highlight: Approval Profiles

So the concept of approvals is a rather well known concept in EJBCA. The basic concept is that your organization may not trust lower level or individual administrators to perform certain actions (such as enrolling end entities or renewing certificates), and thus require either higher level administrators (with specific approval rights) or a multitude of administrators (requiring a conspiracy) to perform certain actions, or a mixture of both.

In EJBCA 6.6 we introduced the concept of Approval Profiles due to the fact that we got a customer request to implement a more dynamic and complex approvals process, while we were at the same time unwilling to drop the old one.

Accumulative Approvals

Accumulative Approvals represents the type of approval process which existed prior to EJBCA 6.6, now given a name to differentiate it from later implementations. The concept is rather simple: say that we have a PKI organization containing a relatively flat structure, simple three administrators:
For the sake of argument, let's presume that these three are all equal, but their policies require that none of them be able to perform any enrollment actions without the cooperation of at least one of the other. Traditionally we would simply set the number of approvals in the CA or Certificate Profile to two, but now that we use Approval Profiles we set up an Accumulative Approval Profile instead:

Partitioned Approvals

In EJBCA 6.6 we added a more complex form of approvals, which we've decided to call Partitioned Approvals. Partitioned approvals consist of two basic temporal concepts: steps and partitions. The diagram below tries to explain this in simple terms: 

The basic concept is that steps are solve sequentially, while partitions are solved in parallel within their step. What this means is that (for example) Step2:Partition1 can't be approved until all three partitions in Step 1 have been approved. Now, how might this be used? Well, let's presume the following organization:
This structure resembles an actual PKI organization far more. The players here are:
  • Alita  -  An RA Administrator whose role is to meet certificate applicants after they've enrolled using the RA UI and to verify their identities. 
  • Björn - Works for Financial Services. Does not have any rights to enroll customers, but has been tasked in verifying that customers have payed their fees. 
  • Beatrix - Works for the company's security division. Lacks like Björn the ability to enroll customers, but is tasked in performing background checks on prospective clients. 
  • Cilla  -  A supervisor who has to approve the work of the previous three. If she's happy, then the customer can next retrieve their certificate. 
Now, looking at the graph above you may infer that Alita's, Björn's and Beatrix' tasks are all part of Step 1. The reason for this is that Cilla  isn't interested (or allowed) to give her approval until she's verified the results of Alita, Björn and Beatrix. 

On the other hand, there is nothing stopping Alita, Björn and Beatrix from solving their tasks in parallel. Once all of them approved their respective partitions, the process will automatically transition to Step 2. Combining these two diagrams we get the following, with blue representing view access and green representing approval rights:

So, what does this look like in EJBCA? Well, an initial Partitioned Profile will look like this:
As you can see above, we initially have a single step containing a single partition, which is the minimum possible. You'll also notice in the center of the partition the two multi-selects that display all available Roles with approval rights. Let's add another step by clicking on the Add Step button on the bottom right:
Next lets create the partitions in Step 1. First we'll click the Add Partition button on the bottom right of that step twice, name the partitions and assign the roles: 

Notice above that the roles do not have view rights of each others' partitions (except the RA Administrator partition, who anybody can review), and that the Supervisor role can review all. Next, let's edit Alita's partition so that she can add a bit more information for the records:
By clicking on the Add Field button (which is hidden in the above screenshot behind the drop-down) we can add meta data fields to the partition. In this case we've added a check box, a radio button list to identify the type of identification provided and a free form text field for any other information (such as passport number). 

We'll set up Beatrix' and Björn's partition in the same way, then lastly make sure that only the Supervisor group has approval and review access to the final step:
This way the supervisor can review and verify that all previous actions have been performed correctly and without fault before allowing the enrollment process to continue.

Practical Example

Now, let's see what this looks like in real life! For this example we're going to follow closely the RA Administrator Alita and her supervisor Cilla, while letting Beatrix and Björn do their work in the background for brevity. First of all, we make sure that the familiar WidgetCorp CA is set up to use the above approval profile for enrollment:
Then along rolls our old friend Alan Widget, who's about to request that the CA generate a keypair for him:
As we've activated approval for the CA, naturally Alan will have to wait a bit to receive his keypair:
Logging in as our RA Administrator we can see that she now has an approval request pending:
And viewing that request, we can fill in the relevant data about the request:
Logging in as the Supervisor on the other hand, you'll notice that the To Approve tab is empty as the Supervisor doesn't have anything to approve in the current step, while the request is instead under the Pending Approval tab as the Supervisor can still review the other's work.
Once Security and Finances have approved (or denied) their respective partitions of the request, the step is automatically completed and moves on to the final step that we've defined, which is the approval of the Supervisor. She now has the request under the To Approve tab, where she can also review all of the previous steps that she has view access to:

Approving the final step will leave the entire request executed, and our end user is now free to retrieve their certificate:
So, that is in a nutshell how to use Partitioned Approvals in EJBCA. If you have any feedback, feature requests or questions, please let us know! And if there are other EJBCA features you'd like me to dive into, please comment here on the blog!

Mike Agrenius Kushner
Product Owner EJBCA

Tuesday, January 2, 2018

EJBCA 6.11: Adding EST, Modular Configuration and External Validators to the Mix

Hey folks, and welcome to 2018. We have an exciting year to look forward to, but I'll go a bit deeper into the currently projected roadmap in a bit, because this blog post is as usual devoted to a deeper dive into the release notes for the latest release.


First and foremost, EJBCA 6.11 introduces a long awaited feature: support for the EST protocol, as defined in RFC 7030. For those of you now in the know, EST is an enrollment protocol similar to SCEP. Much like CMP and SCEP, EST can be configured through multiple aliases, and can like CMP also have calls proxied from an RA up a CA using the Peers Protocol.

External Command Certificate Validators

The second main feature of this release is the concept of External Validators, a feature which has been widely requested by quite a few of our enterprise users. An External Validator functions much like the existing validators (RSA, CAA, etc), but it runs on either a certificate or pre-certificate object and calls on local script on the local system.

As a security feature we've added a configuration value under System Configuration that disables both the External Validator and the General Purpose Custom Publisher. This configuration value is set to be disabled by default unless you're currently running a General Purpose Custom Publisher in your installation. To avoid a malicious user using the External Validator to run system commands, we've also added a command whitelist.

Modular Protocol Configuration

We've also added a few of features to make VA/RA installations more secure in the DMZ. In order to guard against possible 0-days or protocol vulnerabilities we've added the Protocol Configuration-tab to System Configuration. Through this tab all incoming protocols or servlets can be disabled.

Additionally, we've added access rules to allow prohibiting CMP and WS calls being sent from the RA/VA to the CA via Peers in case the RA/VA runs the risk of being compromised.

Upgrade Concerns

Lastly, we've updated the VA so that SHA1WithRSA and SHA1WithECDSA are no longer acceptable signature algorithms for an OCSP responder, see the upgrade document for more information.

Mike Agrenius Kushner
Product Owner EJBCA

Monday, December 11, 2017

EJBCA 6.10.1: Performance and Rethinking Certificate Transparency

Here is the official release companion post for the release of EJBCA 6.10.1, where I'm going to go into a bit of detail about the new features to check out in the latest release. First and foremost, let's talk about the two easy ones:


Some of our truly high volume customers (you know who you are) discovered a performance degradation in EJBCA when trying to upgrade to EJBCA 6.9 and later a few months back. Sadly this was nothing we discovered ourselves as we normally don't test at such high volumes, and neither do most of our customers. Testing and diagnostics showed that this degradation has been gradual over the course of a couple of years.

With EJBCA 6.10.1 we have put a ton of effort into profiling and optimizing, and while we're not yet fully back to previous levels we're at least within parity, and we still have some improvements to make. Most of you don't produce the volumes of transactions where you'd notice the difference, but for those of you that would EJBCA 6.10.1 can perform double the throughput in comparison to EJBCA 6.10. 

In order to avoid similar degradations in the future we've also added a performance testing project to our CI environment with weekly monitoring. 

Custom Certificate Extensions for CV Certificates 

Another new feature introduced in EJBCA 6.10.1 (for Enterprise customers only) is the addition of custom certificate extensions for CV certificates as well. Setting them up is done as usual under System Configuration Custom Certificate Extensions

Improvements to Certificate Transparency Logs 

We've actually redefined quite a bit how to set up CT logging in anticipation to the new Certificate Transparency logging requirements which are going to be coming into effect in Chrome in April of 2018. In short, the new requirements can be summarized as the following:
  1. Writing to an n number of CT logs is not sufficient, but at least one of these logs must be one of the Google CT logs. 
  2. The minimum number of logs to be written to should be defined by the validity time of the certificate. 
  3. Performance requirements by CAs require that writing to n logs in the quickest manner possible takes precedence over log order. 
We made a small improvement back in EJBCA 6.10.0 in which we introduced the concept of "mandatory" logs in order to solve the first requirement. 
The Mandatory requirement introduced in EJBCA 6.10
We ourselves felt that it wasn't going to be sufficient in April, so we revisited the concept and redesigned it a bit, coming up with the following. Firstly, we redefined the mandatory/non-mandatory-status as freeform labels instead:
Labels redone in EJBCA 6.10.1
What you see above is the results of the first screenshot upgraded ot 6.10.1 Instead of the Mandatory-checkbox all of the logs have been sorted in under a label named Mandatory. You may notice that one of the logs wasn't marked as mandatory originally, and this is a conscious choice where we've chosen to view all of Google's logs as mandatory as well. Any non-mandatory non-Google logs will be sorted under Unlabeled. Upgraded logs can then be relabeled and new/existing labels can be applied to new logs that are added:
The contract that these labels infer is that at issuance time, at least one log from each label will be written to (satisfying requirement 1), and given that constraint the other logs will be written to in parallell and the first n SCTs received in reply will be used in the certificate, optimizing issuance time and satisfying requirement 3. 

You may also have noticed the table in the second to last screenshot:

The values from this table are from Google's own specification, but are configurable to allow for future changes. The purpose of this table is to be able to set the number n of CT logs to write to at issuance time based on the validity of the certificate being signed. As a reminder, setting up the minimum/maximum amount of logs to write to in previous versions of EJBCA was done in the following manner in the certificate profiles:

In EJBCA 6.10.1 setting up Certificate Transparency in the certificate profiles looks like the following:
Naturally, you'll notice that individual logs have instead been replaced by labels. The min/max setup from previous versions still remains, but we've added the By Validity-option, which instead sources the sought value from the previously show table att issuance time.

So that's it for now for us. We've been working on EJBCA 6.11 in parallell to this release, so you can expect to see it come out quite shortly. Any feedback on our CT implementation would be greatly appreciated, as we still have plenty of time to amend it before April.

Mike Agrenius Kushner
Product Owner EJBCA

Friday, December 1, 2017

The Definitive EJBCA Upgrade Guide

So, we've heard that a lot of you have been having trouble with upgrades, so we've made an effort to both explain and make the process way easier.

Yeah, we know. You can stop laughing now. Really. We've done better this time, we promise.


The official steps for upgrading any EJBCA installation are:

If running EJBCA < 4.0.16 on JDK6 or earlier:
  1. Upgrade to EJBCA 4.0.16
  2. Run ant upgrade from the console
  3. Run ant post-upgrade from the console
  4. Continue below
If running EJBCA >= 4.0.16 but < 5.0.12 on JDK6 or earlier:
  1. Upgrade to EJBCA
  2. Run ant upgrade from the console
  3. Run ant post-upgrade from the console
  4. Upgrade to JDK7 or JDK8 
  5. Upgrade application server to a JEE6 supporting server
  6. Deploy the latest version of EJBCA 
  7. Run ant upgrade from the console
  8. Run post-upgrade from the UI
If running EJBCA >= 5.0.12 but < 6.4.0:
      1. Upgrade to JDK7 or JDK8 (if required)
      2. Upgrade application server to a JEE6 supporting server (if required) 
      3. Upgrade to latest version of EJBCA 
      4. Run ant upgrade from the console
      5. Run post-upgrade from the UI
      If running EJBCA >= 6.4.0:
      1. Upgrade to latest version of EJBCA 
      2. Run post-upgrade from the UI


      A typical upgrade path:

      1. EJBCA 4.0.16 (on JDK6, JBoss 5.1.0.GA) 
      2. EJBCA (on JDK6, JBoss 5.1.0.GA) 
      3. EJBCA (on JDK8, WildFly 10.1) 
      4. EJBCA 6.x


            The background to writing this guide both stems from the understandable confusion in regards to upgrading EJBCA and many of our users experiencing problems when upgrading decade old installations. Thus there are some concepts we'd like to go through and explain:

            The Intermediate Release: EJBCA

            Description: During EJBCA 6.8.0 we refactored the roles and access rules massively, which lead to an upgrade break when upgrading from versions of EJBCA prior to 5.0 (though upgrading via EJBCA 5.0 was still possible). As we realized that solving this issue while preserving 100% uptime requirements (see below) was impossible, as well as due to the technology jump (see the next section) and bugs that we discovered while testing upgrading from ancient installations, we created EJBCA in order to handle all the intermediate steps. As of today EJBCA is published and available in the Community Edition on SourceForge, and in the download area for customers.  

            Technology Jump - JDK6 → JDK7

            When: EJBCA 6.4.0

            Description: All good things must come to an end, as must support for legacy runtime versions. As much as we value not having to put our customers through unnecessary hoops by forcing them to upgrade underlying technology such as the JDK, at some point we have to drop support due for several reasons: being held back by not being able to use modern developments, because other dependent systems like Application Servers drop support as well and because the JDKs themselves come to the end of their service lives and will no longer receive support from the vendor. 

            Technology Jump - JEE5 → JEE6

            When: EJBCA 6.4.0

            In EJBCA 6.4.0 we decided to move on to JDK7, which means that it can no longer be deployed to application servers based on JDK6 such as JBoss versions 4 and 5. The latest version that can still run under JDK6 is EJBCA For an upgrade path this means that you can continue running on your old JBoss 5.1.0.GA server (JEE5) up to, and including, the EJBCA intermediate release. At this stage you must upgrade JDK and the application server, suggestedly to JDK8 and JBoss EAP 7 or WildFly 10.

            100% Uptime during Upgrade

            When: EJBCA 4.0

            Description: While this may be familiar to many of you, EJBCA has ever since version 4.0 supported full uptime during upgrades for clustered installations. What this means is that we pledge that a clustered installation can continue to sign certificates, issue CRLs and answer OCSP queries during the upgrade process with no noticeable downtime for the end user. 

            This is why the upgrade process you may be familiar with is split up into two steps: upgrade and post-upgrade. In short, upgrade performs whatever steps may be required for the first node to be upgraded to be able to function once it comes online again, while post-upgrade performs whatever steps that remain (such as clean up) that can only be performed once all nodes are running the latest code. 

            Automatic Upgrade

            When: EJBCA 6.4.0

            Description: Stunningly, prior to EJBCA 6.4.0 we hadn't actually thought of tracking the database version internally, thus requiring our user to manually enter this value. From EJBCA 6.4.0 and later we do in fact track this, doing away with the need to run the upgrade command entirely. Instead, it'll be automatically run from the first node running the upgraded code. 

            post-upgrade from Console

            When: EJBCA 6.8.0

            Description: In a similar vein, as more and more of our customers run EJBCA on the PrimeKey Appliance and thus don't have access to the command line. As of EJBCA 6.8.0 it's been possible to perform post-upgrades from the UI. When a post-upgrade is required, the System Upgrade option will appear in the menu:
            Choosing it will bring you to a screen used to perform the post-upgrade action:


            With this blog post and our latest round of QA, we hope that we've solved all existing upgrade issues, and that we can make running the latest version of EJBCA as easy and manageable as possible.

            Tomas Gustavsson

            Mike Agrenius Kushner
            Product Owner EJBCA

            Thursday, November 23, 2017

            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.