Fuse ESB - Fuse Message Broker Security Guide - How to Use X.509 Certificates

How to Use X.509 Certificates

Overview

Before you can understand how to deploy X.509 certificates in a real system, you need to know about the different authentication scenarios supported by the SSL/TLS protocol. The way you deploy the certificates depends on what kind of authentication scenario you decide to adopt for your application.

In the target-only authentication scenario, as shown in Figure 1.1, the target (in this case, the broker) presents its own certificate to the client during the SSL/TLS handshake, so that the client can verify the target's identity. In this scenario, therefore, the target is authentic to the client, but the client is not authentic to the target.

Figure 1.1. Target-Only Authentication Scenario

The broker is configured to have its own certificate and private key, which are both stored in the file, broker.ks. The client is configured to have a trust store, client.ts, that contains the certificate that originally signed the broker certificate. Normally, the trusted certificate is a Certificate Authority (CA) certificate.

Mutual authentication

In the mutual authentication scenario, as shown in Figure 1.2, the target presents its own certificate to the client and the client presents its own certificate to the target during the SSL/TLS handshake, so that both the client and the target can verify each other's identity. In this scenario, therefore, the target is authentic to the client and the client is authentic to the target.

Figure 1.2. Mutual Authentication Scenario

Because authentication is mutual in this scenario, both the client and the target must be equipped with a full set of certificates. The client is configured to have its own certificate and private key in the file, client.ks, and a trust store, client.ts, which contains the certificate that signed the target certificate. The target is configured to have its own certificate and private key in the file, broker.ks, and a trust store, broker.ts, which contains the certificate that signed the client certificate.

Selecting the authentication scenario

Various combinations of target and client authentication are theoretically supported by the SSL/TLS protocols. In general, SSL/TLS authentication scenarios are controlled by selecting a specific cipher suite (or cipher suites) and by setting flags in the SSL/TLS protocol layer (that is, the WantClientAuth or NeedClientAuth flags). The following list describes all of the possible authentication scenarios (some of which are not supported by Fuse Message Broker):

Target-only authentication—(supported) this is the most important authentication scenario. If you want to authenticate the client as well, the most common approach is to let the client log on using username/password credentials, which can be sent securely through the encrypted channel established by the SSL/TLS session.
Target authentication and optional client authentication—(supported) if you want to authenticate the client using an X.509 certificate, simply configure the client to have its own certificate. By default, the target will authenticate the client's certificate, if it receives one.
Target authentication and required client authentication—(not supported) it is theoretically possible to configure a target to require client authentication by setting the NeedClientAuth flag on the SSL/TLS protocol layer. When this flag is set, the target would raise an error, if the client fails to send a certificate during the SSL/TLS handshake. Currently, this option is not supported by Fuse Message Broker. The NeedClientAuth flag is always set to false.
No authentication—this scenario is potentially dangerous from a security perspective, because it is susceptible to a man-in-the-middle attack. It is therefore recommended that you always avoid using this (non-)authentication scenario.
It is theoretically possible to get this scenario, if you select one of the anonymous Diffie-Hellman cipher suites for the SSL/TLS session. In practice, however, you normally do not need to worry about these cipher suites, because they have a low priority amongst the cipher suites supported by the SunJSSE security provider. Other, more secure cipher suites normally take precedence.

Demonstration certificates

Fuse Message Broker provides a collection of demonstration certificates, located in the $ACTIVEMQ_HOME/conf directory, that enable you to get started quickly and run some examples using the secure transport protocols. The following keystore files are provided (where, by convention, the .ks suffix denotes a keystore file with key entries and the .ts suffix denotes a keystore file with trusted certificate entries):

broker.ks—broker keystore, contains the broker's self-signed X.509 certificate and its associated private key.
broker.ts—broker trust store, contains the client's self-signed X.509 certificate.
client.ks—client keystore, contains the client's self-signed X.509 certificate and its associated private key.
client.ts—client trust store, contains the broker's self-signed X.509 certificate.

	Warning
	Do not deploy the demonstration certificates in a live production system! These certificate are provided for demonstration and testing purposes only. For a real system, create your own custom certificates.