| Skip Navigation Links | |
| Exit Print View | |
|
Oracle GlassFish Server Message Queue 4.5 Administration Guide |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Part I Introduction to Message Queue Administration
1. Administrative Tasks and Tools
3. Starting Brokers and Clients
6. Configuring and Managing Connection Services
8. Configuring Persistence Services
9. Configuring and Managing Security Services
10. Configuring and Managing Broker Clusters
11. Managing Administered Objects
12. Configuring and Managing Bridge Services
13. Monitoring Broker Operations
14. Analyzing and Tuning a Message Service
17. Broker Properties Reference
18. Physical Destination Property Reference
19. Administered Object Attribute Reference
20. JMS Resource Adapter Property Reference
21. Metrics Information Reference
22. JES Monitoring Framework Reference
A. Distribution-Specific Locations of Message Queue Data
B. Stability of Message Queue Interfaces
HTTP/HTTPS Support Architecture
Step 1 (HTTPS Only): Generating a Self-Signed Certificate for the Tunnel Servlet
Step 2 (HTTPS Only): Specifying the Key Store Location and Password
To Specify the Location and Password of the Certificate Key Store
Step 3 (HTTPS Only): Validating and Installing the Server's Self-Signed Certificate
To Validate and Install the Server's Self-Signed Certificate
Step 4 (HTTP and HTTPS): Deploying the Tunnel Servlet
To Deploy the HTTP or HTTPS Tunnel Servlet
Modifying the Application Server's Security Policy File
Step 5 (HTTP and HTTPS): Configuring the Connection Service
To Activate the httpjms or httpsjms Connection Service
Step 6 (HTTP and HTTPS): Configuring a Connection
Installing a Root Certificate (HTTPS Only)
Configuring the Connection Factory (HTTP and HTTPS)
Using a Single Servlet to Access Multiple Brokers (HTTP and HTTPS)
Client Failure to Connect Through the Tunnel Servlet
The procedures for enabling HTTP and HTTPS support are essentially the same for both protocols, although a few extra steps are required in the HTTPS case to generate and access the needed encryption keys and certificates. The steps are as follows. (For HTTPS, start with step 1; for non-secure HTTP, start with step 4.)
(HTTPS only) Generate a self-signed certificate for the HTTPS tunnel servlet.
(HTTPS only) Modify the deployment descriptor in the tunnel servlet’s .war file to specify the location and password of the certificate key store.
(HTTPS only) Validate the Web or application server’s self-signed certificate and install it in the client application’s trust store.
(HTTP and HTTPS) Deploy the HTTP or HTTPS tunnel servlet.
(HTTP and HTTPS) Configure the broker’s httpjms or httpsjms connection service and start the broker.
(HTTP and HTTPS) Configure an HTTP or HTTPS connection.
The following subsections describe each of these steps in greater detail, using Oracle GlassFish Server Server as an example for purposes of illustration. If you are using a different application server or Web server (such as Oracle iPlanet Web Server), the procedures will be substantially similar but may differ in detail; see your server product’s own documentation for specifics.
Message Queue’s SSL support is oriented toward securing on-the-wire data, on the assumption that the client is communicating with a known and trusted server. Therefore, SSL is implemented using only self-signed server certificates. Before establishing an HTTPS connection, you must obtain such a certificate. (This step is not needed for ordinary, non-secure HTTP connections.)
Run the Message Queue Key Tool utility (imqkeytool) to generate a self-signed certificate for the tunnel servlet. (On UNIX systems, you may need to run the utility as the root user in order to have permission to create the key store.) Enter the following at the command prompt:
imqkeytool -servlet keyStoreLocationwhere keyStoreLocation is the location of Message Queue’s key store file.
The Key Tool utility prompts you for a key store password:
Enter keystore password:After you have entered a valid password, the utility prompts you for identifying information from which to construct an X.500 distinguished name. Table C-1 shows the prompts and the values to be provided for each prompt. Values are case-insensitive and can include spaces.
Table C-1 Distinguished Name Information Required for a Self-Signed Certificate
|
When you have entered the information, the Key Tool utility displays it for confirmation: for example,
Is CN=mqserver.sun.com, OU=purchasing, ON=Acme Widgets, Inc., L=San Francisco, ST=California, C=US correct?
To accept the current values and proceed, enter yes; to reenter values, accept the default or enter no. After you confirm, the utility pauses while it generates a key pair.
Next, the utility asks for a password to lock the key pair (key password). Press Return in response to this prompt to use the same password for both the key password and the key store password.
 | Caution - Be sure to remember the password you specify. You must provide this password later to the tunnel servlet so it can open the key store. |
The Key Tool utility generates a self-signed certificate and places it in Message Queue’s key store file at the location you specified for the keyStoreLocation argument.
| Caution - The HTTPS tunnel servlet must be able to see the key store. Be sure to move or copy the generated key store from the location specified by keyStoreLocation to one accessible to the tunnel servlet (see Step 4 (HTTP and HTTPS): Deploying the Tunnel Servlet). |
The tunnel servlet’s Web archive (.war) file includes a deployment descriptor, an XML file containing the basic configuration information needed by the application server or Web server to load and run the servlet. Before deploying the .war file for the HTTPS tunnel servlet, you must edit the deployment descriptor to specify the location and password of the certificate key store. (This step is not needed for ordinary, non-secure HTTP connections.)
|