Saturday, July 15, 2017

Introducing the EJBCA RA, Part 2.2: Migrating from the Public Web (continued)

Hey folks, and welcome back. The last post was dragging on a bit, so I decided at the last minute to split it up. This post will cover the rest of the RA (as implemented in EJBCA 6.8.0) before I get into a bit more technical and architectural stuff in the next post(s).

So, sit back and enjoy the continuation of the tour.

Request Management/Approvals

A big part of being an RA is naturally approving requests. To begin with, let's take a look at the Manage Requests screen. You'll notice four tabs:

  • To Approve - a list of all requests that you as a logged in administrator may approve or deny
  • Pending Approval - a list of all currently pending requests to which you have view access, including those that you may approve yourself. 
  • Processed - a list of past requests to which you have view access.
  • Custom Search - a standard search screen, allowing you to filter and search through all requests to which you have view access. 
So let's return to the scion of the Widget fortune and our example from the last blog post, Alan Widget and his quest for certificates. So you'll remember that his enrollment request was sent of for approval? Well, over on their end the ever friendly neighborly RA administrator was on the case. Receiving an e-mail notification about Alan's request, they log in to the RA and check the To Approve-tab.

As expected, here we see Alan's request waiting for review. Clicking on the Review-link, the administrator is shown all pertinent information having to due with Alan's request.

We could mention here that we've only set up a simple cumulative approval profile for this action for the sake of simplicity. We could have also used the more complex partitioned profiles which were introduced in EJBCA 6.6.0, but I'll probably write a bit more about those in a future blog post.

You'll notice that there is an edit button at the bottom of the screen, which allows the administrator to edit some information in Alan's request. Doing so would invalidate the administrator as an approver though, as they would be considered party to the request itself. Instead they choose to approve, which changes the request's status to Executed, will send a notification mail off to Alan and allow him to retrieve his certificate.

Heading over to the Processed-tab, the administrator can now see Alan's request listed, and likewise under the Custom Search-tab.


Search Functions

That ends the final epic saga of Alan Widget and his quest for certificates, so we'll move on to the remaining pages on the RA interface in EJBCA 6.8.0. Clicking on the Search option in the top menu reveals two choices: Certificates and End Entities




Certificate Search

Being able to search for certificates is a brand new feature in EJBCA, and is only implemented in the RA interface. It provides options for searching for partial matches against Subject DN, SAN, username or against the full serial number. Certificates can also be filtered by end entity profile, certificate profile, issuer and status. 

Extra search options include specifying more results to be shown per screen and mechanisms for searching for more precise issuance, expiry and revocation dates. Note that result size is restricted to avoid murdering the database. I would also like to point out that the listed certificates will be restricted to those CA to which the RA is authorized to. 

End Entity Search

The End Entity search is gives roughly the same options as the certificate search screen, and will likely feel familiar to those of you used to the End Entity search screen from the CA interface. 

CA/CRL Overview 

The CA Certificates and CRL screen remains largely unchanged from the public web.

Notice from the screenshot that the WidgetCorp SubCA is slightly indented to show that it's subservient to the WidgetCorp Root CA

Role Management

The last screen to review is the Role Management screen, which was first introduced in EJBCA 6.8.0. Clicking on the menu will show two options: Roles and Role Members. 



At this point you may be wondering why we've moved roles management out into the RA interface, when there is an excellent (well, more or less) equivalent already written in the CA interface? Well, for many use cases this won't make much sense, in particular when CA and RA are on the same machine. It starts getting interesting when the CA is located in a secure environment, using one or many RAs placed in the DMZ to communicate. As these would by bare minimum be physically separated and in different security zones, this allows senior RA administrators some freedom to administrate their own personell, without being forced to enter the CA security zone. This functionality becomes even more pertinent when CA and RA are physically separated, or not even being operated by the same business entities. 

Roles

The roles screen will display a table of all roles to which the current administrator and RA are authorized to see, sorted by name and namespace. The standard options for editing, deleting and cloning roles exist, as well as for creating roles and reviewing role members. 

If we click on Create New Role will bring us to the following screen, which will be similar for editing or cloning. 

Notice that what you see is a simplified rules management screen, restricted to only RA functions and access to Certificate Authorities and End Entity Profiles.

Role Members

Had we instead clicked on the Members link in the previous table, we would have ended up in the same screen as the Role Members menu option. Displayed is a table of all available role members which this RA and administrator is authorized to view, which can be further narrowed down by identifier (common name, certificate serial number, etc), role or CA. 

Choosing to add a role member will lead us on to a familiar screen where we can specify role for the member, what CA has issued the certificate for that member and by what means we identify that certificate. There is also a field for making remarks pertaining to that member.

That brings us to the end of our tour for the EJBCA RA as implemented in EJBCA 6.8.0. I hope that you've learnt something, and you'll join me in future blog posts as we add and modify functionality. We're not done yet though! Fact is that the EJBCA RA is not only a fancy new user interface, but part of a brand spanking new feature: for EJBCA Enterprise customers an instance of EJBCA can be set up to act as a synchronous external RA for another EJBCA instance acting as CA, communicating securely using EJBCA Peers, even through a one-way firewall. 

Will we introduced this functionality back in EJBCA 6.6.0, in the next blog post I'm going to explain how such a setup would look like on an architectural level, and provide an easy walkthrough for how to set it up!

Cheers!
Mike Agrenius Kushner
Product Owner EJBCA

Monday, July 3, 2017

Introducing the EJBCA RA, Part 2.1: Migrating from the Public Web

As mentioned in the previous blog entry on this subject, one of our end goals with the RA is that it will replace what is currently known as the Public Web. As a result, its final demise is in the works (expect it for EJBCA 7.0), and so I'd like to guide you on how to migrate from using the current Public Web to the RA, as well as give a detailed tour of the entire RA web.

Certificate and Key Store Creation, and Registration

The biggest change to the current process is in the context of certificate and key store creation, as well as end entity self registration, which we've chose to collect under a common workflow. As a reminder, here is the current menu in the Public Web (as of EJBCA 6.8.0):
Nearly this entire menu has been replaced by the top option in the Enroll-menu in the RA, as can be seen below:


So What's Missing?

To just get that out of the way, the only part of the Public Web which hasn't yet been implemented in the RA is the ability to request certificate renewal, i.e. the Renew Browser Certificate option in the first screenshot. 

Registering a new End Entity 

The main procedural change is that self registration (Register -> Request Registration in the Public Web) is now the default first step in either creating a certificate or requesting a key store. Using the old Public Web, the first step in either case is to go to the Administration Web and creating a new end entity, a process I'm sure that you're more than familiar with:

Going instead to the RA and clicking Enroll -> Make New Request brings up the following screen:

As you see, we're first asked to input a Certificate Type, which is analogue to the End Entity Profile concept in the EJBCA Administrative web. I'd like to point out that only WidgetCorp's profiles are visible on the RA, due to this being a dedicated RA for WidgetCorp, even though several other end customers share the same CA, but more on that later. 

For this example WidgetCorp's employee Alan Widget (sadly, well designed PKI is not a cure for nepotism) needs to enroll for a P12 for his personal use. As a trusted employee (and for the sake of example), he has access to an RA terminal where he's free to select any certificate type allotted to WidgetCorp. He'll select the WidgetCorp User type, which gives him a choice of Certificate Subtypes.

Selecting the End User Certificate subtype, he'll next be given a choice of where to generate the key pair:

 In this case Alan requires a soft signed key pair produced by the server, so he'll select the top option. We'll talk more about the second option in a moment.
 Next the RA will provide Alan with a choice of key algorithms as defined by the Certificate Profile/Certificate Subtype.
Lastly, he'll be asked to provide whatever values that must or could go into the distinguished name of his certificate. Notice that mandatory values are marked by an asterisk, while values defined in the End Entity Profile/Certificate Type are filled in and unchangeable. Lastly he'll be asked to provide a username and enrollment code, as well as his e-mail. The username/enrollment code can be used to retrieve the finished certificate at a later date (using the Use Username option in the menu above), and the enrollment code will also be used as a passphrase if a key store is desired as the end result. Lastly, a field for an e-mail address is provided so that Alan can be notified once his key store is ready for retrieval.

Finally Alan is given a chance to review the contents of his request before confirming and sending it off:

Alan's request is sent off for approval by a higher level admin, and Alan has been left with a request ID. 
We'll talk about the approvals process in the RA in a later blog post, so for now we'll stick with Alan. Once his request has been approved, he'll receive an e-mail telling him that he can return with either his username/password or his request ID, using the Use Request ID option in the Enroll menu.

Entering his request ID, he moves on to the final screen, where he's asked to input his passphrase to authenticate himself. Lastly he simply has to choose how his wants his key store delivered (as permitted in the Certificate Profile). 

Creating a New Certificate

So, how is the procedure different if all we need is a certificate? Well, Alan's first task at the job is to set up a new VA for WidgetCorp's SubCA. He's set up the machine and generated the signing keys, so he needs to get them signed. As it happens we've already defined the WidgetCorp M2M Certificate end entity profile for just this purpose, so we'll choose that from the dropdown, and then the OCSP Signer subtype. 


You'll notice he's never given a choice of where to generate the keys, as the OCSP Signer certificate subtype specifies that they be user generated only. Alan is instead encouraged to upload or paste his CSR.
Doing so will fill in any data already defined in the CSR such as key algorithm and DN values, and all he has to do now is submit the signing request for approval.

The astute of you will notice one feature missing in the current Public Web, which is letting the browser generate its own key pair. We have chosen to not implement this feature because it's already been dropped by Chrome, and it's on its way out in FireFox as well.

This blog post has gone on long enough for now, so we'll cut it here and continue with the rest of the RA interface in a few days time, so please check back then!

Cheers!
Mike Agrenius Kushner,
Product Owner EJBCA

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.

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

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