Listed in this document are important changes and upgrade requirements from EJBCA 6.13 to EJBCA 6.14. For detailed upgrade instructions and information on upgrade paths, see Upgrading EJBCA. For full details of the new features and improvements in this release, see the EJBCA 6.14 Release Notes.
Access Rules Changes
The access rule requirements for generating CSRs from the UI for internal keybindings have been change from /cryptotoken/keys/generate/ to /cryptotoken/use/ in order allow for these roles to be separated.
Changes to EJBCAWS
The method org.ejbca.core.protocol.ws.common.IEjbcaWS.getRemainingNumberOfApprovals(int) has changed behavior slightly in order to conform to real world requirements. The previous javadoc stated that
/** * * @param requestId the ID of an approval request * @return the number of remaining approvals required, or STATUS_REJECTED (-1) if request was rejected * @throws ApprovalException if a request of the given ID didn't exist * @throws AuthorizationDeniedException if the current requester wasn't authorized. * @throws ApprovalRequestExpiredException if sought approval request has expired * */
This was incorrect as ApprovalDataVO.STATUS_REJECTED is actually -2. In order to stay true to the API we have changed the return value to be -1 for rejected results. The new javadoc states as following:
/** * * @param requestId the ID of an approval request * @return the remaining number of approvals for this request (with 0 meaning that the request has passed) or -1 if the request has been denied * @throws ApprovalException if a request of the given ID didn't exist * @throws AuthorizationDeniedException if the current requester wasn't authorized. * @throws ApprovalRequestExpiredException if approval request was expired before having a definite status * */
The additional change is that the older implementation would throw an exception for approvals that had expired after being approved. Since 6.14 this method will return 0 if the approval has passed (or -1 if it has been rejected), even if it has since then expired.
This method was found to potentially leak information about end entity profiles and CA ID's that the requesting admin wasn't authorized to. If requesting an End Entity Profile, the requesting user must be authorized to the following rules:
- to any CAs that are referenced in the EEP
- to any CAs that are referenced in any Certificate Profiles referenced to in the EEP
If requesting a Certificate Profile, the requesting user must be authorized to the following rules:
- to any CAs that are referenced in the Certificate Profile
100% Uptime Notes
Upgrading CAA Validators
A minor bug was found in 6.13 where the list of ignored Top Level Domains was reduced to a single entry if the validator has been edited or saved. EJBCA will automatically upgrade the validators when they are edited in 6.14, but for this reason it's required that CAA Validators are not edited during the upgrade. Besides that, CAA Validators will otherwise function entirely as normal.