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.
You can create certificate expiration alerts that will notify you when a certificate is about to expire. For more information, see Creating alerts and adding contacts. Expired certificates are saved in the IBM WebSphere Partner Gateway database; they cannot be deleted from the system.
Certificate authority (CA). An authority that issues and manages security credentials and public keys for message encryption. When an individual or company requests a digital certificate, a CA checks with a registration authority (RA) to verify information given to them by the individual or company. If the RA verifies the submitted information, the CA issues a certificate.
Examples of a CA include VeriSign and Thawte.
Digital certificate. A digital certificate is the electronic version of an ID card. It establishes your identity when you perform B2B transactions over the Internet. Digital certificates are obtained from a Certificate Authority (CA) and consist of three things:
Digital signature. A digital code created with a private key. Digital signatures allow members of the hub community to authenticate transmissions through signature verification. When you sign a file, a digital code is created that is unique to both the contents of the file and your private key. Your public key is used to verify your signature.
Encryption. A method of scrambling information to render it unreadable to anyone except the intended recipient, who must decrypt the information to read it.
Decryption. A method of unscrambling encrypted information so that it becomes legible again. The recipient's private key is used for decryption.
Key. A digital code used to encrypt, sign, decrypt, and verify files. Keys can come in key pairs, a private key and a public key.
Non-repudiation. To prevent the denial of previous commitments or actions. For B2B electronic transactions, digital signatures are used to validate the sender and time stamp the transaction. This prevents the parties involved from claiming that the transaction was not authorized or not valid.
Private key. The secret portion of a key pair. This key is used to sign and decrypt information. Only you have access to your private key. Your private key is also used to generate a unique digital signature based on the contents of the document.
Public key. The public portion of a key pair. This key is used to encrypt information and verify signatures. A public key can be distributed to other members of the hub community. Knowing a person's public key does not help anyone discover the corresponding private key.
Self-signed key. A public key that has been signed by the corresponding private key for proof of ownership.
X.509 certificate. A digital certificate used to prove identity and public key ownership over a communication network. It contains the issuer's name (that is, the CA), the user's identifying information, and the issuer's digital signature.
Your certificate identifies your organization and the time period that the certificate is valid.
All certificates must be in either DER or ASCII Privacy Enhanced Mail (PEM) format. The certificates can be converted from one format to another.
There are several types of certificates:
You must upload the certificate to WebSphere Partner Gateway through the console and send a copy of the certificate to the Hub Operator.
VTP certificates copied to the file system are active for all participants created through the console. They are used to validate signed documents received from the Community Participant Simulator. Additionally, certificates copied to the file system are not viewable through the console.
If client authentication is not required, the following must occur:
If client authentication is required, the following must occur: