NoSuchAlgorithmException: Algorithm HmacSHA1 not available

Look at the following line of java:

Mac.getInstance("HmacSHA1");

If I put this in a simple test program, it runs without problems on my server. However, if I use this line in a container, I get

java.security.NoSuchAlgorithmException: Algorithm HmacSHA1 not available
  at javax.crypto.Mac.getInstance(DashoA13*..)

The same JDK installation is used in both cases.

After googling around a bit, I managed to get it to work by doing two things:

1. Copying sunjce_provider.jar from $JAVA_HOME/jre/lib/ext to the lib directory of the container.

2. Adding the following line to my code:

   java.security.Security.addProvider(new com.sun.crypto.provider.SunJCE());

Specifically, this happens to me in an Apache James mailet, but I'm pretty sure this is has to do with JVM options. Here is the startup script that it uses.

Although I got 开发者_如何学Cit to work in the end, the solution feels too hacked to be the right one. I would appreciate an explanation of what is going on, as well as a more "proper" solution.

Related question: Using Java crypto leads to NoSuchAlgorithmException. However, in this case I'm pretty sure the HmacSHA1 algorithm should be supported out of the box. As evidence, this works without problems in a test program.

The startup script sets the java.ext.dirs to its own set of directories (specific to the application) but omitting the "normal" extension directory ($JAVA_HOME/jre/lib/ext/) which is where sunjce_provider.jar resides. This explains your first point (copying the Jar file to the lib directory makes it visible again). This is easily reproduced.

As for the second point, I think this is due the policy file that the startup script sets with the -Djava.security.policy option. Whether some providers are available or not depends on policy files. The default policy file makes the SunJCE provider available, but since the startup scripts mandates a non-default, custom policy file, then anything goes. I suggest you take a look at that policy file.

For instance, on my system (Ubuntu Linux, with Sun JVM 1.6.0_20 as packaged by Ubuntu), the default policy file is in /etc/java-6-sun/security/java.security and contains (among others) the following lines:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.6=com.sun.security.sasl.Provider
security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.8=sun.security.smartcardio.SunPCSC

which define what providers should be available by default. From your symptoms, I think that the custom policy file made SunJCE unavailable unless explicitly registered (which is understandable since the startup script also removed the access to the Jar file containing SunJCE...).

The correct shortened form is as below

HmacMD5
HmacSHA1
HmacSHA256

It was shortened to SHA1, MD5, and SHA256

Try to change the Java version

I was getting exception NoSuchAlgorithmException: "Unable to obtain JCA MAC algorithm 'HmacSHA512'" on following Java version:

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

After changing the JDK version to following the issue was resolved:

java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

The required jar for this issue is sunjce_provider.jar it is possible that it might be corrupt.

I was getting the same error, and when was trying to list all my keys I was not noticing an error:

"The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /Users/matua/.keystore -destkeystore /Users/matua/.keystore -deststoretype pkcs12".

So what I did was changing a keystone type to PKCS #12 instead of JKS and all went smooth. I used KeysStore Explorer 5.4.4 to generate keystore via GUI.