EJBCA 6.15.1: Publishers, Publishers, Publishers!

We couldn't stay away, so at the same time as the UI is being refurbished and prepared for our coming Common Criteria certification we've been busy adding some neat new features to EJBCA 6.15: Publishers Galore!

Multi Group Publishing

 In order to facilitate for users administrating large numbers of publishers referenced in multiple certificate profiles, we've implemented the Multi Group Publisher. 

By referencing Multi Group Publishers instead of the affected publishers directly, actions such as adding or removing VAs can quickly permeate throughout all affected certificate profiles. The publisher also allows splitting referenced publishers into groups, which establishes parallel publishing queues. 

SCP Publishing and VA Population

Due to popular demand for an alternative to the Peer Publisher in environments where establishing a Peer Connection between CA and VA isn't an option, we've created the SCP Publisher, which publishes certificates and CRLs to a remote location over SCP.

Conversely, in order to import certificates and CRLs exported by the SCP Publisher a VA, we've implemented the Certificate and CRL Reader Service. 

GDPR Adapted Legacy VA Publisher

Just like we did for the Peer VA Publisher back in EJBCA 6.13, we've GDPR adapted the Legacy VA Publisher.

By enabling the new Don't store certificate meta data option at the bottom, VA publishing can be performed without writing any identifying information to the VA. 

Revocation Time added to CertSafe Publisher

The output of the CertSafe Publisher has been amended to include revocation time. 

Cheers!

Mike Agrenius Kushner

Product Owner, EJBCA

Keep track of certificate issuance using Graylog (and pretty dashboards)

Running an EJBCA based PKI can be a very boring task, usually everything just works. One complaint that we get is that it just works so stably, that the operations staff forgets what to be done when something happens.

Apart from being boring to run, a question that i asked now and then is to get reports or displays of issued certificates, with different flavor sand slices of reporting. As EJBCA is open, you can find all needed information in the database, or in the audit logs. The question is of course how to aggregate information across cluster nodes, and how to process it in a nice way.

One answer to this is to use a central log system, which can process logs from all nodes in a cluster, or even from different segments, like Issuing CAs, OCSP responders, RAs etc.

Using the Open Source Log Collection and Analysis tool Graylog, we can do all this. For those familiar with other similar tools such as Splunk, it works quite similarly, and EJBCA users currently successfully use both Splunk and Graylog in production. Some buzzwords for this are Log Aggregation, Central Log Analysis, SIEM, etc.

So what can it look like?

Example EJBCA Dashbord on Graylog

A Little Background on Logs

An EJBCA PKI system has the following types of logs:

• Security Audit Log: Used for PKI auditors to audit important security PKI events that the system performs.
• System Log: Used to monitor daily operations in the system, debug and track down errors etc.
• Transaction Log: Used for accounting of specific functions, mainly validation (OCSP).

The Security Audit Log constrains greatly what it logs (defined by EJBCA's Security Target), and does not log any other events. Events pertinent to log are ones such as "Certificate issued", "Certificate Profile edited", "Administrator accessed resource", etc. One of the most important aspects to consider is that the Security Audit log does not log things that do not happen. Things that do not happen are for example invalid requests that the system rejects, because the PKI system did not perform any important auditable event.

The System Log, on the other hand, logs all events that are interesting to monitor, such as rejecting invalid requests, reading profiles etc.

Full information of EJBCA logging can be found in the documentation.

Integrating with Graylog

The easiest integration, that I found, was to simply send logs using Syslog from EJBCA to Graylog. Assuming you have EJBCA running, and Graylog running (I used the AWS AMI to get up and running in no-time) it is easy to start sending logs to Graylog.

Configuring Syslog Sending and Receiving

I used Syslog-TCP, which is not enabled by default in Graylog, nor in JBoss/WildFly (where EJBCA runs).

Enabling Syslog TCP Input in Graylog

To enable using syslog TCP input in Graylog, do the following:

1. Go to the Graylog Web Console and select System > Input.
2. Select Syslog TCP in the Select Input list menu and click Launch new input.

Configuring EJBCA Logging

On the EJBCA server, configure JBoss/WildFly to send messages to Graylog with syslog TCP. This is done by adding the following section in the logging subsystem in the JBoss/WildFly standalone.xml:

<custom-handler name="SYSLOGTCP" class="org.jboss.logmanager.handlers.SyslogHandler" module="org.jboss.logmanager">
    <level name="INFO"/>
    <encoding value="ISO-8859-1"/>
    <formatter>
        <pattern-formatter pattern="%-5p [%c] (%t) %s%E%n"/>
    </formatter>
    <properties>
      <property name="appName" value="WildFly"/>
      <property name="facility" value="LOCAL_USE_5"/>
      <property name="serverHostname" value="ec2-52-72-41-146.compute-1.amazonaws.com"/>
      <property name="hostname" value="-"/>
      <property name="port" value="514"/>
      <property name="syslogType" value="RFC5424"/>
      <property name="protocol" value="TCP"/>
      <property name="messageDelimiter" value="-"/>
      <property name="useMessageDelimiter" value="true"/>
    </properties>
</custom-handler>

You also need to configure the root-logger to use the new handler, this will start sending the same logs to syslog. Add the new handler by modifying the root-loggers section in standalone.xml:

<root-logger>
    <level name="INFO"/>
    <handlers>
        <handler name="CONSOLE"/>
        <handler name="FILE"/>
        <handler name="SYSLOGTCP"/>
    </handlers>
</root-logger>

Send some log items by performing an action in the EJBCA Admin UI, for example saving a certificate profile.

Configuring Graylog

Configuring Graylog involves a few tasks:

• Creating Exctractors
• Making some Searches
• Adding searches to a Dashboard

Create Graylog Extractors

Graylog Extractors are used to extract fields, that can be used in queries in Graylog, from the log stream. You can create Extractors for your log input under System > Input in the Graylog Web Console.
You can analyze log items and create the extractors you need. In our example, the following extractors are created:

• RADN: An administrators DN who issued a certificate, for example 'CN=RA Admin,O=PrimeKey,C=SE'
• Extractor type: Split & Index
• Split by: ;
• Target index: 6
• EVENT: The event that happened, for example 'CERT_CREATION'
• Extractor type: Split & Index
• Split by: ;
• Target index: 2
• CERTPROFILE: the certificate profile a certificate was issued for, for example 'certprofile=346136222'
• Extractor type: Split & Index
• Split by: ;
• Target index: 11

You can edit and create extractors of many different types, the above are simple examples.

After the extractors have been created, go to EJBCA and make some actions, to log something you want to visualize. Such as running a stresstest to issue a bunch of certificate, by different RAs.

Add and Visualize Searches on a Dashboard

The following provides examples of search result information that you can add to your dashboard.

Examples of search result information to visualize:

• CERT_CREATION last day
  • Search in the last 1 day
  • EVENT:CERT_CREATION
  • Click Add count to dashboard
• CERT_REVOKED last day
  • Search in the last 1 day
  • EVENT:CERT_REVOKED
  • Click Add count to dashboard
• Certs issued by SuperAdmin all time
  • Search in all messages
  • EVENT:CERT_CREATION AND RADN:CN=SuperAdmin
  • Click Add count to dashboard
• Certs per RA
  • Search in all messages
  • EVENT:CERT_CREATION
  • Select RADN and click to expand, click Quick values, and then Add to dashboard when you see the graph.
• Certs issued per day
  • Search in the last 30 days
  • EVENT:CERT_CREATION
  • Select Day in the Histogram and then click Add to dashboard
• Exceptions last week
• Search in the last 7 days
• Exception
• Select Hour in the Histogram and then click Add to dashboard

You can now go to your dashboard and rearrange the widgets using Unlock/Edit.

Cheers,

Tomas Gustavsson

CTO 

Presenting EJBCA 6.15 and one word: ACME

Version 6 of EJBCA is beginning to near its end, and the team are looking forward with great anticipation to be able to give you all a look at what's coming with EJBCA 7. That said, we're sending off the last feature release of EJBCA 6 with a helluva bang: full support for the ACME REST protocol! 

ACME Protocol Support

Nearly done by the release of 6.14 but not quite there, EJBCA 6.15's main feature is our support for the ACME protocol, up unto and including all mandatory features in draft 12. Naturally we've implemented it with full support for proxying communications over Peers through our RA, and support for multiple configurations using aliases as we do with other protocols.

As it's a commonly asked question, we'd like to state here that our implementation has been verified against Certbot, PJAC and ACME Tiny, and our documentation describes how to configure them.

Wildcards for Custom Certificate Extensions

We've added two minor features to Custom Certificate Extensions: 

Firstly, we've added wildcards (identified by an '*') to the OID field, which allows a defined extension to match against any array of extensions defined in an incoming request (e.g. in the above example, any request containing an extension ending in .123. The second addition is the Required property, which is by default checked. Unchecking this property makes an extension available to be requested in the enrollment request but not necessary. 

Roadmap Update

Development of EJBCA 7.0 is now underway, and while many of you will be pleased at the new Common Criteria certification that's incoming, the initial UI changes won't be monumental at first. This is because most of the work is being done behind the scenes to pay back a monumental technical debt which has been incurred over the years in the UI module, and in order to maintain stability while the UI is being worked on we're making the changes as slow and gradual as possible. 

From The Oatmeal

What you'll be seeing next over the coming months will first be a normalization of UI functionality (making sure that similar actions across different pages behave in the same way), followed by a massive renovation of our CSS. After that we'll progressively start introducing more tangible improvements to the UI. 

Upgrade Information

Read the EJBCA 6.15 Upgrade Notes for important information about this release. For upgrade instructions and information on upgrade paths, see Upgrading EJBCA.

Minor Release: EJBCA 6.14.1

Hi folks, we'd like to send the summer off with a minor release based the latest version of EJBCA: 6.14.1

This minor primarily fixes some issues that some users reported when running EJBCA 6.14 on JBoss 7.1.1GA, due to some race conditions and library collisions in that particular version that didn't come up during testing. We also took the chance to fix some other minor issues that came up late during QA that we believe should hold you over for the time being. For a full list of new features and implemented improvements in EJBCA 6.14, see the EJBCA 6.14 Release Notes.

In other news, we've decided to release our ACME implementation before moving on to EJBCA 7.0, so you can look forward to seeing EJBCA 6.15 in the next few weeks. 

This minor release does not involve any upgrade steps or notable database changes. Read the EJBCA 6.14 Upgrade Notes for important information about the release. For upgrade instructions and information on upgrade paths, see Upgrading EJBCA.

Presenting EJBCA 6.14: A Plethora of Protocols

It's with no small amount of pride that we'd like to announce the release of EJBCA 6.14, one of the most feature rich releases to come out in a long while. Let's get straight to it, because we have quite a bit to discuss. 

New Features

EJBCA 6.14 introduces a ton of long awaited functionality primarily centered around protocols, to supplant our already extensive support for SCEP, CMP, EST and our homegrown WS API. 

The Certificate Management REST API

A long requested and requested feature is for EJBCA to support a spick and span new REST API, and EJBCA 6.14 introduces the first iteration of our Certificate Management REST Interface. 

Screenshot of the offline API documentation

So far we've only implemented basic certificate management methods, and we'll be slowly moving on with implementing more powerful features in the near future. 

You'll find the complete offline API as a part of our documentation here, or deployed locally with your EJBCA installation. For those of you wishing to integrate with EJBCA using REST we deploy Swagger on non-production installations in order to expose the API. Just like with all new protocols added to EJBCA, the REST API is disabled by default and needs to be manually activated. 

Sceenshot from the online Swagger UI

Complete Proxification of the EJBCA Web Services API 

A huge milestone for the EJBCA, we put in a huge effort into providing proxification for nearly all EJBCA WS calls. This means that CAs relying on communication with 3rd party applications can now be placed behind an outgoing-only firewall, with communications being relayed through an EJBCA RA. 

Roadmap Update

We're now looking forward to Q3 and EJBCA 7.0, which will be our next Common Criteria candidate. In doing so our goal is to make the complete technology leap from JSP to JSF in our CA UI, a first step to greatly improving the usability of EJBCA. Be also aware that EJBCA 7.0 will drop support for JDK7, so if you haven't upgraded to JDK8 or later yet we strongly recommend doing so. EJBCA 7.0 will also hopefully provide full support for the ACME protocol. 

Cheers!

Mike Agrenius Kushner

Product Owner, EJBCA

From PrimeKey Tech Days 2017: EST Update

Next up in PrimeKey's series of Tech Days videos is Michael Luken from Cisco who spoke about the EST Protocol, which has been supported by EJBCA ever since version EJBCA 6.11.0. Make sure also to check out this excellent guide to setting up EST written by Tomas a few weeks ago.

Too see many more lecture like this, come and visit us this fall.

EJBCA and Agile PKI

So in case anybody is wondering what the buzzword for 2018 is, it's quite obviously Post Quantum Cryptography. Besides full and entire conferences on the subject, large tracts of security conferences such as RSA and ICMC have been dedicated to it this year, not to mention a plethora of blog posts on other security and product blogs with similar titles to this one.

Anybody looking for a business idea? Harness the buzz of the last five years by implementing Silo Breaking Post Quantum Blockchain Microservices in the Cloud As A Service. No need to thank me, just remember where you heard it first.

No, but seriously...

In spite of the buzz though, Agile PKI is a thing, and a thing we should be taking very seriously.  There are several reasons why we should be honing in on this matter more than we are:

• Everybody is talking algorithms and variants. While those discussions are interesting in themselves, unless we have a method to perform a world wide catastrophic migration then the discussion is moot. 
• Quantum computers are far from the only threat to the PKI infrastructure:
•  MD5 and SHA1 were at the time believed to be cryptographically sound, until the day they were proven not to be. How long will we be able to trust SHA2, even without passing the quantum singularity?
• There may be flaws (and by that I mean that there are, just that they haven't been disclosed or found yet) in the implementations, Heartbleed and ROCA typically come to mind.  
• PKI infrastructures may be knocked out through human mishandling, requiring mass migrations between CAs. 

Where are we now?

Depending on your outlook, developments in Quantum Computing are either progressing at a snail's or at a monster pace. To compare, in the 90s a qubit was still a relatively theoretical concept, while during the early 2000s large strides were made in small scale computations. In 2001 the number 15 was successfully factored using Shor's algorithm, and it took until 2012 to factor the then record number of 143, during which it was proven two years later that 56153 had been factored during the same computation. The currently largest known quantum computer is Google's Bristlecone, which has a whopping 72 qubits. So, have we passed the quantum singularity? Well, not quite. 

Image courtesy of the Google Quantum AI Lab.

In the above graph, the white line between the purple and blue fields is what's called "quantum supremacy", and is the threshold where a quantum computer solves a problem faster than its digital counterpart. The jury is mostly out on whether we've passed that level or not, but what is undebatable is that we are still very far from a workable quantum computer of millions or tens of millions of qubits working on concert. The term Error Correction Threshold refers to the fact that quantum computations are probabilistic, that while they are more likely to end up at the correct result, they are not guaranteed go, and all derived answers must be verifiable. 

It's also not a clear question of when:

• qubits are fickle things, and as a quantum computer is only usable while all its qubits are part of a single coherent field. The more qubits added and the longer the computation, the larger the chance is that coherence is broken before the computation has finished. 
• adding in more qubits is not trivial (as the meager gains of the last 20 years have shown), and moving from <100 qubits to millions requires passing several engineering challenges which haven't yet been met. 

So what's the hurry?

As mentioned above, the are plenty of reasons to be pursuing PKI agility that aren't part of sci-fi scenarios, but with regards to quantum computing there is good cause to start getting organized. As a reference, ETSI have published an IPR pertaining to post quantum computing, in which they declare the following doomsday equation:

• X = the number of years the public-key cryptography needs to remain unbroken. 
• Y = the number of years it will take to replace the current system with one that is quantum-safe. 
• Z = the number of years it will take to break the current tools, using quantum computers or other means. 
• T = the number of years it will take to develop trust in quantum-safe algorithms.

Where a state of X + Y + T > Z implies that everything has gone pear-shaped. I've taken the liberty to translate this into PKI friendly terms, where:

• X = the longest validity of a certificate issued today in a PKI. Unless actively threatened, end users are extremely unlikely to migrate their certificates to agile variants when prompted. Even then, look at how prolific Triple-DES and SHA1 (and dare I say it, even MD5) still are. DV/EV certificates can have a validity of as long as two years, but many intermediate and root CAs have validities of 5-10 years, as do many eID and passport certificates. 
• Y = the number of years it takes to establish an Agile PKI standard and implement that standard universally. Off the top of my head, I would say that this would take 1-3 years from inception to complete rollout. 
• Z = the number of years until a quantum computer can solve factorization/discrete logarithm problems + computation time. The lowest estimate I've heard for this is 4 years (though unlikely) while there still are theories that quantum computing is unfeasible. Counting on the q-bomb being dropped within 10-20 years is not unrealistic though.
• T = the number of years it will take for a PQ algorithm to be adopted. Certifying organizations such as NIST are notoriously slow in adopting new standards, and even though the PQ algorithm competitions are in full swing, we are still 3-4 years from having at least one algorithm be considered trusted. A worst case scenario is that this could take up to 20 years though.

So the main factor that PrimeKey as a software developer is Y, to encourage the adoption of open Agile PKI standards, to implement those standards and encourage the rollout of agile systems.

So where do we go from here?

From our point of view which algorithm is chosen by the certifying bodies doesn't matter greatly, though some are by their very nature inappropriate for PKI use due to statefulness or egregious key sizes. If you're interested in reading more about what implementations that currently exist and how the behave when implemented in EJBCA, you're welcome to read the very excellent thesis which was hosted by PrimeKey last year.

Ragnarök

Our Requirements

From out point of view, our requirements for an Agile PKI implementation is that:

1. all issued non-PQ certificates for our customer PKI’s must be able to safely and instantly migrate to post-quantum certificates, or already be in possesion of one.
2. all issued non-PQ keys (for PKIs using client side authentication) must have a migration strategy to equivalent post-quantum key pairs 

There are currently two end transitions described, the first of which is described in this paper hosted by IACR:

Hybrid Certificates

This is the most straight forward idea and simplest to understand, and simply means rewriting RFC5280 to include a second tbsCertificate within the certificate body.

While conceptually simple, this approach is very unattractive from our point of view. Besides requiring a huge rewrite of existing RFCs, it also poses the challenge of how to declare a tbsCertificate load in a certificate as non-critical (or face backwards compatibility issues). 

Post Quantum Certificate Extensions

This solution exists in two variants, and is proposed in this draft written by our friends at Entrust, ISARA and Cisco. This solution proposes instead to create an intermediate certificate by adding post quantum elements as part of non-critical extensions, either the full tbsCertificate or just partial elements (public key/signature).

This approach is far more flexible, as it allows for full backwards compatibility, even allowing for cross-signing by several PQ keys in the same certificate in case there are trust issues prior to rollout. 

Both of these variants suffer from the same problem, which is potentially widely inflated certificate sizes depending on what algorithm is chosen  as XMSS, SPHINCS and similar hash-based algorithms can have very large public keys. 

In summary, what does the future bring?

If one only knew, right? In terms of just Agile PKI I believe that it's on the near horizon, both for the post-quantum use case and because there is a general use to codifying the general functionality. 

What a post-quantum world will look like I can only speculate. Based on current progress, I don't believe that private quantum computing will turn up overnight but rather be a very gradual progress a qubit clusters grow in scale and hurdles of size and coherence are gradually overcome, though there could well be sudden breakthroughs that proves this wrong. 

We also only know about private research in the matter. The 2014 Snowden Files showed that the NSA does have an interest in quantum computing, but it's pure speculation how much progress they or any other intelligence organization have made, if any at all. Should a breakthrough be made it's unlikely to be announced matter-of-factly as possession of such capabilities is best used in secret. A sudden announcement would cause a catastrophic breakdown in trade and infrastructure, so is unlikely.  The NSA also has a mandate to secure domestic communication, so long before a quantum breakthrough, no matter how secret, we will see US communications policies deprecate RSA and EC for commercial use. 

From our end, our aim is to continue researching the subject and try to proactively encourage all PKI using bodies to adopt PKI Agile methods within the next few years.

Cheers
Mike Agrenius Kushner
Product Owner EJBCA

From PrimeKey Tech Days 2017: Creating a Trust Center is not your Panacea

It's that time of year again, and we've begun releasing the lectures from last year's PrimeKey Tech Days conference. First up is a good friend of ours and one of the most knowledgeable guys in the business, Scott Rea from Dark Matter:

If you haven't considered visiting Tech Days, I'd very much recommend that you do so. It's a cryptography conference for geeks and by geeks, and we invite the speakers that we ourselves want to listen to. Come to Stockholm this September and join us!

EST for Certificate Enrollment

There are multiple protocols available to enroll for certificates from a CA. Some are standardized and some are proprietary.
The most popular standardized ones are SCEP, CMP and EST. SCEP has been around since 2000 and show severa ageing issues, most notably the lack of ability to work with EC keys in a usable matter.
CMP has been around since 2005, is multi functional and handles both RSA and EC keys well. It's a true Swiss knife of PKI enrollment protocols. Being so functional is also it largest criticism, being advanced also becomes complex. CMP works well for a large number of uses cases and we have discussed some of them here and here.
The new kid on the block is EST, which in 2013. EST re-uses other standards such as TLS to try to make it easier to use while at the same time providing much functionality. EJBCA Enterprise has implemented EST since EJBCA 6.11 and it can be used for efficient certificate enrollment from a management system (mobile device management, token management system, IoT platform, etc), using both RSA and EC keys. The management system acts as a Registration Authority (RA) in PKI terminology and this is the notation we'll use throughout.

A typical use case for certificate enrollment is to have an RA that handles initial enrollment for users, mobiles or devices. After initial enrollment (provisioning) the device can automatically re-enroll for updated certificates as long as it still have a valid certificate.

We'll walk through this use case, using EJBCA as the CA server supporting EST, and the open source Cisco EST Client. In order to use EST an EST Alias must be configured in EJBCA, as described in the EST documentation.

Adding an EST Alias

Configuring an EST alias is easily done in the EJBCA Admin UI in the EST Configuration section.

Using EST Client

Before doing any enrollment the RA can fetch the latest CA certificate from EJBCA.

estclient -g -s 127.0.0.1 -p 8442 -o certs --pem-output

After a device has been approved by the RA, the RA can get a certificate for the device from the CA.

estclient -e -s 127.0.0.1 -p 8442 -o certs -u estadmin -h foo123 --pem-output --common-name myclient

In this case the RA i authenticates to the CA using a username (estadmin) and a password (foo123). The RA can also use client certificate authentication instead of username/password.
The issued client certificate will contain the distinguished name (subjectDN) "CN=myclient". This command will automatically generate an RA key for the client.

The device can automatically re-enroll for a new certificate, authenticating itself using the private key and certificate it received from the RA.

estclient -r -s 127.0.0.1 -p 8443 -o certs -c certs/cert-0-0.pem -k certs/key-x-x.pem --pem-output

If an EC key is desired instead of RSA, this key must first be generated before enrolling for the certificate.

openssl ecparam -name prime256v1 -genkey -noout -out prime256v1-key.pem
estclient -e -s 127.0.0.1 -p 8442 -o certs -u estadmin -h foo123 --pem-output --common-name myclient -x prime256v1-key.pem

The corresponding re-enrollment command is.

estclient -r -s 127.0.0.1 -p 8443 -o certs -c certs/cert-0-0.pem -k prime256v1-key.pem --pem-output -x prime256v1-key.pem

This command re-enrolls using the same key as used in the initial certificate, but a new key can equally well be generated, which is in general the prefferred option.

Re-using keys for subsequent re-enrollment can be prohibited in EJBCA by a configuration in the EST Alias.

Roadmap: Rethinking our UI

A common point of pain for anybody who has ever tried to interface with EJBCA is the UI.  It stinks like something died, got eaten by something else which then in turn also died but did so after eating a pair of old sneakers and then not being found for two weeks. We know. 

It's a problem which we've been trying to fix for something like the last decade, but in my entire career legacy UIs seem to be the most common technical debt issue that software companies have. I've seen it happen before, and PrimeKey has also tried rewriting our UI from scratch at least once; it always fails for many of the common reasons. Joel Spolsky wrote an article nearly 20 years ago (which I first read something like 10 years ago) describing why redoing your UI from scratch is a bad idea, and what he says mostly rings true.

The Problem(s)

Why change something that works? Well, when designing an interface the concept of quality comes to mind. EJBCA obviously does most of what is required of it - its extensive use out in the wild wouldn't be possible otherwise. The support questions and the frustrations of both our customers and our own staff witness to the fact that much remains to be done though. Looking fairly objectively at the CA UI (still titled the Admin UI), it reflects several issues:

It Was Designed a Long Time Ago

EJBCA has been alive and kicking since 2001, which of course means eons in internet time. Not that frames were a modern concept even then (and hey, we kicked ours last year!), but it's from a day that preceded widespread adoption of proper MVC design, and the existence of fancy javascript libraries. As a consequence...

It Doesn't follow Consistent MVC Design 

Through the years we've put a lot of effort into moving functionality to where it belongs  - moving down logic into the business beans and caching into the session beans from the UI layer (in some cases even inlined in the UI code) while moving up formatting instructions into the MBeans of the view layer - much still remains though. An added difficulty is the fact that...

Large Parts are Still in Ancient JSP

I know, JSF is hardly bleeding edge technology, but that's what we're aiming for at this point. The fact that we have a UI written in two different coding schemes with three different styles make all and any usability changes hell to try to implement. Trying to rewrite the UI to something more modern is difficult because...

It Does a Lot

From Hyperbole and a Half

This is where previous efforts have always failed, as such efforts have in so many software projects. We've made attempts in the past (though only one properly in earnest) of rewriting the UI, and they've simply failed due to the lead times being so great that there has never been a way of updating the spec at the same rate as development, and this is just what we're adding as the tiny development team we are. The huge amount of functionality in EJBCA is one of its greatest strengths, but it adds a huge amount of inertia to any major changes - not only can't we lose features, our huge feature set also adds a risk of causing regressions; these may be anything from annoying to fatal for our users. The other problem about our huge feature set is that a lot of it is quite obscure because...

Our UI is Designed By Developers

Our UI really does cover everything - the problem is that we're a bunch of developers who have designed it. If you want to have a deep understanding for how EJBCA's data model looks like the UI is really a great guide, because it mirrors it exactly. Honestly, do you as a user care what an Internal Key Binding is? Why does setting up a Peer require background knowledge of TLS to be comprehensible? Why are both of these required when setting up a remote VA Responder, and why is that option nowhere in the menu? 

We have a long way to go in usability. 

Where We Want to Go

Does that mean that we've given up? Nope, not in the least. Divide and conquer is a heuristic that never goes out of style, and the RA Web we introduced back in 2016 takes care of some of those concerns. In addition to all the other advantages provided by having a separate RA, it also allowed us to move some functionality from the CA Web into the RA Web. As stated in the last roadmap update, most functionality which is today duplicated between the two interfaces will soon be officially deprecated, then unlinked, then finally deleted. 

Technology Update 

Our goal is to move the entirety of the CA Web to JSF in XHTML. While well aware of the fact that there are tons of neat noun.js javascript libraries out there, due to the business we're in we want as much as possible to avoid dependencies linked to specific corporations, and shy very much away from non-FOSS libraries. JSF does what we need, and there is little risk of it being abandoned. Once there we're at a far better place - changes no longer need to be made in two languages, we can have far more code in common, we're working in an environment which is far less painful. 

This is the first part of our UI project, is currently ongoing, and is slated to be complete by the beginning of Q4 of this year (in parallel with other development). We will be avoiding usability changes as much as possible in order to make keep the usability delta minimal, thus making life easier for our QA staff. 

Layout Update

The next step will be moving the entire layout of the UI to the CSS files, much like the RA Web. 

This not only allows us to be entirely flexible with the layout (you do know you can customize the RA Web as much as you like, right?) but also work with several designs at once, being able to provide both a "legacy" layout and to work on something brand new. 

Customizable stylesheets for the RA web. 

Usability Normalization

EJBCA currently badly lacks consistency - similar functions have been developed by different developers at different periods in different technologies. There are very few unified ways of perform an action, and the learning curve for using our UI is very low as a result. Having normalized technology and layout, our next avenue is to give our design a single voice, a feel. 

Workflow Based Design

Ah, the holy grail - we're I've dreamt about ending up for years. 

Gone will be all connections between data models and frontend, remaining will be an interface based on what you as users actually wish to accomplish within PKI. We have some exciting times ahead.

Cheers,

Mike Agrenius Kushner

Product Owner, EJBCA

EJBCA 6.13.0 - Our VA is GDPR Ready!

What now, another feature release so soon? Fear not, all is well  - instead we felt that some of the work we've put in to the trunk should be made available as soon as possible. We hope that as many of you as possible have had a chance to check out the ConfigDump tool we released with EJBCA 6.12, please give us any available feedback that we can plug in to future versions.

Adapting the VA to GDPR

We've added an option to the VA Peer Publisher to restrict publishing identifying certificate metadata from the CA to VA, such as subject DN, SAN or usernames. 

 Key Ceremony Utilities added to the RA Web

During key ceremonies, auditors typically require a copy of all CA Certificate fingerprints. To spare you the process of downloading CA certificates and computing the fingerprints manually using a third-party tool, we've added the following functionality to the RA Web:

• Download Fingerprints: Downloads a YAML text document with the CA Certificate fingerprints of all CAs you have access to.
• Download Certificate Bundle: Downloads a compressed zip file containing the CA certificates of all CAs you have access to.

For more information, see RA Web CA Certificates and CRLs.

Roadmap Update

As always we tend to be very restrictive with discussing our roadmap, but one very long awaited project we're very pleased to finally have time to redo the CA UI, a point of contention which I'm sure all of you are painfully aware of. As refactoring interfaces is always a minefield we'll be taking it in minor steps, beginning with the conversion of the antiquated JSP pages into more modern-ish JSF before beginning to make more concrete improvements in usability. Expect to see some pages in the UI slightly change appearance in the autumn, and keep tuned to this blog for more updates on this subject. 

Cheers!

Mike Agrenius Kushner

Product Owner EJBCA

EJBCA 6.12 - Brand New Documentation and Auditing Capabilities Galore!

The PrimeKey EJBCA team is pleased to announce the feature release EJBCA 6.12, and a small step but important step forward in the development of EJBCA. The first changes I'd like to divulge are organisational, we added some very important personell to our team. PrimeKey has hired a dedicated tech writer, Annica, who will be helping both the EJBCA and SignServer teams to get our much maligned documentation in order. Secondly, we've started taking in some outside help for development work, integrating them into our core team in order to increase throughput. So, what is new with this release?

Revamped Documentation

Having listened to all your calls of woe and distress over the state of the documentation (and I may add, much of our own), our tech writer Annica has performed a Herculean effort in shifting the entire thing over to Confluence instead of the ancient xdoc format.

Naturally, this is just a first step towards a far more organized, updated and user friendly documentation. You may notice a sense of chaos and disarray in the current structure, and while we agree with you fully, that is merely a consequence of the already existent structure coming to light. Major changes to take notice to that the release notes (this document), change log and upgrade instructions have all been moved in here as well. They're still available offline from within the doc folder in the release zip, but are now also published both online and deployed with EJBCA to the application server.

Configurable OCSP Extensions

We've put quite a bit of work into OCSP Extensions. Those of you familiar with OCSP Extensions will probably remember configuring them through ocsp.properties configuration file.

In order to make extension configuration simpler and more precise we've moved it to the UI, and set it up to act per keybinding instead. Any existing extensions defined in the configuration files will automatically be added to existing OCSP keybinding configurations, but please read more about that and more in the upgrade notes.

Additional Proxying Capabilities in the RA

As response to external demand, we've added two new features to the RA:

1. The ability to proxy SCEP requests, much as is done with CMP and EST already
2. We added forwarding of revocation and revocation status requests over SOAP. The full list of methods in the EJBCA WS that can be proxied via the RA are:

• certificateRequest
• checkRevokationStatus
• getLastCertChain
• keyRecover
• keyRecoverEnroll
• revokeCert

The ConfigDump Export and Audit Tool

Some of you may be previously familiar with our StateDump tool, an application for exporting and importing installations. While this has solved many problems for us and some of our customers in our past, a very common deficiency in the tool has always been that the XML based dumps are difficult to read, edit and manage, and that the data therein has never been human readable. We have thus decided to venture on remaking this tool from the ground up, and making the first iteration (which is only export capable) publicly available. It is built and run from the command line:

This results in a neat structure of export files sorted by type:

Which are serialized and normalized as yaml objects. Any UID references are replaced with their human-readable names.

We very much hope that you'll find this tool useful in the future for change handling and auditing.

Cheers!
Mike Agrenius Kushner
Product Owner EJBCA