EJBCA 7.3 Upgrade Notes

Below are important changes and requirements when upgrading from EJBCA 7.2 to EJBCA 7.3. 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.3 Release Notes.

Database Changes

OCSP Archive Cutoff

As of EJBCA 7.3, if the OCSP archive cutoff extension is enabled for the OCSP key binding, the extension is included in all OCSP responses. In previous versions of EJBCA, the OCSP archive cutoff extension was only included in an OCSP response sent in response to a request for an expired certificate.

The archive cutoff extension is disabled after an upgrade if the property ocsp.expiredcert.retentionperiod has not been configured in ocsp.properties.

Important Upgrade Information

During an upgrade, the property ocsp.expiredcert.retentionperiod specified in ocsp.properties is migrated to the database as follows:

The property ocsp.expiredcert.retentionperiod is read from ocsp.properties.
If the property is not found or set to -1, archive cutoff is disabled and there is nothing to migrate.
If archive cutoff is enabled, an OCSP archive cutoff extension is added to each OCSP key binding with a retention period as specified by ocsp.expiredcert.retentionperiod.

To ensure that there are no behavioral changes between EJBCA 7.2 and EJBCA 7.3, make sure the following is configured before you upgrade:

OCSP key bindings are configured for all CAs (only CAs with an OCSP key binding will respond with an archive cutoff extension).
The property ocsp.expiredcert.retentionperiod in ocsp.properties is set to the correct value.

After the upgrade has completed, you may remove the property ocsp.expiredcert.retentionperiod from ocsp.properties since it is not being used anymore, and optionally enable the setting to base the archive cutoff date on the issuer's notBefore date.

Behavioral Changes

Specifying Certificate Signing Key when Creating CAs

When creating new CAs it is strongly recommended that you specifically select the certificate signing key. Previously you could select the default key, which could be a convenient short-cut in test environments. As a means to improve usability and prevent misconfigurations, we have removed the possibility to specify the default key for the certificate signing key. Generally, the change will not be noticeable as this is what most users already do.

Automatic Certificate Management Environment (ACME) RFC 8555 Compliance

The ACME implementation is now compliant with RFC 8555 and not compatible with the prior release implementing ACME Draft 12. The major changes between these two releases are, that all ACME operations except directory and newNonce have to be authenticated with POST requests. The new release was tested with certbot 0.37.0 (as well as 0.31.0) and PJAC 3.0.1.