Avoid security level blocking without adding url in exception site list

Question

I have created Java signed applet, it runs perfectly if I set my Java(JRE 8) security level high and add my site url in exception site list.

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

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 popups by 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?

Or is it really mandatory from Java that we must need to add site url in exception site list to avoid such blocking error.

Basically is there any option available to add our url in exception site list through manifest file or any Java code ?

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?

As I am getting self signed applet block issue though I have signed my applet with wildcard certificate.

Answer 1

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 dialogs for a description of the dialogs and why and when they appear.

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.

A second nice 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 may include key usage fields (KU's) and extended key usage fields (EKU's). These fields, when present, restrict the valid usage of the certificate. The java plugin checks for the presence of these fields.

I've found the source code for the 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);
}

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 signature KU 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.

Finally, the checkRemainingExtensions method balks when it encounters other relevant critical EKU's.

So I expect that your wildcard SSL certificate specifies at least one EKU that is not code signing and therefore is not recognized as a valid code signing certificate by the java plugin.