Using random hexadecimal strings for passwords can cause the build and install process to fail

[sbarnes-tecnica]

Describe the Bug
I'm in the process of writing a build script to install and deploy EJBCA CE (8.2.0.1) under Wildfly (26.1.3) running with Java 11.

Following the documentation for configuring Wildfly and EJBCA I discovered an issue when generating random secure passwords for the truststore between EJBCA and Wildfly.

If the password I generate is all hexadecimal characters and the length is a multiple of 32, the underlying library (cesecore-common/src/org/cesecore/util/StringTools.java) interprets this password as being already encrypted, and throws the following exception from the passwordDecryption function:

Password decryption failed. 'password.encryption.key' might have been modified more than once.

To Reproduce
From a fresh server:

1. Download and install all dependencies (database of choice, OpenJDK 11)
2. Download, install, and start up Wildfly
3. Select two random hexadecimal strings (length a multiple of 32) for your Java trust password and https server password and run the following:

/opt/wildfly/bin/jboss-cli.sh --connect "/subsystem=elytron/credential-store=defaultCS:add-alias(alias=httpsKeystorePassword, secret-value=3cc7603d8cee5e1284e95c5ef2d47ca17a4cb2767776297951f336fde2d63bac)"
/opt/wildfly/bin/jboss-cli.sh --connect "/subsystem=elytron/credential-store=defaultCS:add-alias(alias=httpsTruststorePassword, secret-value=c13d297c7ba2d8f10563fa8c782decc089231f1678f4c2faf014bb40e2f152e8)"

4. Configure the following in web.properties:

httpsserver.password=3cc7603d8cee5e1284e95c5ef2d47ca17a4cb2767776297951f336fde2d63bac
java.trustpassword=c13d297c7ba2d8f10563fa8c782decc089231f1678f4c2faf014bb40e2f152e8

5. Run the following from $EJBCA_HOME

ant -q clean deployear
ant runinstall

6. These commands will fail and give the above error

Expected Behavior

If the failure to decrypt is expected and desired behaviour, maybe there could be a simple check on the values in web.properties can alert the user rather than cryptically fail.

Product Deployment

Please complete the following information:

• Server OS: Ubuntu 22.04 LTS
• Java: openjdk 11.0.22
• Wildfly Version: 26.1.3
• EJBCA-CE Version: 8.2.0.1

Workaround
If you're going to use random hex passwords to protect the trust stores, use any value whose length isn't a multiple of 32.

[primetomas]

Thanks, it's something to investigate certainly. It is due to legacy backwards compatibility, the punishment for being able to work with 15 year old data. Newer data have more data in the encrypted string (algorithm, salt and such), but really really old didn't.

There are many options:

• you of course worked around it by modifying the string, so there is no critical issue, it's possible to leave it like that
• add code to assume that if decryption failed the last time, assume that it's supposed to be like that
• remove the backwards compatibility for really old data

Do you have any preferences?

[sbarnes-tecnica]

I'd say that without any other context the second option makes most sense to me, possibly with a final check to see if the provided value is the trust store password itself without modification.

Alternatively, a more explicit error message might be enough.

This could come up even with values that aren't (completely) randomly generated, if for some reason a user decided to use a pre-generated 128 or 256-bit AES key (196-bit would be fine as the length would be 48 characters).

[primetomas]

The passphrase is used to derive a symmetric cryptographic key, i.e. AES. So using an AES key as input is not recommended, i.e. you don't use an AES key to derive an AES key. A (random) alphanumerical string utilizing the full character set is a much better option.

[primetomas]

I think the best I can do right now is to add documentation about this to:
https://doc.primekey.com/ejbca/ejbca-installation/managing-ejbca-configurations
This has been done for the next release.