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. 


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!

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!

Mike Agrenius Kushner,
Product Owner EJBCA