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!

Cheers!
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.




Wednesday, May 24, 2017

From PrimeKey Tech Days 2016: How to be ready for tomorrow’s quantum attacks Vladimir Soukharev

By Vladimir Soukharev, Ph.D. Cryptographer at InfoSec Global Group


Wednesday, April 19, 2017

DNS CAA to be Mandatory from September 2017

The Vote

Back in March, the CA/Browser Forum (CABForum) held a vote for Ballot 187 - Make CAA Checking Mandatory. The vote passed with a resounding 19 out of 21 CAs voting 'yes' (one 'no' and one 'abstain') and all three participating browsers in favor [1]. The practical result of this is that starting September 8th of 2017 it will become mandatory for CAs to consult CAA records before issuing certificates. [2]

The Current State of the PKI Ecosystem  

A commonly lifted obstacle in PKI infrastructure is the issue of the Web of Trust. Through the years we've seen on several occasions how that trust can be violated, i.e when a CA goes rogue, becomes compromised, or fails to follow its own regulations. This was illustrated back in 2011 by the infamous breaches of the Comodo and DigiNotar certificate authorities where both CAs issued wildcard certificates for several high profile domains, or just this year when Google Chrome downgraded certificates issued by Symantec due them to issuing test certificates to Google domains without Google's knowledge. [3]

Several combined efforts have been made to solve the inherent vulnerabilities to this system. So far, no single solution is all encompassing, and even the overlap of every solution proposed doesn't create a foolproof system. Certificate Transparency [4] is one such effort, and has been been supported by EJBCA Enterprise since EJBCA 6.0.4, released in early 2014. [5]

So what is DNS CAA?

DNS Certificate Authority Authorization is defined in RFC 6488 [6] and defines a requirement for CAs to make a pre-issuance check, according to the certificate policy set, with a record stored at the DNS of the affected domain. Any CA without authorization from the DNS will be warned not to issue a certificate. 

Essentially, it allows the end client to restrict which CA's they consider trustworthy, and since the vote at CABForum, this implies any CA not enforcing CAA. While this does not guard against CAs going rogue (by ignoring CAA), it allows domain owners to restrict issuance to CAs whose security and policies they trust, and to exclude less trustworthy (but still CAA enforcing) CAs from the web of trust. 

How does this affect EJBCA?

Here at PrimeKey we more than welcome any efforts to improve the state of the PKI ecosystem, so naturally we were delighted to see the results of the vote at CABForum. While CAA hasn't been a priority for us until now (due to little demand), we've moved up our roadmap. Thus we've slated CAA for EJBCA 6.9.0, which will be released to by August 4th 2017, a month before CAA becomes mandatory. CAA will be an Enterprise feature only

On behalf of the EJBCA Development Team, 
Mike Agrenius Kushner,
Product Owner EJBCA

[1] https://cabforum.org/pipermail/public/2017-March/009988.html
[2] https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/
[3] https://arstechnica.com/security/2017/03/google-takes-symantec-to-the-woodshed-for-mis-issuing-30000-https-certs/
[4] https://www.certificate-transparency.org/
[5] http://blog.ejbca.org/2014/06/certificate-transparency-with-ejbca.html
[6] https://tools.ietf.org/html/rfc6844