EJBCA 7.2 Upgrade Notes
Below are important changes and requirements when upgrading from EJBCA 7.1 to EJBCA 7.2:
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.2 Release Notes.
Behavioral Changes
Certificate Store and CRL Store Servlets Always Available
The configuration files certstore.properties and crlstore.properties are removed and should no longer be used.
These configuration files allowed you to specify the context root of the servlet and whether the servlet should be available in the EAR file. As of EJBCA 7.2, these two servlets are always available and the context root property has been removed.
Access to these servlets is controlled using Modular Protocols Configuration.
If you are using a custom context root for these servlets, you should reconfigure your client to use the new context root, or put an HTTP proxy between EJBCA and your client. Wildfly can act as HTTP proxy, see WildFly 14 / JBoss EAP 7.2.
|
Property |
Default setting in EJBCA <7.2 |
Default setting as of EJBCA 7.2 |
|
CRL Store |
||
|
crlstore.enabled |
false |
trueSetting configured using Modular Protocols Configuration at runtime. |
|
crlstore.contextroot |
/ejbca/publicweb/crlsSetting configured in crlstore.properties at compile time. |
/ejbca/publicweb/crls |
|
Certificate Store |
||
|
certstore.enabled |
false |
trueSetting configured using Modular Protocols Configuration at runtime. |
|
certstore.contextroot |
/ejbca/publicweb/certificatesSetting configured in certstore.properties at compile time. |
/ejbca/publicweb/certificates |
If you are upgrading from EJBCA 6.11 or later, and your previous deployment did not contain the servlet, access to it will be disabled after an upgrade. However, if you are upgrading from EJBCA 6.10 or older (where the Modular Protocols Configuration feature was not implemented) access to the servlet cannot be configured automatically during an upgrade, since there is no way of determining whether your previous deployment contained the servlet or not. If your previous deployment did not contain the servlet and you do not want it to be accessible, you need to manually disable it.
|
Upgrading from |
EJBCA 6.10 or older |
EJBCA 6.11 and later versions |
|
Previous deployment contained servlet |
New deployment will still contain the servlet, and it will be enabled. |
New deployment will still contain the servlet, and the existing configuration value in Modular Protocols Configuration is kept. |
|
Previous deployment did not contain servlet |
New deployment will contain the servlet, and it will be enabled. |
New deployment will contain the servlet, but it will be disabled. |
Improved Service Execution Logging
Previously the logs stated that service workers had executed or not, but didn't note the state of the execution (any errors being rendered as parts of output). Service workers have been modified to report to the logs the complete execution state, which can be Successful (if run), Failed (if run, although with some failures) or No Action (if executed, but no actions needed to be taken).
Default CA for SCEP Aliases
If the alias being used is operating in RA mode and the message parameter is not specified in the SCEP request, the SCEP operations GetCACert, GetCACertChain, GetNextCACert and GetCACaps use the RA CA name defined by the alias, instead of relying on the scep.defaultca property. This allows for more flexibility and easier configuration for deployments where editing configuration files is inconvenient or not possible.
The old behavior for determining the CA name to use was as follows:
If a message was sent, use the CA specified by the message.
If no message was sent, use the CA specified by the property scep.defaultca.
As of EJBCA 7.2, the name of the CA to use is computed as follows:
If a message was sent, use the CA specified by the message.
If the alias is in RA mode and no message is sent, use the RA CA name specified by the alias.
If the alias is in CA mode, the property scep.defaultca is defined, and no message is sent, use the CA specified by the property scep.defaultca.
If the alias is in CA mode, the property scep.defaultca is not defined, and no message is sent, produce an error.
For more information, see SCEP.
Certificate Transparency
Persistent Caching
Persistent caching of Certificate Transparency SCTs (Signed Certificate Timestamps) has been added in addition to the existing in-memory caching. This adds a new table, SctData for storing cached SCT data. Please ensure this table exists if you use Certificate Transparency.
As there can be several SCTs per certificate, the SctData table will grow large over time. Therefore, we strongly recommend creating an index on the fingerprint column. Refer to doc/sql-scripts/create-index-ejbca.sql for an SQL command to create the index.
Non-Functional Logs Caching (fast fail)
The "fast fail" cache is now enabled by default. For details, see EJBCA 7.2 Release Notes.
Please make sure that only CAs that are trusted by the CT logs are used in certificate profiles where CT is enabled. If a certificate issued by an untrusted CA is submitted, the CT log will return an error, and EJBCA will consider the log to be non-functional (for all CAs, not just the untrusted one).
To disable the "fast fail" cache, set the property ct.fastfail.enabled to false in the file conf/cesecore.properties.
For more information, see Certificate Transparency.
Post Upgrade
When upgrading to EJBCA 7.2.0, you must perform a post-upgrade after all nodes have been upgraded. The post-upgrade is required because of an improvement allowing custom certificate start time/end time to be set with seconds granularity. The time value was previously saved with minutes granularity.
To perform the post-upgrade, click the EJBCA System Upgrade menu option, and then click Start post-upgrade. For more information, see Upgrading EJBCA.