Skip to main content
Skip table of contents

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

Important Upgrade Information

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

  1. The property  ocsp.expiredcert.retentionperiod is read from
  2. If the property is not found or set to -1, archive cutoff is disabled and there is nothing to migrate.
  3. 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 is set to the correct value.

After the upgrade has completed, you may remove the property ocsp.expiredcert.retentionperiod from 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.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.