Below are important changes and requirements when upgrading from EJBCA 7.5.0.X to EJBCA 7.6.
OCSP Logging Configurable in the GUI
The OCSP Audit Log and the OCSP Transaction Log configuration are now configured in the EJBCA GUI instead of in the
ocsp.properties configuration file, see OCSP Management. Your existing configuration in
ocsp.properties is migrated to the database when EJBCA 7.6.0 is deployed for the first time. The property
ocsp.log-timezone is ignored and the timezone specified in
ocsp.log-date is used instead.
Stricter Enforcement of Script Execution from the General Purpose Custom Publisher
The enforcement of which local scripts are allowed to be executed from the General Purpose Custom Publishers has been improved to verify against script enablement and an allow list every time the publisher runs. If you are using a General Purpose Custom Publisher to run scripts locally on the CA, verify that access to scripts are enabled in the EJBCA System Configuration (System Configuration → External Scripts → Enable External Script Access). If scripts are enabled and no allow list enforced, you are not affected by the change. If scripts are enabled and an allow list is enforced, ensure that the script executed is on the allow list.
Additional Password Masking in ConfigDump and Statedump
ConfigDump exports previously included certain passwords that allowed importing the passwords into other environments. As of EJBCA 7.6.0, all passwords are masked. This means you now need to either edit the exported configuration file before import or edit the values in EJBCA after the import. For more information, see ConfigDump Tool.
Alias passwords are exported in encrypted form in the Statedump tool. If importing a Statedump configuration file into a system with a different encryption key configured, the input cannot be decrypted, and instead, the hex string with the (old) encryption will be used as the alias password. You can edit passwords in Statedump XML files before import, or change the passwords after import using the EJBCA CLI or CA UI.
CMP Revocation Applying Multi-tenant Controls on Issuing End Entity Profile
When using an RA calling EJBCA with CMP, utilizing client certificate authentication (signed CMP messages), revocation requests now always control the RA authorization against the end entity profile used to issue the certificate. This enables RA separation based on end entity profiles. Note that if you were relying on only the revoke privilege for RAs, this may now prevent revocation if your access rules do not allow revocation from the same end entity profiles for which issuance is permitted.
Extended Key Usage Enforced for Peer Connections
Due to an issue in earlier versions of EJBCA, outgoing peer connections would accept server certificates having an Extended Key Usage (EKU) extension, but without the Server Authentication value.
The EKU certificate extension is now enforced. This affects only systems with incorrectly configured EKU certificate extensions. Systems with correctly configured EKU certificate extensions will not require any changes.