Below are important changes and requirements when upgrading from EJBCA 7.0.1 to EJBCA 7.1:

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 7.1 Release Notes. 

Database Changes

A new column, crlPartitionIndex, has been added to the CertificateData, NoConflictCertificateData and CRLData database tables. If your EJBCA database user does not have GRANT privileges, you will need to run the ALTER commands in the upgrade scripts. Please note that if you use the Validation Authority Publisher with CRL publishing, you must upgrade at least the CRLData tables on the VAs (or the whole database) before you upgrade the CAs.

After EJBCA 7.1.0 is deployed, it is safe to remove hardtokendata, hardtokenissuerdata, hardtokenprofiledata and hardtokenpropertydata database tables.

Upgrade scripts are available in the src/upgrade/700_710 folder.

Behavioral Changes

New Access Rules for RA Roles

Some access rules for roles created in the RA web were missing or not set properly.

The new behavior in EJBCA 7.1 is as follows:

  • When Approve end entity actions is selected, access is granted to both view and approve end entities. In previous versions of EJBCA, access was only granted to approve end entities, but not to view approvals.
  • When Create certificates is selected, access is granted to issue certificates for an end entity. This access rule was missing from the RA web in previous versions of EJBCA.
  • When View end entities and certificates is selected, access is granted to both view end entities and certificates issued to those end entities. In previous versions of EJBCA, access was only granted to view end entities, but not the certificates.

The missing access rules will not automatically be granted to existing roles during an upgrade. You need to manually edit any existing RA roles created in the RA Web and enable the appropriate options for the changes to take effect.

Default CMP response signature algorithm is now SHA256

The signature algorithm used to sign CMP response now defaults to SHA256 instead of SHA1. The default algorithm is only used if the CMP request does not contain a signature algorithm, so for most users, there is no change, and SHA1 will be used if your client sends messages signed with SHA1. The only typical case where the default algorithm is used is when client messages are protected by HMAC protection and the CMP server is configured to answer with signed messages. If your CMP clients understand SHA256, they will be able to process the responses as the algorithm used is part of the response.