Avoid blocking security levels without adding a URL to the exclusion list

Question

I created a Java signed applet , it works fine if I set the Java Security Level (JRE 8) high and add my site URL to the exclusion list.

But if we do not add the site URL to the list of exception sites, a java security exception occurs: add the URL to the list of exceptions

I created a signed applet using the certificate of the third part.

Here is my manifest file after creating the signed applet:

Is there an option to avoid security lockout pop-ups by adding some changes to the manifest file when creating a signed applet or any script, java code to avoid these pop-ups appearing without adding the site URL to the exclusion list?

Or is it really mandatory for Java that we need to add the site URL to the exclusion list to avoid such a blocking error.

Basically, is it possible to add our url to the list of exception sites through the manifest file or any Java code?

Is it mandatory if I want to sign my applet using a signed certificate, should it be a code signing certificate? Wildcard or ssl certificate won't work?

Since I get a self-locking problem with the applet block, although I signed my applet with a wildcard certificate.

Answer 1

Your application is considered self-signed because you signed it with a certificate that is not intended to sign the code. Self-signed applications are blocked by this nasty pop-up:

You can prevent this pop-up window if you sign it using a code signing certificate signed by a trusted certificate authority. Then the user will get a more convenient confirmation dialog, which will indicate your name as the publisher of the application:

See also the Oracle documentation for security dialogs for a description of the dialogs and why and when they appear.

Take a look at the documentation for working with signed RIAs , in particular 23.2 "Signing RIAs", for information on how to create a code signing certificate to sign your applet.

The second good link is 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 can include key usage fields (KU) and advanced key usage fields (EKU). These fields, if present, limit the actual use of the certificate. The java plugin checks for these fields.

I found the source code of EndEntityChecker that performs this check.

 /** * 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); } 

Verification methods are 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 KU or EKU is not specified, checking KU or EKU returns true. But if KU is indicated, the KU digital signature must be one of them. Similarly, if any EKU is specified, either the signing of the EKU code (identified by file 1.3.3.1.5.5.7.3.3) or the EKU should also be indicated. Any use (indicated by oid 2.5.29.37.0) should also be indicated.

Finally, the checkRemainingExtensions method checkRemainingExtensions aborted when it encounters other relevant critical EKUs.

Therefore, I expect your wildcard SSL certificate to specify at least one EKU that is not code signatures, and therefore not recognized as a valid code signing certificate by the java plugin.

Answer 2

Or is it really mandatory JAVA that we need to add the site URL to the exclusion list in order to avoid such a blocking error.

I guess, yes. End users can disable the securoty popup, but you cannot do this through your application. If You Look At The Oracle Documentation Avoid Security Dialogs . It clearly states that the securoty popup is the expected behavior:

The Java Runtime will automatically alert the user of potential security issues. If you are sure that the applications you use are safe, then you can bypass the security dialogs to simplify the work with users. If the Java applet / webstart application is signed, a certificate security warning dialog box appears, and the user must click the Run button to grant all permissions to the application code.

And if you read the options to avoid the pop-up, you will see that they all mean changing something on the end users computer.

Here are the options (cited Avoiding Security Dialogs ):

• The user accepts the certificate used to sign the application and selects the Always trust the content of this publisher check box. Then next time, permissions will be granted to this application automatically (until the certificate expires or is removed from the trust key store).

• You can manually import the certificate into the JRE trust store. To import a certificate using the Java Control Panel, select the Security tab and select Certificates> Trusted Certificates. To import a certificate from the certificate store from the command line, use the keytool utility (in the JRE bin folder).

• Provide AllPermissions in the Java policy file located at $ {user.home} /. java.policy, or specify any Java policy file that has AllPermissions in $ (JRE_HOME) / lib / security / java. security file. Permissions can be granted to all applications or limited to a specific URL. See “Implementing the default policy” and “Policy file syntax” for more information on .java.policy.

Answer 3

Try changing the manifest by adding your server name to a valid codebase. You probably no longer need to add your site url to the exception

UPDATE

This is an example of my manessest 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: * 

Answer 4

Once you have the code identifier, these tweaks in the make make manifest work:

 Manifest-Version: 1.4 Application-Library-Allowable-Codebase: * Permissions: all-permissions Caller-Allowable-Codebase: **http://yourIp:yourPort/-** Codebase: * 

Details at the end of http: // yourIp: yourPort / - put "/ -" on your entire site ...