Java 避免安全级别的阻塞而不在例外站点列表中添加 url
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/27564307/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Avoid security level blocking without adding url in exception site list
提问by Java
I have created Java signed applet, it runs perfectly if I set my Java(JRE 8) security levelhighand add my site urlin exception site list.
我已经创建了 Java signed applet，如果我将Java(JRE 8) 安全级别设置为高并将我的站点 url添加到异常站点列表中，它可以完美运行。
But if we do not add site url in exception site list, java security exception comes as explained here : add url in exception site list
但是如果我们没有在异常站点列表中添加站点 url，java 安全异常就会出现在这里：在异常站点列表中添加 url
I have created a signed applet using a third part certificate.
我使用第三方证书创建了一个签名小程序。
Here is my manifest file after creating signed applet:
这是创建签名小程序后的清单文件：
Is there any option available to avoid these security blocking popupsby adding some changes in manifest file while creating signed applet, or any script, java code to avoid these popups without adding site url in exception site list?
是否有任何选项可以通过在创建签名小程序时在清单文件中添加一些更改来避免这些安全阻止弹出窗口，或任何脚本、java 代码来避免这些弹出窗口，而无需在异常站点列表中添加站点 url？
Or is it really mandatory from Javathat we must need to add site url in exception site list to avoid such blocking error.
或者，我们必须在异常站点列表中添加站点 url 以避免此类阻塞错误，这是否真的是 Java 强制要求的。
Basically is there any option available to add our url in exception site list through manifest file or any Java code ?
基本上是否有任何选项可以通过清单文件或任何 Java 代码将我们的 url 添加到例外站点列表中？
Is it mandatory if I want to sign my applet using signed certificate then it must be a code signing certificate? wildcard or ssl certificate will not work?
如果我想使用签名证书签署我的小程序，它是否必须是代码签名证书？通配符或 ssl 证书将不起作用？
As I am getting self signed applet block issue though I have signed my applet with wildcard certificate.
虽然我已经用通配符证书签署了我的小程序，但我遇到了自签名小程序块问题。
回答by Andrea Baglioni
Try to modify manifest, adding your server name into caller-allowable-codebase. Probably you don't need to add your site url into exception anymore
尝试修改清单，将您的服务器名称添加到调用者允许的代码库中。可能您不再需要将您的网站网址添加到异常中
UPDATE:
更新：
This is an example of my manisfest file:
这是我的清单文件的一个例子：
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Application-Name: myApp
Name: MyName
Permissions: all-permissions
Created-By: 1.7.0_51 (Oracle Corporation)
Caller-Allowable-Codebase: MyServerName
Codebase: *
回答by alain.janinm
Or is it really mandatory from JAVA that we must need to add site url in exception site list to avoid such blocking error.
或者我们必须在异常站点列表中添加站点 url 以避免此类阻塞错误，这是否真的是 JAVA 的强制要求。
Basically yes. End users can disable the securoty popup, but you can't do it through you application. If you look at the Oracle documentation "Avoiding security dialogs". It's clearly stated that the securoty popup is an expected behaviour :
基本上是的。最终用户可以禁用安全弹出窗口，但您不能通过您的应用程序执行此操作。如果您查看 Oracle 文档“避免安全对话框”。明确指出安全弹出窗口是一种预期行为：
The Java Runtime will automatically warn the user about possible security sensitive issues. If you are confident that applications you use are safe, then it is possible to bypass security dialogs to simplify user experience. If a Java applet/webstart application is signed, a certificate security warning dialog box will pop up and the user must click the Run button to give all permissions to the code of application.
Java 运行时将自动警告用户可能存在的安全敏感问题。如果您确信您使用的应用程序是安全的，则可以绕过安全对话框以简化用户体验。如果对 Java 小程序/webstart 应用程序进行签名，则会弹出证书安全警告对话框，用户必须单击“运行”按钮以授予应用程序代码的所有权限。
And if you read the options to avoid the popup you wil see that they all imply modifying something on the end users computer.
如果您阅读避免弹出窗口的选项，您会发现它们都暗示在最终用户计算机上修改某些内容。
Here are the options (quoted from "Avoiding security dialogs"):
以下是选项（引自 “避免安全对话框”）：
User accepts the certificate used to sign the application and selects the check box Always trust content from this publisher. Then next time permissions will be granted to this application automatically (until the certificate expires or is removed from the trusted key store).
The certificate can be manually imported into the JRE trusted certificate store. To import the certificate using the Java Control Panel, choose the Security tab and select Certificates > Trusted Certificates. To import a certificate into the certificate store from the command line, use the keytool utility (in the JRE's bin folder).
Grant AllPermissions in the Java policy file located at ${user.home}/.java.policy, or point to any Java policy file which has AllPermissions in the $(JRE_HOME)/lib/security/java.security file. Permissions can be granted to all applications or restricted to a particular URL. See Default Policy Implementation and Policy File Syntax for more details on .java.policy.
用户接受用于签署应用程序的证书并选中始终信任来自此发布者的内容复选框。然后下次权限将自动授予此应用程序（直到证书过期或从受信任的密钥库中删除）。
可以手动将证书导入 JRE 受信任证书库。要使用 Java 控制面板导入证书，请选择“安全”选项卡并选择“证书”>“受信任的证书”。要将证书从命令行导入证书存储，请使用 keytool 实用程序（在 JRE 的 bin 文件夹中）。
在位于 ${user.home}/.java.policy 的 Java 策略文件中授予 AllPermissions，或指向 $(JRE_HOME)/lib/security/java.security 文件中具有 AllPermissions 的任何 Java 策略文件。权限可以授予所有应用程序或限制为特定 URL。有关 .java.policy 的更多详细信息，请参阅默认策略实现和策略文件语法。
回答by flup
Your application is considered to be self-signed because you've signed it with a certificate that's not intended for code signing. Self-signed applications are blocked with this nasty-looking popup:
您的应用程序被认为是自签名的，因为您已使用不用于代码签名的证书对其进行签名。自签名应用程序被这个难看的弹出窗口阻止：
You can prevent this popup, if you sign using a code signing certificate that's signed by a trusted certificate authority. Then the user will get a way nicer looking confirmation dialog that lists your name as the publisher of the application:
如果您使用由受信任的证书颁发机构签名的代码签名证书进行签名，则可以阻止此弹出窗口。然后用户将获得一个更好看的确认对话框，其中列出您的姓名作为应用程序的发布者：
See also Oracle's documentation on security dialogsfor a description of the dialogs and why and when they appear.
另请参阅 Oracle 关于安全对话框的文档，了解对话框的说明以及它们出现的原因和时间。
Take a look at the documentation on working with Signed RIAs, in particular 23.2 "Signing RIAs", for information on how to create a code signing certificate to sign your applet.
查看有关使用签名 RIA的文档，特别是 23.2“签名 RIA”，了解有关如何创建代码签名证书以签署小程序的信息。
A second nice link is http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html#5
第二个不错的链接是http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html#5
--UPDATE--
- 更新 -
What exactly makes a certificate a Code Signing Certificate?
究竟是什么使证书成为代码签名证书？
X.509 certificates may include key usage fields (KU's) and extended key usage fields(EKU's). These fields, when present, restrictthe valid usage of the certificate. The java plugin checks for the presence of these fields.
X.509 证书可能包括密钥使用字段 (KU) 和扩展密钥使用字段(EKU)。这些字段（如果存在）会限制证书的有效使用。java 插件会检查这些字段是否存在。
I've found the source code for the EndEntityCheckerthat performs this check.
我找到了执行此检查的EndEntityChecker的源代码。
/**
* Check whether this certificate can be used for code signing.
* @throws CertificateException if not.
*/
private void checkCodeSigning(X509Certificate cert)
throws CertificateException {
Set<String> exts = getCriticalExtensions(cert);
if (checkKeyUsage(cert, KU_SIGNATURE) == false) {
throw new ValidatorException
("KeyUsage does not allow digital signatures",
ValidatorException.T_EE_EXTENSIONS, cert);
}
if (checkEKU(cert, exts, OID_EKU_CODE_SIGNING) == false) {
throw new ValidatorException
("Extended key usage does not permit use for code signing",
ValidatorException.T_EE_EXTENSIONS, cert);
}
[...]
checkRemainingExtensions(exts);
}
The check methods look as follows:
检查方法如下所示：
/**
* Utility method checking if the extended key usage extension in
* certificate cert allows use for expectedEKU.
*/
private boolean checkEKU(X509Certificate cert, Set<String> exts,
String expectedEKU) throws CertificateException {
List<String> eku = cert.getExtendedKeyUsage();
if (eku == null) {
return true;
}
return eku.contains(expectedEKU) || eku.contains(OID_EKU_ANY_USAGE);
}
Note that if no KU or EKU is specified, the KU or EKU checker returns true. But if KU's are specified, the digital signatureKU should be one of them. Similarly, if any EKU's are specified, either the EKU code signing(identified by oid 1.3.6.1.5.5.7.3.3) or the EKU any usage(identified by oid 2.5.29.37.0) should be specified as well.
请注意，如果未指定 KU 或 EKU，则 KU 或 EKU 检查器返回 true。但如果指定了KU ，则数字签名KU 应该是其中之一。同样，如果指定了任何 EKU，则还应指定 EKU代码签名（由 oid 1.3.6.1.5.5.7.3.3 标识）或 EKU任何用法（由 oid 2.5.29.37.0 标识）。
Finally, the checkRemainingExtensionsmethod balks when it encounters other relevant critical EKU's.
最后，该checkRemainingExtensions方法在遇到其他相关的关键 EKU 时会停止。
So I expect that your wildcard SSL certificate specifies at least one EKU that is not code signingand therefore is not recognized as a valid code signing certificate by the java plugin.
因此，我希望您的通配符 SSL 证书至少指定一个不是代码签名的EKU，因此不会被 java 插件识别为有效的代码签名证书。
回答by Luiz Frederico Jr
After having an codesigner, this twicks in may manifest make that works:
在有一个代码设计师之后，这个 twicks in may manifest make 有效：
Manifest-Version: 1.4
Application-Library-Allowable-Codebase: *
Permissions: all-permissions
Caller-Allowable-Codebase: **http://yourIp:yourPort/-**
Codebase: *
An detailon the end of http://yourIp:yourPort/-put the "/-" to achive all your site...
http://yourIp:yourPort/末尾的详细信息-将“/-”放在您的所有站点上...
