NoSuchAlgorithmException：算法HmacSHA1不可用 [英] NoSuchAlgorithmException: Algorithm HmacSHA1 not available

问题描述

看看下面这行java：

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*..)

使用相同的JDK安装在这两种情况下。

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. 将 sunjce_provider.jar 从 $ JAVA_HOME / jre / lib / ext 复制到lib目录

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（））;

具体来说，这发生在我在 Apache James mailet中，但我很确定这个是与JVM选项有关。 这里是启动脚本。

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 it 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.

相关问题：使用Java crypto导致NoSuchAlgorithmException 。但是，在这种情况下，我很确定HmacSHA1算法应该支持开箱即用。作为证据，这在测试程序中没有问题。

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.

推荐答案

启动脚本设置 java。 ext.dirs 到其自己的目录（特定于应用程序），但省略正常扩展目录（ $ JAVA_HOME / jre / lib / ext / ），其中 sunjce_provider.jar 驻留。这解释了你的第一点（将Jar文件复制到lib目录，使它再次可见）。这很容易被复制。

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.

至于第二点，我认为这是由于启动脚本用 -Djava设置的策略文件。 security.policy 选项。某些提供程序是否可用取决于策略文件。默认策略文件使SunJCE提供程序可用，但由于启动脚本强制使用非默认的自定义策略文件，因此任何情况都会发生。我建议你看看这个策略文件。

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.

例如，在我的系统（Ubuntu Linux，Ubuntu打包的Sun JVM 1.6.0_20）策略文件位于 /etc/java-6-sun/security/java.security 中，并包含以下行：

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

其中定义了默认。从您的症状，我认为自定义策略文件使SunJCE不可用，除非显式注册（这是可以理解的，因为启动脚本也删除了包含SunJCE的Jar文件的访问...）。

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...).

这篇关于NoSuchAlgorithmException：算法HmacSHA1不可用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！