Plug-ins are typically signed by the developer or the build room depending on how the plug-ins are built. JAR signing is a standard process and many tools exist to do this. You can sign features and plug-ins either by using the JarSigner tool included in the Java™ Development Kit (JDK) or by using a third-party tool, such as the Plugin Development Environment (PDE) in Eclipse. Certificates used in jar signing can be obtained from many of the well known certificate authorities (CA).

When you install and deploy new custom or third-party features and plug-ins for Notes installation, you can add your own certificates to a keystore so that the signed features are trusted during install and update from the media kit.

Features are checked for trust during initial and update provisioning. If Lotus Notes is already installed, features are checked during runtime provisioning -- either during traditional third-party install or user-initiated update.

• Install time provisioning – The Notes installer installs and initially provisions new or updated features from the install kit's update site UPDATESITE.ZIP. During this initial provisioning, trust is based on the Java keystore file in the Lotus Notes install media kit's "deploy" directory. This keystore contains the IBM code signing certificate. By default, only features and plug-ins that are signed with this certificate will be installed.
• Runtime provisioning – Notes is running and provisioning is initiated manually by the end user or programmatically based on a scheduled criteria. During runtime provisioning, the Notes keystore determines trust for the features being downloaded. This keystore contains the IBM code signing certificate, and by default only plug-ins that are signed with this certificate are installed.

• Displays errors about untrusted content as a post-install summary
• Provides a consistent user interface for handling trusted and untrusted content during runtime provisioning based on policy settings

  Note There is no user interface for prompting during initial Notes install.

• Makes trust decisions based on managed policy settings so that you can override default settings and manage policy settings from a server

If you create new Eclipse features, you can sign them in preparation for install and update using a code signing certificate obtained from a certification authority. When signed and properly resident in the install media kit, the features can be installed if the code signing certificate is included in the media kit keystore. If the code signing certificate is not a trusted file, you can modify the install signature verification policy to allow for installing signed but untrusted content. Signing your custom or third-party Eclipse features accomplishes the following:

• Allows you to dictate the policy settings to determine what kind of signed/unsigned content can be downloaded from an allowed Eclipse update site
• Allows you to modify the default policy used by the signature verification code at install and update time by using IBM® Lotus® Domino™ policy or by setting preferences in the PLUGIN_CUSTOMIZATION.INI file in the install media kit
• Based on administrator settings, allows users to make trust decisions based on the certificate details that were used to sign a feature on the update site
• Prevents corrupted signed content from being installed and provisioned

To add new features to the Lotus Notes installer do the following:

1. Build and create JAR files for new custom or third-party features and plug-ins for use in an Eclipse update site. Use the JRE's JarSigner tool, Eclipse, or other third-party tool.

2. Sign the new custom or third-party feature and plug-in JAR files.

3. Add the certificate to the Notes install media kit's deploy\.keystore.JCEKS.IBM_J9_VM.install file using the KeyTool program included with the JVM or other third-party tool.

Note: Add the certificate(s) used to sign the JAR files to the file(s) beginning with ".KEYSTORE" in the deploy directory of the Lotus Notes install media kit. 

Note The Notes Keystore, which is used for manual update, does not currently include a cross certificate for the IBM code signing certificate. Only the .KEYSTORE file contains this certificate, and it is only used for install and upgrade.

5. Modify the Notes install kit install manifest (deploy\install.xml) and the update site registry (updateSite.zip\site.xml) to include the new feature(s).

6. Use the Domino Administrator to set the default signature verification policies to be used by the Notes client using the Security Settings - Signed Plugin page.

Note If you are updating using the install media kit, Domino policy takes precedent over settings that reside in the Notes install media kit deploy\plugincustomization.ini file. Domino policy does not affect the initial install.

8. Deploy or make available to users, the install kit, including the keystore that you updated in the install kit's deploy directory.

Note If you are adding the new features to an update site, place the update site content and deploy folder content wherever the update is to be made available. When performing a runtime update, the Notes keystore is used for determining trust. This requires an Internet cross-certificate for the code signing certificate to exist in the personal address book. Based on the policy settings set by the administrator, the user can be prompted if the code signing certificate is not trusted by the Notes trust store.

Look for updates to this content as future Expeditor releases become available.

See also

Creating a security policy settings document
Customizing Notes installation using the install manifest
Using the plugin_customization.ini file to verify trust
Using Domino policy to verify trust
Installing and updating custom and third-party features and plug-ins

Glossary