EJBCA 6.7.x to EJBCA 6.8.0

Here are some important notes on upgrading to EJBCA 6.8. For upgrade instructions and information on upgrade paths, see Upgrading EJBCA.

For details of the new features and improvements in this release, see the EJBCA 6.8 Release Notes.


When upgrading to EJBCA 6.8.0, the initial upgrade will occur automatically when 6.8.0 is deployed. All in all the following changes will have taken place, or will take place in the post-upgrade step:

Besides this, branches and custom implementations based on EJBCA code need to take the following changes into account:

Lastly, the following behavioral changes should be taken into account:

Post-upgrade can now be performed in the Admin GUI

From 6.8.0 and onwards, the "System Upgrade" menu option will be available in the UI when the system is in need of a post-upgrade-step. Post-upgradecan be triggered from here instead of from the CLI.

The role, role member and access rule implementations have changed

All rules are now recursive and during upgrade the existing access rules are converted to grant the same access. Note that when new objects are created under a recursive accept rule, access will be automatically granted.

After a post-upgrade, authentication sessions (i.e. administrators) that match multiple Roles will have the combined access from all the Roles.In previous versions different authentication methods had different priority in the case where authenticated session could belong to multiple Roles.

The "Not equals case sensitive" and "Not equals case insensitive" match operators are no longer allowed. If you use currently use them, you needto reconfigure your roles to be able to proceed past the post-upgrade

Each match key now implies if the match should be case sensitive or not. You are recommended to use the default match value operator for existing rules (usually this means "Equals case sensitive").

For the new implementation, two new tables have been introduced: RoleData and RoleMemberData. The tables AdminGroupData, AdminEntityData and AccessRulesData will no longer be updated with new data, but are retained for upgrade and 100% uptime reasons. 

Approval Profiles can now be set per action in CA and Certificate Profile

CAs and Certificate Profiles will automatically be upgraded, using the same profiles for the same actions as before. 

Be aware that exported certificate profiles from 6.6 and 6.7 can be imported, but not from prior versions. 

AuthenticationTokens are now loaded dynamically and custom implementations will need modification

Authentication token implementations now implement the AuthenticationTokenMetaData marker interface, which is used to load them dynamically using service manifests. 

The ability to search for information in the 'Details' column of the audit log has been removed

This is due to the fact that search was not delivering results for rows that contain accented characters, which gave inconsistent behavior. This functionality will be reintroduced when the search always delivers the same results. 

WebService API has changed for approvals 

During the rework of Approvals in EJBCA 6.7.0, the exception class WaitingForApprovalException was changed, where the attribute approvalId was changed to the more usable requestId. Since this value was of little use for webservice calls we judged that there was little harm in changing it, but any 3rd party implementations of the WS API should be aware of this change.    

NOTE: There is now a possibility to store subject alternative names in CertificateData, and search for certificates based on that. This feature is disabled by default and you need to enable it with 'Search enabled' for 'Subject Alternative Name' in old Certificate Profiles.  

The CLI command 'role addadmin' has been renamed 'role addrolemember'

Besides this, the command is identical to previous versions. 

In the CMP protocol, more stringent chain validation of certificate in the extraCerts fields (used in 3GPP Vendor mode and RA mode) has been introduced

If you have been using CMP clients which have previously slipped by sending incomplete or bad chains in this field, they may now be rejected. This could for example happen if your vendor of eNodeB's use a vendor CA that issues certificates invalid according to the RFC5280 standard.