Table of Contents
Advertisement
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 and 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 internal partners and external
partners. They are also used for encryption and decryption.
You can specify a primary and a secondary certificate 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.
Digital certificates are uploaded and identified during the configuration process.
If a certificate is expired or revoked, it is disabled and is reflected as such in the
console. However, this is not applicable to the certificates uploaded as
Root/Intermediate certificates. If the primary certificate is expired, 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.
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,
Encryption, or SSL Client certificate. In the partner 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 has 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 check boxes can be set in the same
certificate entry.
Secondary certificates can also be loaded twice, once for Digital Signature and
again for SSL Client. If so, the same pattern has to be followed for the secondary
certificates. For example, if the primary certificates were loaded as different
certificates for Digital Signature and for SSL Client, then secondary certificates has
to 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 is not built and the transaction is
unsuccessful. The CA certificates can be obtained from the Certificate Repositories
maintained by the Certificate Authorities. Root and intermediate certificates can
only be uploaded in the Hub Operator profile.
Note: Before you can use the procedures in the following sections, the certificates
must be loaded into the system. For more information about loading the
certificates, see the WebSphere Partner Gateway Hub Configuration Guide.
The Certificate Management view allows you to modify certificate sets that are
used for a specific participant connection. An option to filter is provided. Modify
the certificate sets that are used in the connection. Alternatively, this can be done
from the participant connection itself. Steps to manage Certificates sets:
50
IBM WebSphere Partner Gateway Enterprise and Advanced Editions: Administration Guide
Advertisement
Table of Contents
