Digital certificates

A digital certificate consists of the public portion of a private/public key pair and metadata values that identify the holder of the certificate (name, company name, certificate expiry date, etc.). A certificate is said to be ‘signed’ when a CA or individual uses a private key to encrypt a hash of a message.

Signing of digital certificates

Note: In TLS encryption, a hash is a mathematical reworking of a message to reduce it to a manageable size. It is created by using a hashing algorithm, which is included as part of a signed message.

The hash can be decrypted only by someone who has the public portion of the private/public key pair. Decrypting the hash proves that the sender (or holder of the certificate) is trusted by the signer and that secure communication can begin.

In the following diagram, the receiver of a signed message is verifying the identity of the signer. Authentication is done by comparing a hash of the certificate that the receiver creates with a similar hash that the signer created and then encrypted using their private key. The receiver uses the signer's public key to decrypt the signer's signature to expose the original hash of the certificate.

If the two hashes match, then the receiver can trust the signature of the message, as only the signer could have encrypted the hash with the private portion of their key pair.

The receiver of a signed message is verifying the identity of the signer. Verification is done by comparing a hash of the certificate that the receiver creates with a similar hash that the signer created and then encrypted using their private key. The receiver uses the signer's public key to decrypt the signer's signature to expose the original hash of the certificate. If the two hashes match, then the receiver can trust the signature of the message, as only the signer could have encrypted the hash with the private portion of their key pair.

Note: If you have a small network of only a few servers and clients, you can . You then send certificates for each server to trusted clients within your network, and these clients trust the certificates as if they were signed by a CA.

The certificate chain

Your certificate might in turn depend on the digital certificate of another CA; there might be a hierarchy of certificates that are issued by multiple CAs, each depending on the validity of the next. However, the receiver needs the public key of the root CA, eventually. The root CA is the CA at the top of the hierarchy, and this hierarchy, or dependency, is known as a certificate chain.

To trust the validity of the digital certificate of the root CA, the user must receive that digital certificate in a secure manner. Examples of secure transfer include downloading from an authenticated server, or with preinstalled software received from a reliable source. Applications that send a digital certificate to a receiver send not just their own certificate: They also all the CA digital certificates necessary to verify the hierarchy of certificates up to the root CA certificate.

For a digital certificate to be entirely trustworthy, the owner of the digital certificate must be careful to protect their private key in their keystore. If their private key has been compromised, an imposter could misuse their digital certificate.

Distributing a signed certificate

When you receive your signed certificates from a CA, you can use IBM Global Security Kit (GSKit) to add (receive) them to a keystore and to import them to a certificate file. You can then distribute the certificate file to the Db2® servers and clients within your network. This process allows receiving clients and servers to validate a sending server's certificate against the one that they added to their local keystore. Once the certificate is validated, the client and server can establish encrypted communication.

Note: In some cases, your security team might do all the work for you. They might act as your CA and create the needed keys and certificates for each Db2 server in your network. They might provide these components in a certificate file like a *.crt or they might provide you with a keystore that contains all of required elements.