...
- (Preferred) Create a certificate for the Virtualize server, sign it with a certificate authority that is trusted by the AUT, and issue it for the host where the Virtualize server is installed. With this option, you don’t need to make any changes to the AUT.
- Configure Virtualize Server with a generated (possibly self-signed) certificate and add it to the trust store of the AUT.
- Add your actual server certificate to Virtualize. This option assumes that access to the server certificate and keys is possible and that changes to the AUT are difficult or should be avoided. However, this option may not be possible if the certificate was signed for a hostname other than the hostname where Virtualize is deployed.
- Disable certificate trust in the AUT. The AUT would still connect over SSL but trust any server (such as the Virtualize server) without validating its certificate or its trust paths.
- Set up a frontend like a load balancer that provides SSL and forwards to the Virtualize server.
For the AUT to accept a certificate/private key pair, you generally need—at minimum—a self-signed certificate/private key pair whose common name (CN) parameter matches the fully-qualified name of the server. For example, if your Virtualize server URL is http://myserver.mycompany.com, the CN parameter should be "myserver.mycompany.com".
...
- Default: allows you to manually enter connection details, such as host, port, and channel.
- CCDT: allows you to specify a client channel definition table (CCDT) file that provides connection details.
- Bindings: use Bindings mode when the queue manager and connected applications are running on the same system. The IBM WebSphere MQ Java API connects API connects directly to the queue manager using the Java Native Interface (JNI). To use the bindings transport, the IBM MQ classes for JMS must be run in an environment that has access to the IBM MQ Java Native Interface libraries.
...