Using Eclipse preferences to verify trust
You can use the Notes® install kit's deploy\plugin_customization.ini file to call a named keystore and instruct the installer how to respond to features and plug-ins that are expired or not yet valid, unsigned, or signed by an unrecognized certificate authority.
com.ibm.rcp.security.update/EXPIRED_SIGNATURE_POLICY=PROMPT
com.ibm.rcp.security.update/UNSIGNED_PLUGIN_POLICY=PROMPT
com.ibm.rcp.security.update/UNTRUSTED_SIGNATURE_POLICY=PROMPT
Domino® policy takes precedence over Eclipse preferences. Eclipse preferences reside in the plugin_customization.ini file.
Features and plug-ins being installed as part of Notes® install or upgrade must be signed. Features and plug-ins being deployed to an existing Notes® install, for example using a widget, should be signed by a trusted certifier.
Trust defaults can be pushed to clients using Domino® policy settings in the Administrative trust defaults page on the security policy document's Keys and Certificates tab or by using the deploy.nsf. However, if you have used the Keys and Certificates tab on the Security policy dialog to push administrative trust defaults, those settings are used and the user's deploy.nsf is ignored.
This instructs the installer to verify trust in code signing certificates using the JRE CACERTS file, which contains the certificates for all well known roots. Using this setting will compromise the security of the installer, since anyone with a valid certificate can modify the code.
com.ibm.rcp.security.update/TRUST_CERTIFICATE_AUTHORITIES=true #(default is false)
There are three settings that govern how the result of signature verification is interpreted:
- ALLOW -- Install the feature.
- PROMPT -- Prompt the user and let them decide what to do.
In the case of untrusted, the user can choose to start trusting the certificate by adding it to the keystore. Note that during Notes® installation, PROMPT = DENY, because the installation program does not prompt the user for this information.
- DENY -- Don't prompt the user and don't install the feature.
EXPIRED_SIGNATURE_POLICY
The EXPIRED_SIGNATURE_POLICY setting defines the default behavior when provisioning encounters a JAR file that is signed but the certificate used to sign the jar file has expired. The available values are PROMPT, ALLOW, and DENY. For the initial install, PROMPT=DENY because there is no user interface for this function. The PROMPT function is recognized by Notes® upgrade.
The following example allows JAR files with expired signatures to be installed or updated:
com.ibm.rcp.security.update/EXPIRED_SIGNATURE_POLICY=ALLOW
TSAEXPIRED_SIGNATURE_POLICY
The TSAEXPIRED_SIGNATURE_POLICY setting defines the default behavior when provisioning encounters a JAR file with an expired time stamp. The available values are PROMPT, ALLOW, and DENY. For the initial install, PROMPT=DENY because there is no user interface for this function. The PROMPT function is recognized by Notes® upgrade.
The following example allows JAR files with expired timestamp to be installed or updated:
com.ibm.rcp.security.update/TSAEXPIRED_SIGNATURE_POLICY=ALLOW
UNSIGNED_PLUGIN_POLICY
The UNSIGNED_PLUGIN_POLICY setting defines the default behavior when provisioning encounters an unsigned JAR file. The available values are PROMPT, ALLOW, and DENY. For the initial install, PROMPT=DENY because there is no user interface for this function.
com.ibm.rcp.security.update/UNSIGNED_PLUGIN_POLICY=ALLOW
UNTRUSTED_SIGNATURE_POLICY
The UNTRUSTED_SIGNATURE_POLICY setting defines default behavior when provisioning encounters a JAR file that has been properly signed, but no matching certificate exists in the keystore.
The available values are PROMPT, ALLOW, and DENY. For kit install and upgrade, PROMPT=DENY because there is no user interface for this function.
com.ibm.rcp.security.update/UNTRUSTED_SIGNATURE_POLICY=DENY