NoSuchAlgorithmException:算法 HmacSHA1 不可用

问题描述

看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. 将$JAVA_HOME/jre/lib/ext中的sunjce_provider.jar复制到容器的lib目录中.

2. 将以下行添加到我的代码中:

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 邮件中，但我很漂亮确定这与 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加密导致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 设置为其自己的目录集(特定于应用程序)，但省略了"normal" 扩展目录 ($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 并包含(除其他外)以下几行:

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