EJBCA 9.4 Upgrade Notes

Below are important changes and requirements when upgrading from EJBCA 9.3 to EJBCA 9.4.

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

Licensing

As of EJBCA 9.4, EJBCA Enterprise containers require a license file to operate. If you have not received a license file yet, please contact Keyfactor to obtain one.

To apply the license to Helm chart-based deployments, create a Kubernetes secret:

BASH

kubectl create secret generic ejbca-license-secret \
  --from-file=ejbca-license=<license-file>

Next, reference the license secret in your Helm deployment parameters:

YAML

ejbca:
  license: ejbca-license-secret
# ...

Finally, upgrade the deployment using the modified values file:

BASH

helm upgrade <deplyment-name> -f values.yaml \
  oci://repo.keyfactor.com/charts/ejbca --version 9.4.0

Upgrade Baseline set to EJBCA 7.0

In the interest of renovating EJBCA’s codebase, the upgrade baseline (the earliest version of EJBCA where the database can be migrated to EJBCA 9.4 without going through an intermediate release) has been moved from EJBCA 6.3 to EJBCA 7.0

With this change a slew of legacy upgrade code has been made fully redundant, meaning that the following tables may be dropped after the post-upgrade procedure is complete:

AccessRulesData
AdminEntityData
AdminGroupData

These tables remained only to facilitate the upgrade to EJBCA 6.8, and thus may be dropped.

Behavioral Changes

Stricter Checks of End Entity Status and Profiles during Self-Renewal

EJBCA has a “Renew Certificate” page in the RA UI that allows a user authenticated with a client certificate to renew their own certificate.

Prior to EJBCA 9.3.4, this function always allowed renewal, regardless of the status of the end entity and profile settings such as the number of days specified for “Allow renewal before expiration” in the end-entity profile.

Since EJBCA 9.3.4, the correct status and profile checks are performed. In addition, it is checked that the key usage and extended key usage are valid for client certificate authentication.

Database Changes

Normalization of GlobalConfiguration Map

As part of the greater effort of making more of EJBCA configurable via ConfigDump, the GlobalConfiguration row in the GlobalConfigurationData table has been normalized into several contextualized sub-maps in their own rows, which more closely matches the corresponding ConfigDump output.

This operation is performed automatically during upgrade, and redundant database values are removed during post-upgrade.