Certificates and Keys in IBM B2Bi

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.

Certificate Authority Section or CA

As the name suggests the CA section stores your CA certified Keys. These are the Public Keys obtained from Certificate Authorities and are the keys that confirm the validity of the child Certificates.

Note: In other Key Stores this may be populated by your Favourite browser provider or OS patches. This can be used to store the root CAs the “because everyone trusts them” certificates. Since B2Bi is installed in a secure environment with no direct access to the internet this will need to be maintained by the system owners manually. Although this seems to some like an oversight, mainly those not truly appreciating the risk, most customers will not need these CAs configured. There is a cost of maintaining these and there would be discussions around who owns issues if it were to go wrong.

Trusted

As the name suggests, this is the part of Key Store where Public Keys are stored that B2B trusts. The intention is that this holds the lowest level key in the chain (although you can store the whole chain including the CA with no issue in this section).

In essence these are the keys that;

Validate the Certificate sent by the partner when negotiating the channel
Actually used by the algorithms to decrypt and/or validate the data.
To check the Public Keys in you need it as part of a Certificate. The Key is validated against the Certificate in a .cer file. This Certificate needs to be valid at the time of check-in.

System

This section holds the Private Keys. As discussed, these can be Self Signed and B2B can generate these.

Or special purpose Private Keys can be purchased and are validated by Certificate. These are applied from typically a PKCS12 format .pfx files and the Certificate Chain must be valid at time of check in.

Using the Keys in B2Bi

Public Keys in B2B will be needed when B2B is connecting to a remote system and validating the connection for SSL or TLS communications (commonly used in SSH, SFTP or HTTPS.) The easiest way to gather these is with the Certificate Capture Utility. The idea being that when a connection is made to the remote service the Public Certificate is exchanged in the connection to be checked against the one you hold, to prove the connection is valid. You may have seen this prompt in other systems asking you to trust a connection on first attempt. The tool will grab that and allow you to save this in the Trusted Store. This will be considered valid.

Private Keys in B2B are used to secure Connect Direct, SFTP, HTTP Servers (With SSL/TLS enabled) and in other places. Once the System Certificate is checked in then this can be found in a drop-down box in the required service.

Special Notes when applying Certificates in B2Bi

Public The beauty of using the Certificate Capture Wizard is that the connection is made to the system proving connectivity is setup. The wizard by default is not using the Perimeter Server so you may need to check for halted processes. To fix this you can edit the service it references and change the Perimeter Service in the drop down. Then run the wizard again. Make sure you give this a relevant name as this name will be used to reference it in drop down boxes. It may be useful to add a start or end date on the name as these will expire and will need to be replaced.

If the remote end decides to change their Key, they are using then the connection will no longer be trusted. You may or may not have been notified of this change so if you are having problems it is worth running the Certificate Capture Wizard to check this. If this is the case, repeat the process above, use a name that closely follows the old one with a different date and then apply it to your connection details.

Not all applications of Public Keys are on communications (AS2 file encryption for example) in this case then they will be required to send you a .cer file.

Private Normally it is possible to apply any PKCS12 (.pfx) file to B2Bi assuming you have the required passwords (Private Key Password and the Original Key Store Password) it this is the case go ahead.

If you have issues, then firstly if you only know one password then they are probably the same … but usually if you have problems then ask if the sender can create the .pfx again and confirm the passwords.

Next request that the creator, creates a .pfx file with the full chain. This will allow B2Bi to validate the full chain upon check in.

The tick boxes are a personnel choice and don’t really make any difference if they work or not

When checking in, ensure the message “Date Valid” and “Verified” are shown otherwise you may have issues.

The issue will not necessarily manifest itself with your system. The partner trying to connect may reject the Certificate because it’s not valid.

If after working with the sending party, you are still having issues getting the .pfx file to work then try a Key Store Editor … an example is Keystore Explorer. These tools act as a Key Store but allow you to manage the Certificate Chain, rebuild it, re validate it or separate the chain … you cannot of course edit the Certificates. In a recent example the Chain had expired and had been included in the distribution. This could have been fixed in any number of ways but was really discovered by using a tool like this and re-validating the Chain and saving it as a new PKCS12 .pfx distribution.

Lastly ensure you choose the Key for the Job and the Certificate for the purpose. If you have a Key that is certified for mymachine.mydomain.com then it will work on mymachine when someone is using that to make the connection. If they are connecting using a different name (obvious example but say localhost) then it will show that connection to be invalid. Even though the Certificate is Valid.

As there is a risk using self-signed certificates many systems won’t support them you will therefore need to purchase a general purpose one for your needs.