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.