EJBCA 6.4 Upgrade Notes
EJBCA 6.3.2 to EJBCA 6.4.2
The following lists important notes on upgrading to EJBCA 6.4.x versions:
For upgrade instructions and information on upgrade paths, see Upgrading EJBCA.
For details of the new features and improvements in the releases, see the EJBCA Release Notes.
EJBCA 6.4.0 to EJBCA 6.4.2
EJBCA 6.4.2 adds a couple of additional rules to any existing Auditors introduced since 6.4.0, as well as their analogs (i.e. an admin with edit rights will be given view rights as well). This upgrade will happen automatically and the database version will be set to 6.4.2.
The changes will be as follows. Any roles matching up to the 6.4.0 Auditors will be given the full set of rules, while non-auditors will be handled as follows:
Currently accessed rules |
Future accessed rules |
/system_functionality/edit_systemconfiguration |
/system_functionality/view_systemconfiguration |
/system_functionality/edit_available_extended_key_usages |
/system_functionality/view_available_extended_key_usages |
/system_functionality/edit_available_custom_certificate_extensions |
/system_functionality/view_available_custom_certificate_extensions |
/system_functionality/edit_administrator_privileges |
/system_functionality/view_administrator_privileges |
Auditors will receive all of the above rules, in addition to:
/ra_functionality/view_end_entity
The additional pages available to the Auditor are the following:
Search End Entities
Administrator Roles
CMP Configuration
SCEP Configuration
System Configuration
EJBCA 6.3.2 up to EJBCA 6.4.0
Upgrading to 6.4.0 will require some minor additions of access rules, which will be performed in post-upgrade. All additions create more granularity, so while role will be given access to anything they didn't have before the upgrade, rules can be restricted manually after the upgrade to make access control more restrictive.
New Access rules for Auditors
A new default Role has been added named "Auditor", which is a role which has view access to all pages but not rights to make any changes or perform any actions. Some new rules had to be added to accommodate this role, and authorization to certain GUI pages has been made more fine grained as a result. During upgrade, all roles which previously had access rights using the previous rules will automatically be given access to the new rule. These are as follows:
Any roles which had access to: Now also have access to:
/ca_functionality/basic_functions/activate_ca or /ca_functionality/view_ca
/ca_functionality/ (recursive)
/ca_functionality/edit_certificate_profiles /ca_functionality/view_certificate_profiles
/ca_functionality/edit_publisher /ca_functionality/view_publisher
/ra_functionality/edit_end_entity_profiles /ra_functionality/view_end_entity_profiles
/ /services/edit and /services/view
/internalkeybinding /internalkeybinding/view (recursive)
The pages that will be available to this new role are the following:
CA Activation
CA Structure & CRLs
Certificate Profiles Certificate Profiles previously not accessible (due to lack of access to CAs or
root access) will be rendered view only.
Certification Authorities All CA's will now be listed (instead of only the ones which the admin had access to, but
ones without access will be greyed out.
End Entity Profiles
Publishers
Crypto Tokens
Services
Internal Key Bindings
XKMS no longer supported
Support for XKMS was removed and is no longer available. When upgrading to EJBCA 6.4.0, internal keystores for XKMS will be removed and is upgrading in a 100% uptime cluster, the XKMS option in older versions of EJBCA will also disappear.
Extended Key Usages and Custom Certificate Extension are imported to the database from the previously static configuration files:
The configuration files 'extendedkeyusage.properties' and 'certextensions.properties' are automatically read into EJBCA database during deployment of the new code. Future changes to Extended Key Usages and Custom Certificate Extensions will have to be done through the AdminGUI under 'System Configuration'->'Extended Key Usages' and 'System Configuration'->'Custom Certificate Extensions'
In the case of Custom Certificate Extension, only the extensions with 'id<ID>.used=true' are imported into the database. Please note that extensions related to OCSP responses are not effected. Only the handling the content of 'extendedkeyusage.properties' and 'certextensions.properties' files is effected.
New Access rules to update Extended Key Usages and Custom Certificate Extensions
New Access Rules has been added to add, remove or edit Extended Key Usages and Custom Certificate Extensions. During upgrade, all roles which previously had the access right '/system_functionality/edit_systemconfiguration', will automatically be given access to the new rules '/system_functionality/edit_available_extended_key_usages' and '/system_functionality/edit_available_custom_certificate_extensions'
Changes to Custom Certificate Extensions
Several changes have been implemented in how Custom Certificate Extensions are handled:
Available Custom Certificate Extensions are no longer limited to only 255 extensions: The limitation on how many Custom Certificate Extensions EJBCA can have available at one time has now been removed.
Used Custom Certificate Extensions in a Certificate Profile are now identified by their OIDs: The Used Custom Certificate Extensions in a Certificate Profile used to be a list of numbers representing the extensions' IDs. This has now been changed to a list of Strings representing the extensions' OIDs instead. This is done by adding a new field containing the OIDs of the Used Custom Certificate Extensions. The field containing the list of IDs is not changed, but all functions are now referencing the new field containing the list of OIDs. This way, an older version of EJBCA can still work on a newer database content without disrupting any functions.
Custom Certificate Extensions must implement the CustomCertificatExtension marker interface