Sun GlassFish Message Queue 4.4 Administration Guide

Using Signed Certificates

Signed certificates provide a stronger level of server authentication than self-signed certificates. You can implement signed certificates only between a client and broker, and currently not between multiple brokers in a cluster. This requires the following extra procedures in addition to the ones described in Using Self-Signed Certificates. Using signed certificates requires configuration on both the broker and client:

Obtaining and Installing a Signed Certificate

The following procedures explain how to obtain and install a signed certificate.

ProcedureTo Obtain a Signed Certificate

  1. Use the J2SE keytool command to generate a certificate signing request (CSR) for the self-signed certificate you generated in the preceding section.

    Information about the keytool command can be found at

    Here is an example:

       keytool  -certreq  -keyalg RSA  -alias imq  -file certreq.csr
                -keystore /etc/imq/keystore  -storepass myStorePassword

    This generates a CSR encapsulating the certificate in the specified file (certreq.csr in the example).

  2. Use the CSR to generate or request a signed certificate.

    You can do this by either of the following methods:

    • Have the certificate signed by a well known certification authority (CA), such as Thawte or Verisign. See your CA’s documentation for more information on how to do this.

    • Sign the certificate yourself, using an SSL signing software package.

      The resulting signed certificate is a sequence of ASCII characters. If you receive the signed certificate from a CA, it may arrive as an e-mail attachment or in the text of a message.

  3. Save the signed certificate in a file.

    The instructions below use the example name broker.cer to represent the broker certificate.

ProcedureTo Install a Signed Certificate

  1. Check whether J2SE supports your certification authority by default.

    The following command lists the root CAs in the system key store:

       keytool  -v  -list  -keystore $JAVA_HOME/lib/security/cacerts

    If your CA is listed, skip the next step.

  2. If your certification authority is not supported in J2SE, import the CA’s root certificate into the Message Queue key store.

    Here is an example:

       keytool  -import  -alias ca  -file ca.cer  -noprompt  -trustcacerts
                -keystore /etc/imq/keystore  -storepass myStorePassword

    where ca.cer is the file containing the root certificate obtained from the CA.

    If you are using a CA test certificate, you probably need to import the test CA root certificate. Your CA should have instructions on how to obtain a copy.

  3. Import the signed certificate into the key store to replace the original self-signed certificate.

    Here is an example:

       keytool  -import  -alias imq  -file broker.cer  -noprompt  -trustcacerts
                -keystore /etc/imq/keystore  -storepass myStorePassword

    where broker.cer is the file containing the signed certificate that you received from the CA.

    The Message Queue key store now contains a signed certificate to use for SSL connections.

Configuring the Client to Require Signed Certificates

You must now configure the Message Queue client runtime to require signed certificates, and ensure that it trusts the certification authority that signed the certificate.

Note –

By default, starting with release 4.0, the connection factory object that the client will be using to establish broker connections has its imqSSLIsHostTrusted attribute set to false, meaning that the client runtime will attempt to validate all certificates. Validation will fail if the signer of the certificate is not in the client's trust store.

ProcedureTo Configure the Client Runtime to Require Signed Certificates

  1. Verify whether the signing authority is registered in the client's trust store.

    To test whether the client will accept certificates signed by your certification authority, try to establish an SSL connection, as described above under Configuring and Running an SSL-Based Client Using Self-Signed Certificates. If the CA is in the client's trust store, the connection will succeed and you can skip the next step. If the connection fails with a certificate validation error, go on to the next step.

  2. Install the signing CA’s root certificate in the client’s trust store.

    The client searches the key store files cacerts and jssecacerts by default, so no further configuration is necessary if you install the certificate in either of those files. The following example installs a test root certificate from the Verisign certification authority from a file named testrootca.cer into the default system certificate file, cacerts. The example assumes that J2SE is installed in the directory $JAVA_HOME/usr/j2se:

       keytool  -import  -keystore /usr/j2se/jre/lib/security/cacerts
                -alias VerisignTestCA  -file testrootca.cer  -noprompt
                -trustcacerts  -storepass myStorePassword

    An alternative (and recommended) option is to install the root certificate into the alternative system certificate file, jssecacerts:

       keytool  -import  -keystore /usr/j2se/jre/lib/security/jssecacerts
                -alias VerisignTestCA  -file testrootca.cer  -noprompt
                -trustcacerts  -storepass myStorePassword

    A third possibility is to install the root certificate into some other key store file and configure the client to use that as its trust store. The following example installs into the file /home/smith/.keystore:

       keytool  -import  -keystore /home/smith/.keystore
                -alias VerisignTestCA  -file testrootca.cer  -noprompt
                -trustcacerts  -storepass myStorePassword

    Since the client does not search this key store by default, you must explicitly provide its location to the client to use as a trust store. You do this by setting the Java system property once the client is running: