EJBCA 6.0.x to EJBCA 6.1.y
For details of the new features and improvements in the releases, see the EJBCA Release Notes.
EJBCA 6.1.x to EJBCA 6.1.y
See the procedure, and notes, for upgrading from 6.0.x to 6.0.x.
In EJBCA 6.1.2, the SCEP configuration handling has been rewritten. SCEP configurations are no longer read from conf/scep.properties file, instead, SCEP configurations will be set through the command line (execute './bin/ejbca.sh config scep' from EJBCA home directory for command line documentation).
If you do use SCEP, you need to upload your old scep.properties file to EJBCA after upgrade. You can do that by executing the following command in EJBCA home directory:
./bin/ejbca.sh config scep uploadfile conf/scep.properties scep
The new URL will be: http://HOST:PORT/ejbca/publicweb/apply/scep/CONFIGURATION_ALIAS/pkiclient.exe
It you use the URL: http://HOST:PORT/ejbca/publicweb/apply/scep/noca/pkiclient.exe
You need to set the property 'ALIAS.includeca' to 'false' in the command line by executing the followingfrom EJBCA home directory:
./bin/ejbca.sh config scep updatealias ALIAS includeca false
If you are using External RA, please note that the name of the scep.properties file has been changed to scepra.properties
EJBCA 6.0.x to EJBCA 6.1.x
Upgrade from EJBCA 6.0 to 6.1 consists of a simple database change in the table KeyRecoveryData. If the database user used for EJBCA has alter table privileges the upgrade will be done automatically when deploying the new version of EJBCA (plug-in upgrade) and starting JBoss. If you prefer to do the database upgrade manually, see src/upgrade for SQL scripts for your specific database.
100% up-time upgrade notes
There should be no issues moving between EJBCA 6.0 and 6.1, older versions of EJBCA will run with the additional database columns added to KeyRecoveryData.
If you had existing KeyrecoveryData, you need to set the new column cryptoTokenId to 0 (see src/upgrade/600_610).
update KeyRecoveryData set cryptoTokenId=0;
Since EJBCA 6.1.0 OCSP responses no longer include the Root CA Certificate, unless the Root CA is the OCSP signer, and it is configured to include the signer certificate. Having OCSP responses as small as possible is an important performance feature, and since the client must have the root certificate as trusted there is no need to include the root certificate in the chain.
If you get a "java.lang.NoSuchMethodError" in the admin GUI it is because JBoss (5) does not clean temporary files very well. Delete the directories JBOSS_HOME/server/default/tmp and JBOSS_HOME/server/default/work and restart JBoss to get it working.