EJBCA 6.6 Upgrade Notes

EJBCA 6.5.x to EJBCA 6.6.1

The following lists important notes on upgrading to EJBCA 6.6.x versions:

For upgrade instructions and information on upgrade paths, see Upgrading EJBCA.

For details of the new features and improvements in the releases, see the EJBCA 6 Release Notes.

EJBCA 6.6.0 to EJBCA 6.6.1

The upgrade to EJBCA 6.6.1 enables seconds precision for CA and user certificate configuration and allows the issuance of short living certificates. To achieve this, for the CA and the certificate profile a new field for the validity is implemented. This field is populated when a CA and certificate profile is loaded from data object for the first time.

Furthermore, the handling of leap years was changed. Previously, EJBCA would take leap years into account when creating a CA or certificate profile when a validity was specified in terms of years (with "10y" syntax), and add extra days accordingly. Since 6.6.1, EJBCA always counts a year as 365 days, so if you need to account for leap years, then you need to specify them manually, for example as "10y 2d". CAs and certificate profiles from earlier versions will keep their existing validity times unchanged.

EJBCA 6.5.x to EJBCA 6.6.0

Upgrading to 6.6.0 will require replacing the approval settings in CAs and certificate profiles with approval profiles. If approvals are used in any capacity, you need to run the following command after deploying the new version of EJBCA and restart JBoss. If approvals are currently not in use, this step is not needed.

$ ant upgrade

Upgrading to 6.6.0 involves the following changes:

Changes to CertificateData

CertificateData has three new columns "notBefore", "endEntityProfileId" and "subjectAltName".

CertificateData is for storing issued certificates and can be quite large. Even though deploying the new version EJBCA will eventually performthe schema change on larger installations, we strongly recommend that you manually alter the table before deploying the new version of EJBCA. (Otherwise you might need to force a restart of the application server.) Since CertificateData is used by EJBCA running as a Validation Authority, you need to make this database schema change to your VAs as well before upgrading for publishing to work.

See src/upgrade/650_660/650_660-upgrade-<database>.sql for the correct SQL ALTER statement.

In the case where the endEntityProfileId and subjectAltName has not changed for End Entities since certificate issuance, you can copy this value using a SQL statement like (consult your DBA for the proper syntax and feasibility of executing this query on your production database):

UPDATE CertificateData AS a INNER JOIN UserData AS b ON a.username = b.username
SET a.endEntityProfileId = b.endEntityProfileId, a.subjectAltName = b.subjectAltName WHERE a.endEntityProfileId IS NULL;  

Changes to ApprovalData

ApprovalData has a new approval profile concept. Approvals created prior to 6.6.0 will still be available, but performing approvals on nodes running EJBCA versions prior to 6.6.0 on an upgraded database (i.e during upgrade) is not supported. As part of this change, approval notifications are now configured per approval partition instead of globally. Check your Approval Profile afterdeploying the new code.

Public Web Self Registration

If you have been using the Self Registration in the old Public Web you need to create an Approval Profile, and select to use this for "Add/Edit End Entity"actions either in the CA configuration or in the Certificate Profile configuration.

Changes to WebService Approvals

If you have been using Approvals with the WebService API you have configured approval settings in jaxws.properties (only related to calls to genTokenCertificates and/or viewHardToken). This configuration setting has changed as part of the new approval profile concept. Look at jaxws.properties and configure a new approval profile for the WebService Approvals.

Removal of the access rule /ca_functionality/store_certificate

The access rule /ca_functionality/store_certificate has been removed for the simple reason that it wasn't actually used. It will not be cleaned from anyexisting roles due to being harmless (and invasive to remove).

100% Upgrade Uptime Notes

Approval Profiles

Approval profiles (of the Accumulative Approval Profile type) will during startup of the first upgraded node be automatically created and set for CAs and Certificate Profiles using approvals. During the upgrade, approval requests may roll in from un-upgraded nodes, and these will automatically be re-parsed when they are read from the upgraded ones, in other words set to use the same profile as if they'd been created on an upgraded node. For the sake of 100% uptime, this means that all actions (enrollment, revocation, CA activation, etc) may continue during the upgrade, and they may be processed from the upgraded nodes. On the other hand, un-upgraded nodes will not be able to approve actions created by or read by the upgraded nodes until the upgrade process is complete.