問題描述

看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