問題描述

看java的下面一行:

Look at the following line of java:

Mac.getInstance("HmacSHA1");

如果我把它放在一個(gè)簡單的測試程序中，它在我的服務(wù)器上運(yùn)行沒有問題.但是，如果我在容器中使用這條線，我會(huì)得到

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.

在谷歌上搜索了一下之后，我通過做兩件事設(shè)法讓它工作:

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復(fù)制到容器的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());

具體來說，這發(fā)生在我的 Apache James 郵件中，但我很漂亮確定這與 JVM 選項(xiàng)有關(guān).這里是啟動(dòng)腳本 它使用.

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.

雖然我最終得到了它的工作，但這個(gè)解決方案感覺太老套了，無法成為正確的解決方案.我將不勝感激對(duì)正在發(fā)生的事情的解釋，以及更適當(dāng)"的解決方案.

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.

相關(guān)問題:使用Java加密導(dǎo)致NoSuchAlgorithmException.但是，在這種情況下，我很確定應(yīng)該支持開箱即用的 HmacSHA1 算法.作為證據(jù)，這在測試程序中沒有問題.

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.

推薦答案

啟動(dòng)腳本將 java.ext.dirs 設(shè)置為其自己的目錄集(特定于應(yīng)用程序)，但省略了"normal" 擴(kuò)展目錄 ($JAVA_HOME/jre/lib/ext/)，它是 sunjce_provider.jar 所在的位置.這解釋了您的第一點(diǎn)(將 Jar 文件復(fù)制到 lib 目錄使其再次可見).這很容易復(fù)制.

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.

至于第二點(diǎn)，我認(rèn)為這是由于啟動(dòng)腳本使用 -Djava.security.policy 選項(xiàng)設(shè)置的策略文件所致.某些提供程序是否可用取決于策略文件.默認(rèn)策略文件使 SunJCE 提供程序可用，但由于啟動(dòng)腳本要求使用非默認(rèn)的自定義策略文件，因此一切正常.我建議你看看那個(gè)策略文件.

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.

例如，在我的系統(tǒng)上(Ubuntu Linux，Ubuntu 打包的 Sun JVM 1.6.0_20)，默認(rèn)策略文件在 /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