Thursday, June 27, 2019

EJBCA 7.2.0 - CT improvements & Extended REST API

Summer is here and as promised, so is EJBCA 7.2.0! Highlighted news are performance improvements to Certificate Transparency and additional functionality added to the REST API.

Persistent Storage of Certificate Transparency SCT Responses

Persistent caching of Certificate Transparency SCTs (Signed Certificate Timestamps), in the form of a database-backed storage, has been added in addition to the existing in-memory caching. This reduces the number of requests to the CT log server and increases the performance in the following ways:

  •  The database-backed storage will be used after a restart when the in-memory cache is empty.
  • The in-memory storage has a limit of 100 000 certificates by default, and will only keep the SCTs for the most recently requested certificates. The database-backed storage has no such limit and will be used for SCTs for less frequently requested certificates.
  • The database-backed storage will store partial results for a certificate, allowing EJBCA to retry a submission efficiently at a later point.

Additionally, the default configuration was changed to rate-limit connections to logs that are down or return error codes. This reduces the load on both log servers and
EJBCA. For example, if a CT log rate-limits EJBCA, then EJBCA will back off for 1 second by default.

Crypto Token and CA Management REST API

The EJBCA REST API has so far been limited to Certificate Management operations. We've now extended the REST API, adding resources for CA administration as well. This allows simpler remote integration and management as an option to the GUI. New endpoints support Crypto Token and CA Management including:
  • CA activation and deactivation.
  • Crypto Token activation and deactivation.
  • Key generation and removal.
New REST end points in Swagger-UI

Expect more news from us this autumn!

the PrimeKey EJBCA Team

Tuesday, June 25, 2019

EJBCA ♥ YubiKey

With the keygen tag in its final death throes, time has come to move on to new and better ways of managing keys on tokens. We here at PrimeKey are big fans of our friends at Yubico, so here is a neat little guide of how to get up and running with using your YubiKey with EJBCA.

Disclaimer: This blog post is in no way sponsored nor endorsed by Yubico, though they were quite kind and provided us with a couple of tokens to play around with. We just honestly like them. 


To get going, you're going to need to have the following installed on your workstation:

Creating a key pair on your YubiKey

1. Start up the YubiKey Manager
2. Under Applications, pick PIV and then Configure Certificates

3. Under the Authentication tab, click Generate to create a new key pair on the token. This will take you through a guide of creating a key pair by picking an algorithm, key size and setting the Common Name for your token. 
4. Make sure that you specify that you was a Certificate Signing Request (CSR)
5. This will result in a CSR that you can use to enroll the key pair to EJBCA. 

Enrolling the YubiKey to EJBCA

Enrolling the newly created key pair is done just like with any other enrollment.

1. Go to the EJBCA RA UI
2. Click on Enroll, choose the appropriate certificate type and sub-type and choose Generated by User, which will prompt you to upload your CSR from the previous step.
3. Fill in any other pertinent information, then choose Download PEM

Importing the Certificate to the YubiKey 

1. Open the YubiKey Manager, and again choose Applications, pick PIV and then Configure Certificates
2. Click Import and pick the new newly generated certificate.
3. Congratulations - your YubiKey is now up and running, but we still need to configure the browser to play along. 

Configuring FireFox to use YubiKey

1. Open Firefox and enter about:preferences in the address bar
2. Under Privacy and Security click on Security Devices 
3. Click on Load to install OpenSC's PKCS#11 Driver
4. Name the module and then locate the (or similar) library
5. The YubiKey will now be shown as a security module

Configuring Access Rights in EJBCA 

This is done using Roles as with any user EJBCA administrator, but here are the exact steps:

1. In the EJBCA CA UI, pick Roles and either create a new Role or add the new administrator to an existing Role
2. To add the administrator, click on Members, pick the appropriate CA and enter the identifying the information for the certificate, preferably the serial number
3. An easy way to find the serial number is to view the certificate in OpenSSL using the command:
$ openssl x509 -in alanwidget.pem -text -noout
The serial number can be copied, converted from hex to decimal using a converter and then used in EJBCA.

4. Finally, click on Access Rules and set the required rules for your administrator
5. The next time you start a new session, your YubiKey will be offered as an option

Thursday, May 16, 2019

A bit about us...

We seldom speak much about the team behind EJBCA or about PrimeKey Solutions on a whole on this blog, so for those interested I'd like to write a bit about us and our culture for those of you who might be interested.

The Evolution of a Company

PrimeKey Solutions was founded way back when in 2002 by a small group of developers who saw the need for an Open Source CA solution, which was innovatively named EJBCA. While we're great at many things, we do admit that naming products is maybe not one of them - I do bid you remember that this was the tail end of the IT-era; it could have been way worse. 
PrimeKey's logo ca 2005
FOSS was an important concept from the very start - both from a practical viewpoint (don't trust anything that you can't verify), but also ideological. PrimeKey was founded on the principal that cryptography (and by extension PKI) should be widely available, so was from the very start founded on FOSS principles, and PrimeKey have ever sought to make use of open source, as well as contributing to the projects that we use (such as BouncyCastle) both in code and monetarily. 
PrimeKey's logo ca 2014
PrimeKey has since then grown and evolved, from being a tiny one-room-everybody-does-everything-company to what it is today: a steadily growing, +100 person company with offices in three countries, specialized staff and specific roles going forward. 
Our logo since 2017

The Evolution of a Team

I joined PrimeKey back in 2010, back in the heydays of the entire company sharing the same volume of air during a working day. Except for our then CEO and a couple of other staff, the bunch of us (<10 people) mostly filled the same roles to varying degrees: developer, professional services, IT, support, QA, documentation, tech sales - there was little delimitation and even less structure. You did what was needed and learned the skills required to overcome the next task at hand. We were happy in those days, though we were disorganized. 

I was originally hired as a developer, but back in those rousing days the prospect of travel appealed to me as well. Between writing (and refactoring) mounds of code, working with customers took me from Ankara to Antwerpen, from Brussels to Baku. My first major project was working with our upcoming Common Criteria certification back in 2011, which taught me the joys of writing months worth of pointless documentation and speaking to auditors.

What I'm getting at was that we existed in mostly a state of unmitigated pandemonium; working on customer requirements as they arose, our own fancies and interests, putting out wild bush fires and occasionally lighting them. At a tech conference in 2012 I described our work style as "Controlled Chaos", which very much makes me cringe today. 

This finally started changing round about 2016 or so, when we were faced with a few issues:
  • We were evolving as a company, moving more towards corporate customers. A couple of bad experiences of letting customers specify implementations, implementing those specs to the letter and then discovering that the customer had asked for the wrong thing showed that we needed to involve ourselves more in specification work. 
  • While the free-form organization was great for allowing the removal of tech debt on a minor scale, non-critical refactoring that would have required major effort were difficult to organize. 
  • Our roadmap was basically just the JIRA backlog, meaning that release dates were largely hypothetical concepts. 
  • Long release cycles (3-4 months) coupled with a lack of issue slicing and cycle breaks (such as sprints) lead to monolithic commits waiting for months on review, occasionally turning out long after the fact to be unsatisfactory or incomplete. 
We direly needed to change. I won't go into the whole process and evolution of how we got to where we are today (though I might write that as a blog post at a later date), I'd love to describe how the EJBCA development team works at present. 

The Team(s)

The goals of our teams are to be as self organizing as possible, wherein each has their own integrated Scrum Master in order to organize and synchronize the teams around common goals. With QA as integral parts of each team, we've started moving away from testing as a waterfall feature and instead testing proactively (and most importantly, just testing). 

The teams each maintain their own culture and rules internally, and sync one day a week in either a general tech meeting to discuss ongoing tasks, hinderances or questions, and have a common retrospective at the end of each sprint in order to evaluate what went well and what went poorly. 

Our Roadmap and Development Cycle 

My role as Product Owner is primarily to maintain a vision and a roadmap in order to help the teams focus on the most important requirements for the moments, to give guidance and answer implementation questions that the teams can't answer themselves. Thus my main avenue of communication with the teams is maintaining and constantly updating the roadmap, which allows them to on their own prioritize and sort the backlog (with some input from myself). Versions are set for features and fixes only as they enter the near horizon (except for features with fixed dates such as customer implementations and specification implementations), which sends less false signals to customers in regards to completion dates, and gives a truer image of what can be expected in each release.

The teams today follow three week development sprints, at the end of which all issues need to be resolved, reviewed and closed. Issues are sliced down to a three days or less if possible. This cuts down on both issue size and time-to-review, letting us catch design errors earlier, before they propagate. It also eliminates the large degree of release date uncertainty due to the large grey blob of review time (and resulting fixes) always invariably plaguing the end of each release cycle. Besides the retrospective mentioned above, sprints often end with an internal sprint demo to show what's been accomplished, and a release demo post release to show off for the rest of the company what's new. 

The Result

In the last couple of years we've taken great leaps forward in terms in terms of reliability, predictability and above all quality. While we still have a long way to go, we are extremely pleased with the results so far.

The Evolution of an Office 

The Stockholm office has changed addresses four times in nearly 20 years. The gang started off sitting in what amounted to a shoebox, before moving to slightly bigger digs in 2009, which is about the time I came into the picture.

The new office was slightly larger than the old one, but the entire team still shared a single room (with an office for our CEO and VP Sales), happily all breathing the same air for the entire working day. 

My desk back in 2010, with era-appropriate camera filter and still relevant stacks of DVD blanks. 
We shared an office back then with two other companies, with constant bickering over which coffee machine to lease (bad coffee leads to bad code - you can quote me on that). We were on top of a children's osteopath, so on clear days the workday was hellishly audioscaped by the little moppets' wailings up through the ventilation. Good times. 

With time we came to outgrow that office, first shifting out one of our office-mates before getting outshifted ourselves. We'd grown to expand over two rooms, and there was as little piece and quiet as there was space to move around the tightly packed desks. Upon finding new space in 2016, I sat down and wrote a manifesto of office design, arguing that the current and continued practices of open offices was provably based on faulty theories on workspace design, citing the esteemed Joel Spolsky, among other sources. I ranted! I raved! I built barricades out of hutches and obsolete cryptographic digests. Join me! I called. Let us throw off the yoke of office plan oppression, seize the means of production and be allowed to work without external interruptions! 

But one colleague heeded my call. We were given our own room in the new office and told to shut up. We were happy. 
The author exploring his new digs. New feats of concentration were attained in this small room. 
Come this year (2018) we had once more outgrown the previous office. PrimeKey's success in the last few years led to huge growth for the company, and we finally expanded into having proper teams handling support, integration and sales - by extension allowing us to hire more developers and QA staff. Management located a new place only a stone's throw away from the existing one, this time moving us into a complete floor of a proper office building, complete with proper server room in the basement, a view and space for luxuries like a gaming room. 
Our office since 2018
A gaming room with a foosball table, the true sign of prosperity
Upon planning the move our CEO Magnus very graciously (and wisely) asked a selection of employees our thoughts on the new office and ideas for an office plan, so for the developers we suggested a scheme that lies more in line with both our own philosophies and with what is considered modern practice. We actively rejected any suggestions for open office plans (or its blasphemous mutated step child, hot desking), but instead suggested that we put up walls or roof-to-floor-dividers, and space them out to create reasonably sound proof work areas containing 4-6 desks, which we consider the ideal team size. We felt that this would have the following advantages:
  • Humans are social creatures, and do well from interacting with others. Development work (particularly in cross functional teams) requires the ability to hold spontaneous meetings and interactions. For teams to form bonds they need to interact, tell in-jokes, form their own culture. 
  • Development work generally requires large degrees of concentration due to the mental effort of visualizing complex solutions, and unwanted distractions (others' phones, distant conversations, etc) lead to stress, anxiety and generally lower productivity. 
  • As humans we tend to nest in order to create a sense of belonging and familiarity in our surroundings, spreading around us items both useful (that extra phone charger) and decorative. We tend to do so in small groups as well, so this scheme would allow each team to be able to decorate their own spaces as they see fit. 
In addition, the additions of walls and partitions would allow each team to have a dedicated whiteboard to use while collaborating on features, a large TV monitor to statically display information (such as CI machine status, roadmaps or JIRA boards). In the end I have to say, management delivered beautifully:
Team Alice's work area

The home of Team Bob
The dwellings of the SignServer Team
While it may not look like much, these spaces serve us perfectly in allowing each team to concentrate on problems and issues, allowing collaboration and social interaction while letting those needing to bite down on a problem concentrate while avoiding the angst-inducing sight of cubicle farms. 

All in all, were constantly evolving here at PrimeKey - analyzing and reevaluating what makes us better as individuals, as teams and as a company.

We're already doing what we love, and now we're a huge leap forward in how much we love doing it. 

Mike Agrenius Kushner
Product Owner EJBCA

Monday, April 29, 2019

EJBCA 7.1.0 - Partitioned CRLs!

Spring has finally arrived in Stockholm, following the traditional seasons of Winter, False Spring, Second Winter, the Spring of Deceit and the final cold snap of I-Just-Changed-My-Tires. The melting snows bring with them many gifts, besides the beer forgotten on the balcony last November, among them EJBCA 7.1

Partitioned CRLs

Long and enduringly requested, EJBCA 7.1 is now capable of producing partitioned CRLs. Activated under the CA configuration, the number of partitions per CRL is dynamically configurable, allowing new partitions to be added as the CRL grows, and assignment to older partitions to be suspended in order to allow for future growth. CDP partition assignment is random in order to allow for even distribution of certificates, and partition definition can be looked up in the CDP extension as defined in RFC5280.
For those of you not wishing to use partitioned CRLs life will mostly move on as usual while for those of you applying partitioned CRLs to existing installations you will retain a legacy CRL for pre-existing certificates (as the CDP can't be changed retroactively) while newly issued certificates will be issued to partitions.

Deprecation and Removal of Hard Token Support

In an effort to relieve ourselves of maintaining little-used features we have chosen in this release to deprecate and remove support of hard tokens, after analyzing that it has little to no use among PrimeKey customers. Naturally this will have no impact on existing installations, but we have provided scripts for those of you wishing to remove the relevant tables from the database. See the upgrade notes for more details.

VA and RA Specific Distributions

As a response to market interest, we've enhanced our build process and modularization in order to produce VA and RA specific builds of EJBCA, each capable of acting in their specific roles but not as a CA. This allows PrimeKey to offer a more dynamic model for Appliance and Cloud users who would like to add RA and VA instances to their PKIs but find it prohibitive to pay for the full fee for the complete distribution. The standard CA distribution still retains the full VA and RA capabilities as before. If you're interested in finding out more, please contact

EJBCA 6.15.2 CE Available on Docker Hub

As some of you already know, as part of our ongoing containerization project we've added a docker container to Docker Hub, built on a sneak-peek of the coming release of EJBCA 6.15.2 Community Edition. 
If you're interested in moving your PKI towards containerization, please go ahead and have a look, and feel free to give us any feedback! 

Mike Agrenius Kushner
Product Owner, EJBCA

Monday, March 4, 2019

EJBCA 7.0.1 - PSD2 and SN Entropy

Hot on the heels of EJBCA 7.0, we'd like to present the release of EJBCA 7.0.1 - implementing a ton of neat functionality that didn't make the cut for the main release. On top of the list of most commonly requested features is PSD2 support, but please read on to find all the reasons to upgrade to EJBCA 7.0.1!

Full PSD2 Support

EJBCA 7.0.1 provides full support for the Payment Services Directive as defined by EU Directive 2015/2366. PSD2 allows eIDAS Trusted Certificate Providers to issue PSD2 QWAC certificates to third party FinTech companies, which in turn gives them access to financial APIs hosted by European banks. To enable PSD2 in your instance of EJBCA, scroll down to the QC Statements extension of your certificate profile and enable the PSD2 option. 
 This will enable PSD2 fields in the RA UI during enrollment.
If you'd like to read more about PSD2, we've written blog post about it on PrimeKey's blog and right here on our own development blog.  

Domain Blacklist Validator

As a request from some of our CABF-customers, we've implemented a Domain Blacklist Validator. The new Validator takes a list of partial and complete domain names, and can be configured to either block them outright (if run during the data phase) or cause an approval action to be triggered in the final approval step (if approvals are activated). 
All of the approving RA administrators in the final approval step will be shown the following warning before the approval passes:

dnsName SAN can be Automatically Populated by the CN

We've added a setting to End Entity Profiles to allow the dnsName Subject Alternative Name field in a certificate to be filled in by the Common Name (CN) value in the Subject DN.

Configurable SN Entropy, Default Value Raised to 20 Octets

CA/B Forum requires the use of 64 bit entropy when generating serial numbers (see CABF Ballot 164). Due to only positive values being valid serial numbers, 8 octets will only result in 63 bit entropy as the most-significant-bit will always be 0, hence we recommend larger sizes than 8 octets. Previously this was set using the property ca.serialnumberoctetsize in, which has now been dropped and the value is instead set directly in the CA.
Possible values may range between 4 and 20 octets, and the default for all new CAs is 20 while upgraded CA's will retain whatever value was set in ca.serialnumberoctetsize, or 8 if none was set. 

Downloadable CSRs

In EJBCA 7.0.1 we've started storing CSRs along with the associated certificate (instead of only the last submitted CSR as it was earlier), so you now have access to download and review all CSRs submitted and processed in the past.

URL Metadata Type Added to Approvals

Upon popular request, we've added a URL metadata type to the partitioned approval profiles. It allows the approving RA administrator to enter a URL while performing the approval, e.g pointing to a file upload at an external location.
Upon later review of the approval, it will show up as a hyperlink:

Experimental: Configuration Checker

Lastly, we're trying out an experimental new feature in EJBCA 7.0.1, the Configuration Checker. It displays an (incomplete) list of common configuration issues on the front page. 
If you'd like to try it out, it can be activated in its own tab under the System Configuration:

Roadmap Update

Common Criteria

Our common criteria process is ongoing - the Security Target (ST) is now complete and has been sent for evaluation. Preliminary date for a certified version of EJBCA is still projected to be at the end of this summer. 

Appliance Release

EJBCA 7.0.1 will be available on Appliance 3.3.0, due at the end of March/beginning of April.

Up Next

The teams are rearing to go to work on EJBCA 7.1. Main features are going to be Partitioned CRLs, multi-value RDN support and a couple of surprises. See you then!

Mike Agrenius Kushner
Product Owner, EJBCA

Friday, February 22, 2019

eIDAS and PSD2, what's new for PKI and what can you do?

What does PSD2 have to do with eIDAS?

With the introduction of the Revised Payment Service Directive (PSD2) in EU there are many changes for Payment Service Providers, but there are also some changes for eIDAS (Trust Service Providers (TSPs). Payment service Providers (PSPs) will be required to use Qualified Certificates for electronic seals and website authentication. Specifically for PSPs there are new fields in the QC statement in certificates issued to for this purpose. With PSD2 the QC statement is an interesting mix of issuer specific field (static) and subject specific fields (dynamic). For general eIDAS QC statement information see our earlier blog post.

PSD2 Specific Certificate Fields

The PSD2 specific fields are specified in the recently released ETSI Technical Specification ETSI TS 119 495 in section 4.

Lets look at the new fields and what they mean. There are four required fields in TS 119 495:
  • Authorization number
  • Roles of PSP
  • NCAName
  • NCAId
The authorization number is a registration number of the payment service provider. This number must be included in the Subject DN of the certificate, in the organizationIdentifier DN attribute. This is a dynamic field, different for each certificate issued to different PSPs, but the same for multiple certificates issued to the same PSP. OrganizationIdentifier is supported in EJBCA Enterprise PKI from version 6.5.2. The other three elements are part of the QC statement.

PSD2 Qualified Certificate Statement

The PSD2 specific fields in the qualified certificate statement are specified in ETSI Technical Specification ETSI TS 119 495 in section 5.

Every PSD2 Third Party Payment Service Provider can have one or more of four different roles (described in section 4.2 of TS 119 495). This means this must be a dynamic field to be set by the TSP when issuing the certificate to the PSP. The four roles are account servicing (PSP_AS), payment initiation (PSP_PI), account information (PSP_AI) and issuing of card-based payment instruments (PSP_IC).

The NCAName and NCAId is the name and ID of the National Competent Authority (NCA). This is for example BaFin in Germany. These are specific to the country where the PSP is registered. Since TSPs can issue certificates within any country in EU, this also means that the NCAName and NCAId fields must be dynamic fields to be set by the TSP when issuing the certificate to the PSP.

PSD2 QC Statements is supported out of the box in EJBCA Enterprise PKI from version 7.0.0. In earlier versions they can be created with custom extensions in order to produce test certificates.

Creating PSD2 Certificates with EJBCA

To issue PDS2 certificates with EJBCA Enterprise (7.0.0 and later):
  • Check the ETSI PSD2 QC Statement checkbox in the Certificate Profile
  • Include the PSD2 specific fields when issuing the certificate

./ EjbcaWsRaCli edituser psd2 foo123 true "CN=PSD2 eSeal Certificate,organizationIdentifier=12345678-9876,O=PrimeKey,C=SE" NULL NULL ManagementCA 1 PEM NEW User Client NULL  NULL NULL "QCETSIPSD2ROLESOFPSP=;PSP_AS" "QCETSIPSD2NCANAME=PrimeKey Solutions AB, Solna Access, Plan A8, Sundbybergsvägen 1, SE-17173 Solna" "QCETSIPSD2NCAID=SE-PK"
You can also set PSD2 specific fields in the web UI (EJBCA 7.0.1 and later), by specifying those to be used in the End Entity Profile:
After that you will be able to enter PSD2 fields in the Admin UI and the RA UI:

PSD2 Certificate Timeline

Payment services must provide account information and payment services with adequate documentation of the technical interface and a corresponding test environment that works with PSD2 certificates from March 14th 2019. From September 14 2019, all service providers must be PSD2-compliant.

EJBCA Enterprise

We strive to support all relevant open PKI standards and it is important to keep EJBCA Enterprise up to date with new and emerging standards. Since EJBCA 6.5.2 eIDAS compliance should be easily achieved on the level of PKI, and the new PSD2 specific QC statement is fully supported in EJBCA 7.0.1.

Tomas Gustavsson

 EJBCA Enterprise PKI and PKI Appliance developed by PrimeKey.

EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.

Monday, February 18, 2019

The (updated) Definitive EJBCA Upgrade Guide

With the release of EJBCA 7.0 and subsequent drop of support for JDK7/JEE6, we've updated the upgrade guide that we published back in 2017 to reflect these changes. With no further ado, here it goes:


The official steps for upgrading any EJBCA installation are:

If running EJBCA < 4.0.16 on JDK6 or earlier:
  1. Upgrade to EJBCA 4.0.16
  2. Run ant upgrade from the console
  3. Run ant post-upgrade from the console
  4. Continue below
If running EJBCA >= 4.0.16 but < 5.0.12 on JDK6 or earlier:
  1. Upgrade to EJBCA
  2. Run ant upgrade from the console
  3. Run ant post-upgrade from the console
  4. Upgrade to JDK8 
  5. Upgrade application server to a JEE7 supporting application server
  6. Deploy the latest version of EJBCA 
  7. Run ant upgrade from the console
  8. Run post-upgrade from the UI
    If running EJBCA >= 5.0.12 but < 6.4.0:
        1. Upgrade to JDK8 
        2. Upgrade application server to a JEE7 supporting application server 
        3. Upgrade to latest version of EJBCA 
        4. Run ant upgrade from the console
        5. Run post-upgrade from the UI
        If running EJBCA >= 6.4.0:
        1. Upgrade to latest version of EJBCA 
        2. Run post-upgrade from the UI


        A typical upgrade path:

        1. EJBCA 4.0.16 (on JDK6, JBoss 5.1.0.GA) 
        2. EJBCA (on JDK6, JBoss 5.1.0.GA) 
        3. EJBCA (on JDK8, WildFly 12) 
        4. EJBCA 7.x


              The background to writing this guide both stems from the understandable confusion in regards to upgrading EJBCA and many of our users experiencing problems when upgrading decade old installations. Thus there are some concepts we'd like to go through and explain:

              The Intermediate Release: EJBCA

              During EJBCA 6.8.0 we refactored the roles and access rules massively, which lead to an upgrade break when upgrading from versions of EJBCA prior to 5.0 (though upgrading via EJBCA 5.0 was still possible). As we realized that solving this issue while preserving 100% uptime requirements (see below) was impossible, as well as due to the technology jump (see the next section) and bugs that we discovered while testing upgrading from ancient installations, we created EJBCA in order to handle all the intermediate steps. As of today EJBCA is published and available in the Community Edition on SourceForge, and in the download area for customers.  

              Technology Jump - JDK6 → JDK7

              When: EJBCA 6.4.0

              All good things must come to an end, as must support for legacy runtime versions. As much as we value not having to put our customers through unnecessary hoops by forcing them to upgrade underlying technology such as the JDK, at some point we have to drop support due for several reasons: being held back by not being able to use modern developments, because other dependent systems like Application Servers drop support as well and because the JDKs themselves come to the end of their service lives and will no longer receive support from the vendor. 

              Technology Jump - JEE5 → JEE6

              When: EJBCA 6.4.0

              In EJBCA 6.4.0 we decided to move on to JDK7, which means that it can no longer be deployed to application servers based on JDK6 such as JBoss versions 4 and 5. The latest version that can still run under JDK6 is EJBCA For an upgrade path this means that you can continue running on your old JBoss 5.1.0.GA server (JEE5) up to, and including, the EJBCA intermediate release. At this stage you must upgrade JDK and the application server to JDK8 and JBoss EAP 7 or WildFly 10.

              Technology Jump - JDK7 → JDK8

              When: EJBCA 7.0.0

              With the planned drop of official support from JDK7 from Oracle during 2019, we've decided to drop JDK7 support. Internally this allows us to upgrade now aging libraries which have long since ceased receiving security updates.

              Technology Jump - JEE6 → JEE7

              When: EJBCA 7.0.0

              The loss of JEE6 support means that we've taken the chance to upgrade persistence definition files and library schemas to JEE7 standards. This means that EJBCA will no longer render on JEE6 application servers, meaning that minimal supported AS's are JBoss EAP7/Wildfly 10. 

              100% Uptime during Upgrade

              When: EJBCA 4.0

              While this may be familiar to many of you, EJBCA has ever since version 4.0 supported full uptime during upgrades for clustered installations. What this means is that we pledge that a clustered installation can continue to sign certificates, issue CRLs and answer OCSP queries during the upgrade process with no noticeable downtime for the end user. 

              This is why the upgrade process you may be familiar with is split up into two steps: upgrade and post-upgrade. In short, upgrade performs whatever steps may be required for the first node to be upgraded to be able to function once it comes online again, while post-upgrade performs whatever steps that remain (such as clean up) that can only be performed once all nodes are running the latest code. 

              Automatic Upgrade

              When: EJBCA 6.4.0

              Stunningly, prior to EJBCA 6.4.0 we hadn't actually thought of tracking the database version internally, thus requiring our user to manually enter this value. From EJBCA 6.4.0 and later we do in fact track this, doing away with the need to run the upgrade command entirely. Instead, it'll be automatically run from the first node running the upgraded code. 

              post-upgrade from Console

              When: EJBCA 6.8.0

              In a similar vein, as more and more of our customers run EJBCA on the PrimeKey Appliance and thus don't have access to the command line. As of EJBCA 6.8.0 it's been possible to perform post-upgrades from the UI. When a post-upgrade is required, the System Upgrade option will appear in the menu:
              Choosing it will bring you to a screen used to perform the post-upgrade action:


              With this blog post and our latest round of QA, we hope that we've solved all existing upgrade issues, and that we can make running the latest version of EJBCA as easy and manageable as possible.

              Tomas Gustavsson

              Mike Agrenius Kushner
              Product Owner EJBCA