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. 

Changes

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

EjbcaWS.getRemainingNumberOfApprovals

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
	 * 
	 */
JAVA

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
	 * 
	 */
JAVA

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.

EjbcaWS.getProfiles

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:

  • /ra_functionality/view_end_entity_profiles

  • 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:

  • /ca_functionality/view_certificate_profiles

  • 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.