Monday, June 26, 2017

Introducing the EJBCA RA, Part 1: Introduction

Where we are now

One the primary complaints we here at PrimeKey get about EJBCA is about the design of our interface, or rather the lack of thereof. We've come a long way from being a tiny open source project to being one of the primary PKI software vendors globally, so while we maintain our dedication to delivering a powerful and secure product, it's time for us to give our users a bit of a break.

The Public Web 

A major feature EJBCA has always been lacking is a dedicated RA. The Public Web, while basically functional, is merely a rudimental interface for performing RA functions, one which only works locally, needs to be used in conjunction with the CA web, and is not in a state that can be considered deployable to the end user.

Many of you reading this have in all likelihood designed your own personal RA using CMP, SCEP or our WebService interface, which brings us to our next topic. Most CA installations are understandably hesitant to expose their CAs to the wild in order to interact with an RA, but instead protect it using a firewall. Currently we provide the standalone ExternalRA, an asynchronous proxy meant to reside outside the firewall, restricted to only being polled by the RA.

What is in store

Those of you familiar with EJBCA Enterprise will hopefully be a bit familiar with the EJBCA's RA Web. We released it back in EJBCA 6.6.0, and with the refinements being done in EJBCA 6.8.0 and beyond.

The EJBCA RA in EJBCA 6.7.0
The RA is the herald of the end of the Public Web and of ExternalRA. By the end of this year we will be discontinuing these two modules and removing them. So what does this mean to you? Well, quite a bit, and all of it good. The RA is in fact designed to completely supersede the Public Web, while providing quite a bit more functionality and improved design, aside from being a whole lot prettier.

Not only that, but by using the Peers protocol introduced in EJBCA 6.3.0, one instance of EJBCA can be set up in the DMZ as a proxy to another acting as CA within the confines of the firewall, responding to synchronous polling from the CA and communicating over TLS instead through database polling.

That's it for now, but follow us for an additional couple of blog posts. Part 2 will take a close look at the EJBCA RA and how to transition to it from using the Public Web, while Part 3 will talk about setting up an RA Proxy, as well as discuss some future ideas for the RA.

Mike Agrenius Kushner,
Product Owner EJBCA

Friday, June 9, 2017

A Sneak Peak into EJBCA 6.8.0: Roles, Rule and RA

So we're finally coming into the last sprints of the current release, testing and fixing bugs as we go. We're expecting the final drop of EJBCA 6.8.0 in the end of June, but in the meanwhile I'd like to talk about and demonstrate some of the new features we've implemented.

Improvements to Roles and Rules

So I know firsthand that one of the more complex and confusing aspects of administrating EJBCA are the roles and rules system. While we're not quite so brave as to redesign the rules system entirely, we've taken several steps to simplify rules administration, and make the capabilities of each role clearer. 

Simplified Rule Administration

You're probably all familiar with the current look and feel of the rules page:

In 6.8.0 we've made some simple improvements which we very much hope will improve usability. From now on, the same page will look like this:

I would like to draw your attention to several features:

  • We've removed the Unused-state and the Recursive-cbeckbox and replaced them both with the Inherit-state. It simply means to inherit whatever rights were set further up the tree (in the above example, setting Allow to /ca_functionality will give access to /ca_functionality/activate_ca and all other subsequent rules, unless they've been specifically set to Deny
  • In order to simplify overview, we made a conscious choice to go from drop-downs to radio buttons, as well as differentiating between leaf rules and branches by color. 
  • Rules are automatically normalized, which means that when saved the rule-set will automatically be minimized to its smallest possible size. Rules which are invalid or redundant are automatically culled. 

Rule Summary

If you check out the top right, a new meny option has been added to the navigation menu:
Clicking on it will bring up a summary of the active rule set for the role (after normalization, see above).

Role Namespaces

We've recognized that there may be many disjunct groups of users administrating EJBCA, all of which may not need to know of each other. In order to minimize confusion in naming Roles, we've added the concept of namespaces.
Belonging to a role in blank namespace (to which the Super Administrator Role belongs) gives access to all namespaces, while all other roles will only see the namespaces to which they themselves belong. In other words, an administrator belonging to WidgetCorp's namespace will only see the WidgetCorp roles. In addition to that, if the administrator only belongs to a single namespace, then the whole column will be hidden and they will never be aware of any other roles at all. 

Roles in the RA

We hope that you've all been following the exciting new development that came in version 6.6 last year, our very own proxyable RA! In EJBCA 6.8.0 we've also extended roles and rules administration to the RA, allowing end users on a proxied RA to manage their own users and rights without needing to access the CA.

CMP Proxy and Windows AutoEnroll Proxy

We're slowly migrating away from the legacy ExternalRA, as well as the CMP and SCEP Proxies. The reasoning behind and advantages to this will be explained in future blog posts, but for now I'd like to let you know about two new features we've introduced in 6.8.0. If an installation of EJBCA has been set up as an RA for a CA installation, it can now proxy both CMP messages and the Windows AutoEnroll feature we introduced in EJBCA 6.7. No special configuration is needed: simply send the messages to the RA as usual, and if it has contact with a CA it will automatically pass the messages on. 

Approval Profiles

Lastly, we decided to build a bit upon the concept of Approval Profiles that was introduced in EJBCA 6.6. In previous versions, only a single approval profile could be to cover for all actions for a CA or Certificate Profile.
CA settings

Certificate Profile settings
In EJBCA 6.8 we've somewhat more intuitively made it possible to set a profile per action, meaning that you don't need to have the same approval workflow for adding end entities as for revocations. 
CA settings

Certificate Profile Settings

Now, that's all for now. We're expecting EJBCA 6.8.0 to pass QA and be released by the end of next week, which will be announced through all the usual channels. On behalf of all of us at PrimeKey Solutions I'd like to wish you all an excellent summer, and check back here during the coming weeks for a series of blog posts about our new RA!

Mike Agrenius Kushner
Product Owner EJBCA

Thursday, June 1, 2017

From PrimeKey Tech Days 2016: Certificate Transparency

Ryan Hurst, Product Manager at Google, talks about Certificate Transparency. What are lessons learned and shape of things to come.