A digital certificate is an online identification credential, similar to a driver's license or passport. A digital certificate can be used to identify an individual or an organization.
Digital signatures are calculations based on an electronic document using public-key cryptography. Through this process, the digital signature is tied to the document being signed, as well as to the signer, and cannot be reproduced. With the passage of the federal digital signature bill, digitally signed electronic transactions have the same legal weight as transactions signed in ink.
WebSphere Partner Gateway uses digital certificates to verify the authenticity of business document transactions between the Community Manager and participants. They are also used for encryption and decryption.
You can specify a primary and a secondary certificate for outbound documents to ensure that the document exchange is not interrupted. The primary is used for all transactions. The secondary is used if the primary is expired or revoked.
Digital certificates are uploaded and identified during the configuration process.
If a certificate is found to be expired or revoked, it is disabled and is reflected as such in the console. If the primary certificate is expired or revoked, it is disabled and the secondary certificate will be set as the primary. An event is generated when a certificate is found to be expired or revoked.
The Certificate Usage option is available based on the certificate type selected. In the Hub Operator profile, Certificate Usage can be set for Digital Signature or SSL Client certificate. In the participant profile, Certificate Usage can be set for Encryption certificate. If the same certificate is to be used for different purposes, for example, for Digital Signature and Encryption in Hub Operator profile, it needs to be loaded twice, once for the Digital Signature, and again for the Encryption certificate. However, if the certificate is used for Digital Signature and for SSL Client, then the corresponding checkboxes can be set in the same certificate entry.
Such certificates can also be loaded twice, once for Digital Signature and again for SSL Client. If so, the same pattern must be followed for the secondary certificates. For example, if the primary certificates were loaded as different certificates for Digital Signature and for SSL Client, secondary certificates should also be loaded as different certificate entries (even though the certificate may be the same).
For complete certpath building and validation, you are required to upload all of the certificates in the certificate chain. For example, if the certificate chain contains certificates A -> B -> C -> D, where A -> B means A is the issuer of B, then certificates A, B, and C should be uploaded as root certificates. If one of the certificates is not available, the certpath would not be built and the transaction would not succeed. The CA certificates can be obtained from the Certificate Repositories maintained by the Certificate Authorities or from the partner who provided the certificate. Root and intermediate certificates can only be uploaded in the Hub Operator profile.
Use the following procedure to list and edit digital certificates stored under the Hub Operator profile (previously uploaded to system).
Parameter | Description |
---|---|
Certificate Type |
Type of digital certificate:
|
Description |
Text that describes the certificate. |
Status |
Enables or disables the certificate. |
Gateway Type |
Select the type of gateway associated with the certificate. |
Certificate Usage |
Select usage type:
|
If you do not want to use a digital certificate, use the following procedure to disable it.