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