Digital Certificates
Digital certificates are data strings that a Certificate Authority (CA) creates after the CA verifies the identity of an entity that has submitted a CSR (Certificate Signing Request).
When the CA signs and issues a certificate to a user, the CA’s signature on the certificate verifies the authenticity of the link between the user’s public key and the user’s actual identity. A user can then use its certificate, as contained in its certificates file, to identify itself during e-commerce. The three basic items in a certificate are the CA’s signature, the user’s identity, and the user’s public key. A certificate is like a driver’s license in that both are issued by a recognized authority (a CA or a governmental agency, respectively) and both identify the holder. Certificates are specified by the X.509 standard, such as X.509v3.
Digital certificates perform these functions:
- Certify the identity of the holder of the certificate
- Allow for non-repudiation of transactions
- Encrypt email messages
- Sign mobile code that can be downloaded by a web server
These certificates contain both a private key for the certificate holder and a public key for distribution to partners. They expire on a pre-determined date. Digital certificates are based on the trust that both trading partners hold in the certificate authority. Some CAs are themselves authenticated using a certificate by a higher-level CA, which may in turn be authenticated by a certificate from an even higher-level CA. This results in a certificate chain.
In a transaction, when digital certificates are being exchanged between the two parties, Party A uses the other party's public key to encrypt the transaction data whereas the Party B uses its own private key to decrypt the data.
Obtaining a Certificate
You can obtain an SSL certificate from the follwoing websites of any authorized certificate authority (CA):
The following are the three kinds of certificates you will use while working with TIBCO BusinessConnect Conatianer Edition and the PKI validation method:
Certificates Authority (CA)
This is a trusted third party that validates identities and issues X.509 certificates by signing the certificate with its signature. Any client or server software that supports certificates has a collection of trusted CA certificates, which determine the certificate issuers that the software can trust. The root CA's certificate is unique as it's a self-signed certificate. It is signed by the root CA itself. The CAs that are directly subordinate to the root CA in the CA hierarchy have CA certificates that were verified and signed by the root CA.
Certificate Chain
A certificate chain is a list of certificates, beginning with a Root certificate and ending with the user’s X.509 certificate. Each certificate in the chain verifies the authenticity of the certificate that follows. Certification is achieved by the presence of a digital signature belonging to the authority issuing the certificate and authenticated by the preceding certificate in the chain. The root certificate authenticates its own signature, which means that it is self-signed. Root certificates from well-known certifying authorities, such as VeriSign, or Thawte, are distributed with applications and kept in an application’s trusted certificate store.
- Root certificates
- The certificate issued by the highest level certificate authority (CA) is called the root certificate.
- Leaf certificates
-
These certificates are issued to you directly from a CA. They are also called identity certificates. You will acquire a leaf certificate from a CA by sending a Certificate Signing Request (CSR), which is associated with the private key of your server.
You can acquire a leaf certificate from a CA by sending a Certificate Signing Request (CSR), which is associated with the private key of your server.
- Intermediate certificates
-
The certificates in the chain that lead up to the highest-level CA are called subordinate or intermediate certificates.
Certificates File
A file that contains the private key’s certificate chain. Unlike a key identity, it contains no private key and is not protected with a password. Trading partners exchange certificates files during the setup phase of their relationship. Each trading partner then installs the other partner’s certificates file. For a host to verify the validity of a trading partner’s certificate, the host must trust each CA’s certificate in the certificate chain within the trading partner’s certificates file. The certificates file defines how each trading partner should expect the other to identify itself in e-commerce transactions. The supported format is PKCS#7 certificates only, which can have file extensions like .p7b and .p7c. When setting up an installation for e-commerce, the key identity file relates to the trading host and one or more certificate files related to one or more trading partners that the host has.
Storing Certificates
A certificate exists in a system file. To exchange business documents with a trading partner you must store the certificates as part of that participant. Hosts require a private key in addition to a public key certificate; partners only include public key certificates. TIBCO BusinessConnect Container Edition stores all certificates, including root, leaf, and intermediate certificates, in a central location: the credential store.