SSL authentication

Activator provides options for allowing 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 act in the role of either client or server 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.

Enable SSL trading connections

To enable SSL authenticated trading with a given partner:

• Deliveries: When you create a trading delivery, specify the option Clients must use SSL to connect to this server. You can then additionally select the option 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.
• Pickups: When you create a trading pickup you also can specify the option Clients must use SSL to connect to this server, and additionally select the option Enable host name verification. The second option requires that the partner’s certificate be used to verify the partner’s identity when a connection is made.

These controls are further described in the topics under Add a trading delivery and Modify a 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.

SSL trading negotiation

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 (community acts in client role) or the partner is connecting to the community’s SSL server (community acts in 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.

1. The client establishes a socket connection to the SSL server. This could be an HTTP, FTP or another kind of server.
2. The server sends the client its SSL server certificate. This is a required step in the SSL handshaking sequence.
3. The client checks whether it trusts the server’s certificate.
4. 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.

1. The server explicitly asks the client to send its SSL client certificate.
2. The client sends the server its SSL client certificate.
3. The server checks whether it trusts the client’s certificate.
4. 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.
5. 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.