Certificates and keys > SSL authentication

SSL authentication

Activator optionally allows certificates to be used for authenticating the identity of trading partners. Secure Sockets Layer (SSL) protocol authentication provides an added layer of security to trading relationships.

A community can be in the client or the server role when trading with a given partner.

Community in client role – When the community is sending a message to a partner, it acts as the SSL client. This requires the community to have trusted the partner's SSL server certificate.
Community in server role – When the partner is sending a message to the community's embedded SSL server, the community acts as the SSL server. If the embedded SSL server has been configured to require client authentication, the community must have trusted the partner's SSL client certificate.

At the time of setting up a trading delivery, you specify that "clients must use SSL to connect to this server." You can further specify to "enable host name verification." The first control requires use of SSL protocol during connections. The second optional control makes Activator compare the name of the SSL server to the name in the server's certificate to make sure they are the same.

When setting up a partner trading pickup, you also can specify that "clients must use SSL to connect to this server." Optionally, you also can require "client-side certificate authentication," which means a partner's certificate is used to verify the partner's identity when a connection is made.

These controls are further described in the topics under Add a partner trading delivery and Modify a partner trading delivery.

Note

If you have a partner who uses webMethods, and the webMethods server runs HTTPS and requires client authentication, and you have not selected an SSL client authentication certificate, the connection is closed. The reason is not apparent in Activator. Activator produces a socket closed error message, but does not indicate the SSL handshake failed. To resolve this, select a certificate for SSL authentication in the community.

The following summarizes what happens when a client connects to an SSL server. These steps apply whether the community is connecting to the partner's SSL server (meaning the community is playing the client role) or the partner is connecting to the community's SSL server (meaning the community is playing the server role). Note that the way Activator performs these tasks may not precisely mirror this order. The steps are presented to illustrate the various checks that may occur.

The client establishes a socket connection to the SSL server. This could be an HTTP, FTP or another kind of server.
The server sends the client its SSL server certificate. This is a required step in the SSL handshaking sequence.
The client checks whether it trusts the server's certificate.
If the client trusts the server's certificate, the connection is maintained. Otherwise, the client drops the connection if it does not trust the server's certificate.

This is the end of the authentication process, unless the server is configured to require client authentication. If client authentication is called for, the following additional steps are performed.

The server explicitly asks the client to send its SSL client certificate.
The client sends the server its SSL client certificate.
The server checks whether it trusts the client's certificate.
If the server trusts the client's certificate, the authentication process is completed (unless host name verification is required as noted in the next step). Otherwise, the server drops the connection if it does not trust the client's certificate.
If host name verification also is called for, the client takes the additional step of comparing the name of the SSL server to the name in the server's certificate. If the names are not the same, the client drops the connection.