Use SSL with Rational Integration Tester

Part 1. Key material, the SSL handshake, and its use in Rational Integration Tester transports

An overview

IBM® Rational® Integration Tester is part of the IBM® Rational® Test Workbench, which among other capabilities, enables you to do integration testing of highly complex applications. Rational Integration Tester is a desktop solution that helps address the challenges of testing legacy or modern architectures by:

• Helping you to visualize connections and dependencies between services and components.
• Creating stubs for services that are unavailable for testing, and automate all aspects of integration testing.

This article focuses on use and configuration of Secured Socket Layer (SSL) within Rational Integration Tester. The Secured Socket Layer and its configuration are hard to understand because of the number of elements involved in the setup. The configuration and use of SSL in IBM Rational Integration Tester is further complicated by the range of different technologies that are available and the ability of the application to act as both a client and a server.

Rational Integration Tester provides SSL configuration on the physical resource editors of supported transports, each of which reference the key material needed to authenticate a peer and optionally, to represent the test or stub.

To assist with the management of key material, Rational Integration Tester uses an Identity Store resource that is a convenience wrapper around a Java keystore, which gives you the ability to import and manage different forms of private keys and certificates in a unified manner.

In this first of two articles on using SSL within Rational Integration Tester you will:

• Learn what is considered key material
• Explore how and where it is used within the SSL handshake
• Find out about the files that contain the key material
• Get an overview of the management, configuration, and usage of SSL within Rational Integration Tester

Key material

SSL communications are based on public and private key pairs that allow each end of the communication (or each peer) to use one or the other to establish a secure, shared secret. These key pairs, when combined with the use of certificates and certificate authorities, provide the framework in which secure communications take place.

When communicating through SSL, Rational Integration Tester, acting as client, might need to be able to verify the identity that is presented to it after establishing a connection. Rational Integration Tester also needs to present an identity both when acting as a server and when participating in mutual authentication.

The SSL handshake

When a connection is established using SSL, a handshake takes place so that both parties can verify each other and so that subsequent communications can then take place securely. Figure 1 shows the points within this handshake that use the key material.

Figure 1. Key material in the SSL handshake

View image at full size

1. Following the client Hello message, the server responds with its Hello message that contains, among other things, its digital certificate.
2. If mutual authentication is taking place, the server sends a client certificate request that includes a list of the names of acceptable certificate authorities.
3. The client verifies the signature on the server's certificate.
4. If required, the client sends its certificate, or a no digital certificate alert.
5. The SSL server verifies the signature on the client certificate.

The implementation of the authentication process is achieved through the exchange of digital certificates during the SSL handshake.

The certificates required are as follows, where certificate authority CA1 issues a certificate to the SSL client, and CA2 issues a certificate to the SSL server:

• Server authentication
• Client authentication
• Self-signed certificates

Server authentication

Server authentication is the most common scenario, typically seen in e-commerce where only the client needs to trust the server. For server authentication, the SSL server needs:

• The server's certificate issued by CA2
• The server's private key

The client needs the CA certificate for CA2 or the server's certificate issued by CA2.

Client authentication

Also known as mutual authentication, client authentication is where the SSL server needs to verify the client's identity by checking the client's digital certificate. For client authentication, the server presents a list of certificate types and authorities that it trusts so that the client is able to find and return the most suitable one from its identity store. In addition to the items above, the SSL server also needs the CA certificate for CA1 or the client's certificate issued by CA1.

The client also needs:

• The client's certificate issued by CA1
• The client's private key

Client authentication is merely a reversal of the requirements for server authentication.

Note: Both parties might need other intermediate certificates to form a certificate chain to the root CA certificate. Normally these certificates are included as part of the client/server's certificate.

Self-signed certificates

In situations such as test environments where formalized trust is not required, self-signed certificates can be used. These can be thought of as both the client/server certificate and the CA certificate all in one.

File formats for key material

As part of defining the model of the system under test within Rational Integration Tester, the key material is either manually generated or sourced from the servers that are being interacted with. This material is exported or downloaded and stored in one of the following file formats:

• PEM format
• DER format
• PKS#7 format
• PKS#12 format
• JKS format

PEM format

The PEM format is the most common format for certificates. Extensions include .pem, .crt, and .cer,. They are Base64-encoded, ASCII files and contain -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- statements. Although certificates and private keys can be stored in the PEM format, Rational Integration Tester only processes the certificate elements.

DER format

The DER format is just the raw, binary version of the key material. The file extension is usually .der but quite often, the extension is .cer, as with PEM certificates. If opened in a simple editor, the contents appear unreadable.

PKCS#7 format

The PKCS#7 format contains individual certificates and chains of certificates, but not the private key. Although this can be a binary file, it is usually stored in Base64 ASCII format and has a file extension of .p7b or .p7c. Base64 P7B certificates contain -----BEGIN PKCS7----- and -----END PKCS7----- statements.

PKCS#12 format

The PKCS#12 or PFX format is a binary format for storing a server certificate, any intermediate certificates, and the private key in one file that can be encrypted. PFX files usually have extensions such as .pfx and .p12.

JKS format

A Java keystore is a password-protected repository of certificates and keys. It is almost always file-based and provided by default implementations within the JRE. The file contents are binary and typically have the extension .jks.

Identity Store resource

After you have obtained the relevant key material, it needs to be imported into Rational Integration Tester. To provide unified access to the different types of material, Rational Integration Tester houses all digital certificates and private keys with an Identity Store resource. Identity Stores are created and accessed from within the Physical View of Architecture School, as shown in Figure 2.

Figure 2. Create the Identity Store resource

In the resource editor of a newly created Identity Store, you first need to reference or create an underlying key store,as shown in Figure 3, that enables Rational Integration Tester to house the key material in a secure way.

Figure 3. Configure the new Identity Store

View image at full size

Click New to open the standard file chooser dialog and to specify the name and location of the key store.

Note: For the project to remain portable, the key store file should reside within the project structure. This arrangement enables the key store to be shared with other users and be used as part of deployed tests and virtual services.

After you specify the name and location, nominate a password, as shown in Figure 4, to keep the key store secure within the project.

Figure 4. Set the Keystore password

View image at full size

After you create the password, start importing key material from one or more of the supported file types. Click Import Key/Certificate(s) and use the file browser to locate and select the file. Rational Integration Tester attempts to identify the file type and where required, requests any passwords used to secure that material from the user, as shown in Figure 5.

In this example use the JKS file that was shipped as part of the Rational Integration Tester Platform Pack for usage with the HTTP(S) proxy.

Figure 5. Enter the password for importing

View image at full size

As with most material containing private keys, a password is required to access the contents of the file. In cases such as JKS, secondary passwords might be required to access the private keys contained in the file. Rational Integration Tester automatically attempts to use the first password when a secondary password is required. After it is complete the material is added to the Identity Store, as shown in Figure 6.

Figure 6. Access the imported certificate and key

View image at full size

When you import private keys stored in the PKCS#12 format, you might encounter situations where the Identity Store resource is unable to recover the key, as shown in Figure 7.

Figure 7. Identity Store is unable to recover the key because of an invalid password

View image at full size

To make the key accessible for use within Rational Integration Tester, click the cell in the Password column and enter the corresponding password, as shown in Figure 8.

Figure 8. Enter the correct key password

View image at full size

Although it is possible to import all of the key material that you will use into one Identity Store resource, the best approach is to create logical collections that represent the groups of trust that should be used by the individual transports.

After the key material has been imported and made available through the use of Identity Store resources, you can use the key material within the configuration of physical transports.

HTTP-based SSL configuration

On the HTTP transport, the SSL tab enables you to express the configuration for one or both ends of the secure connection, as shown in Figure 9.

Figure 9. Specify the HTTP SSL settings

View image at full size

These settings are used at the client end of the connection for tests and at the server end of the connection for virtual services. Which setting you use depends on which end of the secure connection you are configuring.

Configure HTTP SSL when used as a server

The provided certificate and its corresponding key are needed as part of the initial SSL handshake (see Figure 1, Step 1). The client can use it and the cipher suite to generate and encrypt the pre-master secret that is eventually used to calculate the shared key (master secret) used for the remainder of the session. The need to encrypt the pre-master secret requires that the Identity Store and key be specified within the SSL settings.

Configure HTTP SSL when used as a client

The provided certificate and key are only needed when the server that is being connected to is performing mutual authentication and has requested the client certificate (see Figure 1, Step 2). The majority of scenarios do not require this pattern, which can be thought of as using a browser to connect to a secure web site. You want to know that the site is valid but the site doesn't need every individual user to prove who they are using certificates and keys.

Note:If specified, this key might need to relate to the machine on which the test is being run. It depends on the degree of verification being done by the server.

Specify trusted certificates for HTTP SSL

When acting as either a client or a server you can configure Rational Integration Tester to perform increasing levels of verification over the certificates that are presented to it. These options are as follows:

• Perform Authentication: Indicates whether any verification should take place or if the remote peer should just be blindly trusted.
• Specify Trusted Certificates: States that the certificate at the end of the chain provided by the remote peer must match one from those present in the configured Identity Store resource.
• Verify Certificate Chain: Ensures that the peer's certificate chain is both correct and that each certificate is valid.

Typically, for the purposes of testing, you are unconcerned about the identity or validity of the server that you are connecting to and thus it is common for all of these options to be left unchecked.

Configure SSL for other transports

Many other transports, such as IBM® WebSphere® MQ and CICS® Transaction Gateway, also provide client-side SSL connectivity and have a similar set of configuration options. In all cases the same usage of key material applies with regard to trust and representation of the client's identity.

Troubleshoot SSL communication

When you configure SSL, the most significant aspect is to understand who are the parties involved and specifically, what is their relationship to each other. Confirm whether communications are secured using one-way or mutual authentication, and understand what protocol is being used, for example SSL or TLS.

For virtualization, ensure that the physical transport is configured with a suitable provided certificate and key. If one isn't readily available within your organization, construct it with tools such as OpenSSL or use the certificate and key that is supplied with the HTTP proxy server within the Rational Integration Tester Platform Pack.

Summary

This article explains the various key material types and how they are used within Rational Integration Tester so that it can connect to and test applications secured using SSL. In Part Two we explore how to use the HTTP(S) proxy server to record and re-route secure traffic by using existing key material, or by using the certificate and key that is included in the HTTP proxy server, within the Rational Integration Tester Platform Pack.

Downloadable resources

• PDF of this content

Related topics

• Rational Integration Tester information center
• Stubs made easier with Rational Integration Tester
• Use Rational Integration Tester to test WebSphere MQ test message interactions