How to use Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files


Your build may encounter an issue if you use the Java Cryptography API, claiming “the requested algorithm is not available”. Some higher-level frameworks are even friendlier and give you the root cause:

Caused by: org.jasypt.exceptions.EncryptionOperationNotPossibleException: Encryption raised an exception. A possible cause is you are using strong encryption algorithms and you have not installed the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files in this Java Virtual Machine

To conform to US export policy we cannot deploy the JCE Unlimited Strength policy files with the JDKs we have installed on DEV@cloud build slaves.



Workaround #1

A workaround for you is to clone the installed JDK and patch it with JCE policy files you can download from the Oracle website (bottom of the download page). Upload the archive content to your private repository on CloudBees Forge.

Next, go to your Jenkins global configuration and create a new “JDK installation” that will be JCE-enabled. Give it whatever name makes sense to you, such as *JDK 7 with JCE*. You must deselect the option to have this JDK be installed automatically, and enter an explicit installation directory under /home/jenkins, such as /home/jenkins/jdk7jce. (You will see a warning that this directory does not yet exist; ignore it.)


Now for each project which will require the JCE, you will need to make two configuration changes. First, select your new JDK from the dropdown. Next, add a build step (*before* any other build steps in the project) using a shell script which will copy an existing JDK installation into the expected location, splicing in your local_policy.jar and US_export_policy.jar files:

if [ \! -d $JAVA_HOME ]
    cp -a $(readlink -f /opt/jdk/jdk1.7.latest) $JAVA_HOME
    cp /private/*/jce/* $JAVA_HOME/jre/lib/security

(In this example, we are copying the “JDK 7 (latest)” installation provided on all standard build slaves. For other JDK versions, you would need to pick a different origin path in /opt/jdk.)

Be sure to configure your Build Environment so that you have checked the “Mount CloudBees DEV@cloud Private WebDav Repository” option.

Now when your project runs for the first time on a given slave, it will copy the limited JDK and add in the JCE. On that and subsequent builds, $JAVA_HOME should include the JCE.

Workaround #2

If you want a solution independent of our private repository on CloudBees Forge (for example if you need to use it with On-Premise slaves too) you can use a custom installer script for the JDK. You may also have a look at our instruction to setup a JDK Automatic installation for Zulu® (Multi-platform Certified OpenJDK™) and use it to download your patched JDK from another location.

Have more questions? Submit a request


Please sign in to leave a comment.