NOTES CLIENT INSTALLATION AND UPGRADE


Using Eclipse preferences to verify trust
You can use the IBM® Lotus® 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. You can modify the following settings in the Notes install kit deploy\plugincustomization.ini file to establish responses during install and update:
Note IBM® Lotus® Domino® Domino policy takes precedence over Eclipse preferences. Eclipse preferences reside in the plugin_customization.ini file.

Note 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.

Note 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 as well as 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.

By default the Notes installer uses only the keystore in the deploy directory to make trust decisions. If you want to trust any certificate issued by a well known certification authority, use the the following statement to the install kit's deploy\plugin_customization.ini file as below.

Note This instructs the kit 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.


The three settings that govern how the result of signature verification is interpreted are as below:
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.

Note For any install or upgrade performed using an install kit, PROMPT=DENY.

The following example allows JAR files with expired signatures to be installed or updated:


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.

Note For any install or upgrade performed using an install kit, PROMPT=DENY.

The following example allows JAR files with expired timestamp to be installed or updated:


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. The PROMPT function is recognized by Notes install and upgrade.

The following example allows unsigned JAR files to be installed or updated:


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.

The following example does not allow untrusted JAR files to be installed or updated. If the Notes installer encounters an untrusted signature during initial Notes install, it exits the install with an error.


Related topics