NoSuchAlgorithmException：算法 HmacSHA1 不可用
看一下 java 的以下行：
Mac.getInstance("HmacSHA1");
如果我将其放入一个简单的测试程序中，它在我的服务器上运行没有问题。但是，如果我在容器中使用此行，则会
java.security.NoSuchAlgorithmException: Algorithm HmacSHA1 not available
at javax.crypto.Mac.getInstance(DashoA13*..)
在两种情况下使用相同的 JDK 安装。
经过一番谷歌搜索后，我设法通过做两件事让它工作：
- 将
sunjce_provider.jar从$JAVA_HOME/jre/lib/ext复制到 lib 目录容器。 将以下行添加到我的代码中：
java.security.Security.addProvider(new com.sun.crypto.provider.SunJCE());
具体来说，这发生在我身上 Apache James mailet，但我很确定这与 JVM 选项有关。 这是启动脚本< /a> 它使用的。
虽然我最终让它工作了，但这个解决方案感觉太糟糕了，不是正确的解决方案。我希望能够解释正在发生的事情，以及更“正确”的解决方案。
相关问题：使用Java加密导致NoSuchAlgorithmException 。然而，在这种情况下，我非常确定 HmacSHA1 算法应该得到开箱即用的支持。作为证据，这在测试程序中没有问题。
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:
- Copying
sunjce_provider.jarfrom$JAVA_HOME/jre/lib/extto the lib directory of the container. 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 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.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
启动脚本将 java.ext.dirs 设置为其自己的一组目录（特定于应用程序），但省略“正常”扩展目录（$JAVA_HOME/jre/lib/ext/ ），这是
sunjce_provider.jar所在的位置。这解释了您的第一点（将 Jar 文件复制到 lib 目录使其再次可见）。这很容易复制。至于第二点，我认为这是由于启动脚本使用
-Djava.security.policy选项设置的策略文件所致。某些提供程序是否可用取决于策略文件。默认策略文件使 SunJCE 提供程序可用，但由于启动脚本强制使用非默认的自定义策略文件，因此一切正常。我建议您看一下该策略文件。例如，在我的系统（Ubuntu Linux，由 Ubuntu 打包的 Sun JVM 1.6.0_20）上，默认策略文件位于
/etc/java-6-sun/security/java.security中包含（除其他外）以下几行：定义默认情况下可用的提供程序。从您的症状来看，我认为自定义策略文件使 SunJCE 不可用，除非显式注册（这是可以理解的，因为启动脚本还删除了对包含 SunJCE 的 Jar 文件的访问...）。
The startup script sets the
java.ext.dirsto its own set of directories (specific to the application) but omitting the "normal" extension directory ($JAVA_HOME/jre/lib/ext/) which is wheresunjce_provider.jarresides. 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.policyoption. 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.securityand contains (among others) the following lines: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...).
正确的缩写形式如下
添加到上面，keycloak 在其 UI 上显示为
SHA1、SHA256等，但如果您从浏览器检查，它实际上是在更新这些值HmacSHA1、HmacSHA256代码>The correct shortened form is as below
To add to above, keycloak displays as
SHA1, SHA256etc on it's UI but if you inspect from browser, it is actually updating these valuesHmacSHA1, HmacSHA256它被缩短为 SHA1、MD5 和 SHA256
It was shortened to SHA1, MD5, and SHA256
尝试更改 Java 版本，
我在以下 Java 版本上遇到异常
NoSuchAlgorithmException：“无法获取 JCA MAC 算法 'HmacSHA512'”：将 JDK 版本更改为以下版本后，问题得到解决：
此问题所需的 jar 是
sunjce_provider.jar，它可能已损坏。Try to change the Java version
I was getting exception
NoSuchAlgorithmException: "Unable to obtain JCA MAC algorithm 'HmacSHA512'"on following Java version:After changing the JDK version to following the issue was resolved:
The required jar for this issue is
sunjce_provider.jarit is possible that it might be corrupt.我遇到了同样的错误，当尝试列出所有密钥时，我没有注意到错误：
“JKS 密钥库使用专有格式。建议使用“keytool -importkeystore”迁移到 PKCS12，这是一种行业标准格式-srckeystore /Users/matua/.keystore -destkeystore /Users/matua/.keystore -deststoretype pkcs12”。
所以我所做的是将梯形校正类型更改为 PKCS #12 而不是 JKS，一切都很顺利。
我使用 KeysStore Explorer 5.4.4 通过 GUI 生成密钥库。
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.