java - 设置哪个权限，以避免使用 https-URLS 的安全管理器出错？

Question

在面向客户的软件中，我们必须读取给定的 URL 来解析其内容。此外，客户需要激活 Tomcat-Security-Manager 以让 Java-Policies 控制程序的功能。

现在，读取 URL 时会发生异常“javax.net.ssl.SSLKeyException: RSA premaster secret error”，但仅在某些条件下发生:

如果 URL 是 HTTPS 而不是 HTTP

如果安全管理器被激活，而不是在它被停用或
如果在全局授权阻止中设置了 AllPermission

仅适用于 Java 6，不适用于 Java 7(客户目前需要 Java 6)

仅适用于 Tomcat6，不适用于 Tomcat 7(客户目前需要 Tomcat 6)

安全违规发生在 Java 代码的某处，仅限于我们的代码库的 AllPermission 并不能防止错误。

那么，有没有人有想法，为Java 6设置哪个权限，以便它可以处理HTTPS？

其他信息:它在带有 OpenJDK 的 Debian-Linux 上的 tomcat 中运行。

编辑:我在变量 JAVA_OPTS 中向 Tomcats/etc/default/tomcat6 添加了 Java 参数“-Djava.security.debug=access,failure”。但是在日志中我没有其他消息。代码是否有可能在触发权限之前询问权限？

EDIT2:我找到了正确的位置并获得了完整的堆栈跟踪(删除了特定的客户部分):

javax.net.ssl.SSLKeyException: RSA premaster secret error

            at [...]
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at java.lang.Thread.run(Thread.java:701)
    Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available
            at javax.crypto.KeyGenerator.<init>(KeyGenerator.java:141)
            at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:191)
            ... 14 more

EDIT3:到目前为止，我一直假设 Java 类 URL 用于访问资源的内容。但这是不真实的。它使用 Grails-Code 中的 Groovy-URL-object 和 getText() 方法:

new URL(params.url).text

错误发生在这条线上。这是 Grails 版本 2.2.4。

Answer 1

几个评论和OP确认解决方案后的解决方案(总结)
根本原因是存在 sunjce_provider.jar在多个位置。这是在被建议为许多可能的根本原因之一后被 OP 发现的(请参阅此答案的最后部分和评论线索)。根据 OP 的评论:

I have the sunjce_provider.jar in multiple directories. I tried to give all three locations for Java 6 the rights, although clearly only one is JAVA_HOME - and it worked. Somehow one of the other locations is used, although it isn't in the java.ext.dirs-property

因此，在这种情况下的解决方案是确保应用程序有权访问 sunjce_provider.jar 的正确副本。
我已经从我的原始答案中留下了要点，并为以后发现这一点的任何人留下了有助于诊断的评论
导致解决方案的原始答案和评论

http 不会发生这种情况因为您的 Web 应用程序(即此连接的客户端，即使它在 tomcat 中运行)，不需要在此配置中生成 key 。

它仅在启用 SecurityManager 时发生，但在禁用或使用全局 AllPermission 时不会发生，这表明它是一个文件权限错误。它表明 key 长度没有问题(例如 mentioned here )

其他 similar报告 on web表明可能的根本原因是缺少 jar(通常引用 sunjce_provider.jar)。堆栈跟踪确认根本原因异常是 NoSuchAlgorithmException哪里 KeyGenerator正在寻找算法 SunTlsRsaPremasterSecret并且找不到。在您的情况下，因为这只发生在特定的 SecurityManager 上。配置，可能是 无法访问 jar(由于安全权限)。
我的猜测是您还没有启用 grant codeBase包含 RSA key 生成算法所需的 jar 的正确目录的权限。我建议的行动方案是通过您的 webapp 和 JRE 目录结构来查找运行时 jar 的保存位置并确保它们具有权限 grant编入 catalina.policy .
在默认配置中 - 例如 - 你应该在某处看到

// These permissions apply to all shared system extensions
grant codeBase "file:${java.home}/jre/lib/ext/-" {
        permission java.security.AllPermission;
};

有关这究竟意味着什么的详细信息，请参阅 this section的 tomcat 安全管理器“如何”。您需要检查几件事 - 确保 ${java.home}/jre/lib/ext/是您的运行时 jar 所在的位置。如果不是 - 更改路径以指向正确的位置(它 是 它们在我的 OpenJDK 6 版本中的位置 - 构建 27)。特别是你应该看到 sunjce_provider.jar和 sunpkcs11.jar在那里。确保上述部分存在于您的策略文件中。
可能是代码取决于您的 webapp 中的一些 jars - 例如在 ${catalina.base}/path/to/your/webapp/WEB-INF/classes/ - 在这种情况下，您需要授予该目录的权限。

导致相同或相似症状的其他问题

该应用程序无法找到或访问 sunpkcs11.jar将给出相同的错误消息(在 Ubuntu+openjdk6+tomcat6 系统上验证)。那个 jar 的重复副本很可能也会。

检查 /etc/java-6-openjdk/security/java.security .它应该在那里列出提供者 - 检查是否有类似 security.provider.n = sun.security.pkcs11.SunPKCS11 的行在那里 - 如果缺少该行，您也会收到此错误(在同一系统上验证)

此 Debian bug report讨论在 SecurityManager 下运行时 jars 的位置问题

调试注释
根据其他答案，您可以尝试添加 -Djava.security.debug=access,failure至 CATALINA_OPTS或 JAVA_OPTS在您的 catalina.sh 中启用调试 - 应该登录到 catalina.out默认情况下(或您在 catalina.sh 中通过 CATALINA_OUT 设置日志记录的任何位置。您应该在那里看到 SecurityManager 的输出。
你也可以试试 -Djava.security.debug=all. You will get a huge catalina.out`，但您可以搜索可能有帮助的单词(例如“失败”!!!)

遵循堆栈跟踪中的代码
您的异常被抛出 here .查看如何抛出该异常 - this method必须返回空值。它 swallows Exception s - 这不是很好，并且很难准确诊断该代码的哪一部分失败。我的钱会放在 this line - 哪里 canUseProvider() 可能会返回 false .这一切都指向由于某种原因无法访问提供程序 jar。
我假设您没有在输出中看到任何访问冲突，即使是 -Djava.security.debug=access,failure .你可以试试 -Djava.security.debug=all ，尽管这很可能只会产生更多不相关的日志记录。如果没有访问冲突，您 5 月 以某种方式在您的类路径上有该 jar 的两个版本，并且运行时正在访问(或尝试访问错误的一个)。此 Q/A 中描述了与此类似的案例。 .