Secure Sockets Layers (SSL)

Secure Sockets Layer (SSL) is a protocol that provides secure communication over the Internet. It uses both symmetric and asymmetric cryptography.

The SSL protocol provides server authentication and client authentication:
  • Server authentication is performed when a client connects to the server. After the initial handshake, the server sends its digital certificate to the client. The client validates the server certificate or certificate chain.
  • Client authentication is performed when a server sends a certificate request to a client during the handshake. If the client certificate or chain is verified and the certificate verify message is verified, the handshake proceeds further.
  • An optional additional authentication is performed by checking the common name in the certificate against the server's fully qualified domain name from a reverse Domain Name Server (DNS) lookup where the server's fully qualified domain name can be obtained.

Types of Trust

Two types of trust for SSL certificates are supported:
  • CA Trust – Hierarchical trust based on a root certificate used to issue other certificates. This is the standard SSL certificate trust model.
  • Direct Trust – Direct trust of self-signed certificates assumed to be distributed through secure out-of-band mechanisms. Direct trust and self-signed certificates are not part of the SSL standards, but are frequently used in certain trading communities.

Using SSL Certificates

To communicate using the SSL protocol, configure the systems involved to support either server authentication or client/server authentication. To perform authentication against a server, you need a root Certificate Authority (CA) certificate and the set of intermediate certificates in the chain or, if the server uses a self-signed certificate, a copy of the self-signed certificate.

To support client/server authentication you need a CA or self-signed certificate and a system certificate.

You can obtain an SSL certificate from a trusted CA by providing a Certificate Signing Request (CSR) to the CA. The SSL certificate binds the public key and the SSL server or client.

If you plan to use client/server authentication, configure a system certificate. You can create system certificates in the following ways:
  • Check in an existing key certificate file or PKCS12 file
  • Generate a self-signed system certificate
  • Generate a CSR and get a certificate from a CA.
When setting up an SSL client connection to a partner's SSL server, you must get one of the following items from your partner:
  • If the partner is using a self signed certificate, get the certificate. Check the certificate into the CA table and you are done.
  • If the partner is using a CA signed certificate:
    1. You must get the root CA certificate or verify that the root CA certificate already exists in the system.
    2. Test the connection.
    3. If the connection isn't successful, get any intermediate certificates in the trust chain and check those into the CA table.
    4. Test the connection.
    5. If the connection isn't successful, this is a defect that should be raised to IBM Support.
Note: As a short-term alternative, you can request the certificate the trading partner used to generate his key certificate. This is the public part of his key certificate and is transmitted to the client using SSL during the SSL handshake, often referred to as the identity certificate. Check it into the CA table. This makes the identity certificate act like a self-signed certificate, establishing immediate trust. There are several reasons for asking for an identity certificate:
  • Self-signed
  • Incorrectly chained
  • Incorrectly named
  • SSL bug

When using the certificate grabber, don't check in the identity certificate unless it is self signed.

Cipher Strength Settings

To implement a cipher strength setting, contact Customer Support.

Earlier Versions of SSL

To enable an earlier version of SSL, contact Customer Support.