Security Certificates and Keys are used all the time in browsers and communications but unless we are looking for them, we don’t see them. They are applied whenever we need assurance that the communication methods, are secure. Communications like SFTP (Secure FTP), HTTPS (Internet Protocol) and Sterling Connect Direct (C:D) amongst others require the application of Key Pairs and certificates. This text goes some way to de-mystify some of the terms.

There may be subtle differences, but this article applies to all versions of IBM B2Bi
Also sometimes referred to as Gentran Integration Suite (GIS) and Sterling Integrator (SI)

Certificates

What are they for?

There is a requirement for information on the internet to be both encrypted so as not to be seen by prying eyes and signed to prove to the recipient that the sender is who they say they are. In the sphere of the modern connected world this should happen as transparently and simply as possible even though the mechanisms behind the scene may not be.

Keys

Encryption and Signing happens with the application of cryptographic keys and although this full topic is really a separate subject there are elements that must be understood.

• To encrypt or sign you need a fixed algorithm (or method) and a Private Key.
• To unencrypted or verify you need a Public Key.

Typically, the Private Key, as the name suggests, is owned by one source and kept very safe. The Public Key is also important obviously but tends to get distributed to your trusted partners, friends and so on.

Certificate

A Digital Certificate consists of a Public Key and Data.

This Certificate is applied by the Private Key when it is created. This is so as to be able to distribute the Public Key in such a way that it can be verified by itself.

The data in the certificate is information like Version, Subject, Owner, Contact Details, Serial Number, Valid Period (Start and End Dates) and other import data. This is all in clear text but is signed. You can therefore check if any of the data has been changed by checking it against the key.

In theory though it could be possible to create a certificate that looks the same … it would be impossible to create a certificate that is the same without the Private Key

So, if you already have the Public Key and someone sends you the matching Certificate you could compare and guarantee they are the same. This is important when you want to set up a secure channel one an open communications protocol like the internet.

What is important therefore is that the first Certificate that you receive is the real one and this is where all the hard work is required. After that you can relax.

Self-Signed Certificate

One type of Certificate is a Self-Signed Certificate here you are actually creating your own Private Key and with this you will be able to create a Public Key with a Certificate. This Certificate is labelled as self-signed as it has no Trust, more on this later.

These Keys are often used when you own both systems. As you trust yourself you can check in both ends. Internal systems are a good application for these as an example.

The risk though is that when handling a self-signed certificate, you have to be certain that this is from the correct sender. If not, the actual sender could be pretending to be the intended sender. The data will still be encrypted and signed in the same way but will be done with an untrusted source.

Self-Signed Certificates are free however so are great for learning the process and for low risk communications.

Certificate Authority (CA) Certificates and Trusts

What is important with Certificates is what is a called a Trust or a Trust Chain. The paradyme is, that If I trust someone implicitly then I can verify their integrity. It also means anyone that they trust implicitly, I will also trust and so on. The Trust chain is applied to CA Certificates.

There are, therefore, Certificate Authorities whose job it is to be trusted. They check on people and keep themselves above reproach. They can then allocate you or authorise someone else to allocate, for a price, a Private Key. This comes with an Implicit Certificate Authority Chain which can be verified with just the Certificate itself since this can contain Information that cannot be changed. This Chain is sometimes 2 or 3 (or more) in length and the parent can be linked from the child.

There are many Certificate Authorities but for our example below a Private Key being issued for mydomain.com by USERTrust.

This comes with a CA Certificate that contains the following Trust Chain

• The Root Cert from USERTrust RSA Certification Authority.
• The Child Cert from Sectigo RSA Domain Validation Service
• And our mydomain.com Cert would be a child to that.

So, since we trust (because everyone does) USERTrust, and they trust Sectigo RSA and they trust (or issued to) mydomain.com

Therefore, we do too.

So, when mydomain.com issues a Public Certificate the full chain can be verified by checking on the internet and validating the trust chain.

Key Store

A Key Store is where you store Keys (surprisingly enough) and are present in browsers and other products that need to use Keys like Java for example. The important thing is that a key is really useful for encrypting, decrypting, signing and verifying but it is only possible to trust its intended purpose based on its certificate.

Therefore, you check keys into and out of a key store with a certificate.

As a Private Key is in an order of magnitude more important than a Public one you normally apply a password to the file you create. As the file effectively a mini Key Store. It is possible the Key Store itself applies a separate password to the file so you may have to know both.

So how does this apply to B2Bi?

Within B2Bi, you may be surprised to know, there is a Key Store.

To access it go to Trading Partner —> Digital Certificates.