Autenticación de servicios Web mediante certificados digitales en IBM Message Broker v8

Introducción

En esta nota intentaré explicar cómo poner en marcha la autenticación mutua mediante certificados digitales en IBM Message Broker versión 8, especificamente para la protección de servicios Web. No voy a profundizar en el tema de certificados digitales, sobre esto hay mucho escrito. Si el lector no conoce sobre el tema, recomiendo detenerse aquí, buscar un rato en internet y volver hasta comprender los conceptos básicos, por ejemplo; que son?, para que sirven?, cómofuncionan?, que es una llave pública y una llave privada?, que es una CA?, entre otros. Adjunto un par de artículos de IBM que me parecen bien explicados:

Introducción a los certificados digitales
Certificados digitales y autenticación mutua

Entramos en materia; En una arquitectura SOA, el tema de seguridad debe ser prioritario; todo servicio que maneje información sensible para el negocio debería incorporar mecanismos de autenticación/autorización que eviten el acceso no autorizado a estos recursos. Recordemos que Un ESB "aguanta" lo que empresa quiera poner en el. Por ejemplo, un banco podría tener en su bus de servicios una consulta que le permita obtener la lista de los 10 clientes más importantes, o una operación que permita mover dinero de una cuenta a otra. Sería inaceptable que estos servicios se encuentren abiertos a la red interna y que cualquiera pueda accederlos libremente. Esto último es particularmente sencillo con los servicios web, ya que su capacidad de autodescribirse mediante un WSDL, hace que lo único necessario para intentar un ataque sea conocer el URL de acceso.

Aunque el Message Broker pone a disposición de los desarrolladores varios métodos para proteger los servicios, el camino mas sencillo es omitirlos y mantener en los nodos sus propiedades por defecto, las cuales omiten totalmente la seguridad. Por otro lado, los mecanismos de seguridad disponibles no están tan documentados cómo un quisiera, lo cual complica su evaluación e implementación.

Cual mecanismo de seguridad es el más indicado para utilizarse en conjunto con Message Broker es relativo, sin embargo, el uso de certificados digitales proporciona una herramienta robusta, de gran madurez y compatible con las principales plataformas del mercado, por ejemplo, java y .net tienen soporte nativo desde hace muchos a esta tecnología. A modo de cultura general, adjunto enlaces a otras alternativas de seguridad disponibles  para esta herramienta:

Seguridad de Web service mediante WS-Security
Autenticación mediante LDAP
Seguridad mediante tokens de nombre de usuario

Existen otros mecanismos de software y hasta hardware especializado en temas de seguridad, cómo por ejemplo el IBM Data Power, sin embargo no es tema de esta nota. Para continuar con el tema de la nota, seguiremos con un poco de teoría sobre la comunicación segura mediante certificados digitales.

Lo primero a tener claro son las piezas que conforman esta arquitectura de seguridad y cómo se relación entre sí para lograr su objetivo. Esto se presenta en el siguiente diagrama:

Esquema de componentes y sus relaciones 

En primer lugar se observa la existencia de una Autoridad de certificación (CA). Esta suministra los certificados que serán utilizados en el resto del proceso, tanto por el cliente cómoel servidor. Sobre esto es importante mencionar que un certificado es simplemente un archivo más dentro del sistema de archivos, algunas herramientas pueden incluso utilizarlos directamente mientras que otras como IWMB requieren que sean importados en un almacén especial antes de poder accederlos. Estos almacenes se denominan de forma genérica como JAVA KEYSTORES y para IWMB existen dos tipos, el TRUSTSTORE, donde se almacenan los certificados de la cadena de confianza (certificados de CA raíz, certificados intermedios, etc) y el KEYSTORE donde se almacena el certificado que será utilizado por el servidor para autenticarse ante el cliente. Como configurar estos keystores y asociarlos al IWMB se explicará más adelante.

Del otro lado del diagrama tenemos el SISTEMA CLIENTE y su CERTIFICADO CLIENTE. Este certificado obligatoriamente debe ser emitido por una CA en la cual el IWMB confíe, es decir, que se encuentre registrada en su TRUSTORE. Este certificado será utilizado por el SISTEMA CLIENTE para identificarse ante el servidor

El certificado en el SISTEMA CLIENTE puede estar almacenado en un repositorio o puede utilizarse directamente el archivo, esto dependerá principalmente de la tecnología utilizada. Por ejemplo, si es un sistema Java, debe estar en un keystore, si es .Net, debe estar en el almacén de certificados de Windows.

Aclarados los componentes y su función, vamos a explicar brevemente el proceso necesario para establecer una comunicación segura entre el SISTEMA CLIENTE y el IBM MESSAGE BROKER, también denominado "handshake". Este se muestra en la siguiente imagen

El diagrama muestra claramente los pasos necesarios para establecer una comunicación segura mediante el uso de certificados digitales. De forma muy breve se explicarán a continuación.

1. El cliente envía un mensaje “Hola” especificando la versión más alta del protocolo TLS soportada,  una lista de algoritmos de autenticación, cifrado, y compresión.
2. El servidor responde con un mensaje “Hola”, indicando la versión del protocolo seleccionado, los algoritmos seleccionados (De los enviados por el cliente) y su certificado digital para autenticarse.
3. El cliente verifica el certificado del servidor mediante una autoridad de confianza o PKI. 
4. El cliente responde con un mensaje con información para generar la clave de sesión. Este mensaje irá cifrado con la clave pública del servidor 
5. El cliente envía su certificado.
6. El servidor valida el certificado del cliente mediante una autoridad de confianza o PKI.
7. El cliente envía un mensaje de "terminado" para indicarle al servidor que su parte del "handshake" ya fue finalizada"
8. El servidor envía un mensaje de "terminado" para indicarle al cliente que su parte del "handshake" ya fue finalizada"
9. Inicia el intercambio de mensajes. 

Si quiere conocer aún más detalle sobre este proceso, puede revisar este enlace de IBM.

Con los pormenores técnicos aclarados, iniciamos la guía como tal, en esta se completará mediante un paso a paso, la configuración necesaria para habilitar la autenticación mutua mediante certificados digitales en IWMB v8. Requisitos

1. Conocer lo básico sobre certificados digitales
2. Contar con un ambiente de pruebas de Mesagge Broker versión 8 (probablemente funcione con versiones 7, 8, 9 y 10), sin embargo solo lo he probado en 8. Se debe tener acceso a la consola de mandatos.
3. Contar con una entidad certificadora, esto para firmar al menos dos certificados, uno para el servidor y otro para el cliente. Sobre este punto hablaremos un poco más adelante.
4. SOAPUI
5. Crear una carpeta de trabajo bajo el nombre Certificados en la carpeta C:\tmp. En esta se almacenarán los certificados, archivos de configuración y demás elementos que se vayan creando a lo largo de la nota.
6. OpenSSL: OpenSSL es una herramienta criptográfica de propósito general que, entre otras cosas, permite trabajar con certificados digitales. La versión más reciente (solo fuentes) se pueden descargar desde su página oficial. En caso de usar Windows, se puede descargar un binario de los listados en este enlace.

Empezamos...

Pasos

1. Configurar OpenSSL

Para utilizar OpenSSL sin especificar demasiados parámetros desde la línea de comandos, es preferible prestablecerlos en su archivo de configuración, denominado openssl.cnf. Este archivo se incluye con la instalación del producto, sin embargo yo recomiendo no utilizar el que viene por defecto y más bien substituirlo por el siguiente:

openssl.cnf

Este archivo fue publicado originalmente en esta entrada del blog jaimelinux.com

Descargar este archivo y ubicarlo en el directorio de trabajo. Editarlo el valor del parámetro dir, para que apunte al directorio de trabajo C:/tmp/Certificados. Las sección [CA_default] quedaría entonces con los siguientes valores:

[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir               = C:/tmp/Certificados
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/.rand

En el directorio de trabajo también es necesario crear dos archivos vacíos, uno con el nombre index.txt y otro con el nombre serial (sin extensión). A este último incluirle el valor 1000 en la primera línea. Ejemplo:

Datos a añadir en el archivo serial

2. Construir CA

El primer elemento necesario para completar esta guía es contar con los certificados digitales que serán utilizados tanto por el cliente como por el servidor para la autenticación, además de los certificados de la cadena de confianza. Se puede usar una CA de la empresa, una CA comercial (habría que pagar por los certificados) o una CA propia creada mediante OpenSSL.  Esta última alternativa es la que vamos a utilizar. 

Básicamente se deben seguir los siguientes pasos:

1. Generar llave privada de la CA
2. Generar certificados de la CA
3. Generar CSR de servidor
4. Firmar CSR de servidor
5. Generar CSR de cliente
6. Firmar CSR de cliente

Vamos a ello. El archivo OpenSSL.exe lo ubiqué en la siguiente dirección: C:\tmp\OpenSSL\bin\OpenSSL.exe y mi directorio de trabajo va a ser el siguiente: C:\tmp\Certificados

Iniciar el símbolo del sistema y agregar al path la ruta del archivo OpenSSL.exe, en mi caso el comando sería el siguiente:

> SET PATH="C:\tmp\OpenSSL\bin"        

Luego, ubicarse en la carpeta de trabajo C:\tmp\Certificados mediante el comando cd. En mi caso el comando sería el siguiente:

> cd "C:\tmp\Certificados" ados

Por último, se debe incluir la ruta del archivo de configuración del OpenSSL (openssl.cnf) en la variable OPENSSL_CONF. El comando utilizado es

> SET OPENSSL_CONF=C:\tmp\Certificados\openssl.cnf

Con el entorno configurado, procedemos a crear los demás componentes:

2.1 Generar llave privada de la CA

Para esto se utilizará el siguiente comando:

openssl genrsa -aes256 -out "Message Broker CA.key" 4096 204
8
El parámetro -out indica el nombre del archivo de salida, mientras que el parámetro -aes256 indica que su contenido (llave privada) será cifrado con al algoritmo aes, con una llave de 256 bits. El valor 2048 establece que la llave tendrá un largo de 4096 bits.

Este comando solicita una contraseña para efectuar el cifrado de la llave según el algoritmo seleccionado (-aes256). Para toda esta guía utilizaré la contraseña 12345 en todos los casos donde se requiera. Se adjunta salida del comando:

c:\tmp\Certificados>openssl genrsa -aes256 -out "Message Broker CA.key" 4096
Loading 'screen' into random state - done
Generating RSA private key, 2048 bit long modulus
.......................................................................................................................................+++
........................................................................................................................+++
e is 65537 (0x10001)
Enter pass phrase for Message Broker CA.cert:
Verifying - Enter pass phrase for Message Broker CA.cert:

c:\tmp\Certificados>

Finalizado esto, verificar que exista el archivo en la ruta seleccionada.

2.2 Generar certificado de la CA

Con la llave privada creada en el paso anterior, se procederá a generar el certificado de la CA. Para esto se utiliza el siguiente comando:

openssl req -key "Message Broker CA.key" -new -x509 -days 7300 -sha256 -extensions v3_ca -out "Message Broker CA.cert"

Este comando solicita la contraseña de la llave primada creada en el paso anterior (Message Broker CA.key). Ingresada la contraseña correcta (12345), se solicitarán los datos que identificarán a la CA, por ejemplo el país, ciudad, nombre, email, etc. Al completar este paso se genera un archivo denominado Message Broker CA.cert  en el directorio de trabajo, que contiene el certificado de la CA.

Con la llave y el certificado creados previamente, contamos con lo necesario para crear los certificados digitales requeridos tanto por el servidor como por el cliente. Empezaremos con el certificado de servidor.

3. Crear keystore de Message Broker y generar CSR de servidor

Para solicitar un certificado digital a una CA, se le debe enviar un documento electrónico denominado CSR (Certificate signing request), este contiene información del solicitante como el país, ciudad, nombre, entre otros. La CA genera el certificado en base a estos datos. IWMB proporciona un mecanismo automático para generar su propio CSR mediante un keystore. Para crear un keystore ingresamos a la consola de comandos de IWMB e ingresamos el comando ikeyman, este abre la aplicación que permite administrar keystores. La aplicación se muestra en la siguiente imagen:

Iniciar ikeyman y sus principales opciones

Para utilizar la aplicación en primer lugar se debe guardar el keystore. Esto se efectúa mediante el botón marcado con el número 3. Esto despliega un dialogo donde se solicita el tipo, nombre y ubicación del archivo. El tipo debe ser JKS ya que es el único soportado por IWMB. En esta guía se utilizará como nombre keystore.jks y será ubicado en el directorio de trabajo. Al darle OK se solicita una contraseña para proteger el keystore. Ingresar la contraseña 12345 y darle OK, como se muestra en la siguiente imagen:

Dialogo para proteger el keystore mediante contraseña

Una vez guardado el keystore se habilitan las opciones para definir sus elementos

Crear CSR

Para crear un CSR se selecciona en la lista desplegable la opción "Personal Certificate Request" y luego se oprime el botón "New...", el cual muestra un diálogo con los campos requeridos del CSR. Este se muestra en la siguiente imagen:

Formulario de creación de CSR

Como se puede observar en la imagen, un CSR puede almacenar información variada sobre el solicitante. Todos estos datos son opcionales, sin embargo, para este certificado será indispensable mantener el valor por defecto que aparece en el campo Common Name, el cual contiene el nombre completo del equipo donde se está generando el CSR. Esto es muy importante, ya que el sistema cliente podría validar durante el handshake que el valor de este campo concuerde con el nombre del servidor al cual se está efectuando la conexión, si no concuerdan, esta podría fallar.

Guardar el CSR con el nombre Message Broker Server.csr en el directorio de trabajo. Utilizar como key label el valor Message Broker Server.

4. Firmar CSR de servidor

Una vez creado el CSR, es necesario que sea firmado por la CA. Para esto ejecutamos el siguiente comando:

C:\tmp\Certificados>openssl ca -extensions server_cert -cert "Message Broker CA.cert" -days 375 -notext -md sha256 -in "Message Broker Server.csr" -out "Message Broker Server.cert"

Este comando solicita la contraseña de la llave privada de la CA (12345) y una confirmación. Al aceptarla se crea el certificado con el nombre Message Broker Server.crt. Este será el certificado de servidor. Ahora este debe ser importado al keystore.

5. Importar certificado de servidor al keystore

Con el certificado en mano, es hora de importarlo al keystore. Para esto se debe seleccionar en el keystore la opción Personal Certificates (1), y mediante el botón Receive (2) seleccionar el certificado recién creado (3). Esto se muestra en la siguiente imagen:

Importar certificado de servidor firmado por la CA

Al aceptar el dialogo se muestra el siguiente mensaje:

Este mensaje indica que los certificados de la CA no están en el keystore. Esto es normal, ya que estos irán en un truststore, a crear más adelante. En este punto el keystore está listo.

6. Crear CSR de cliente

Al igual que para el certificado del servidor, para el certificado de cliente se debe generar primero un CSR. La diferencia es que este CRS no será generado desde un keystore, sino que se creará mediante un comando de OpenSSL

6.1 Crear llave privada de cliente

Un CSR debe estar asociado a una llave privada, la cual se convertirá en la llave privada del certificado. Para generar esta llave utilizar el siguiente comando:

openssl genrsa -aes256 -out "cliente prueba.key" 2048

El comando solicita una contraseña para cifrar la llave a crear, utilizar 12345. Esto genera un archivo denominado cliente prueba.key en el directorio de trabajo.

6.2 Crear CSR de cliente

Para el CSR de cliente utilizar el siguiente comando:

openssl req -key "cliente prueba.key" -new -sha256 -out "cliente prueba.csr"

El comando va a solicitar la contraseña de la llave privada (12345). Luego solicitará los datos que conformarán el CSR. A continuación un ejemplo:

openssl req -key "cliente prueba.key" -new -sha256 -out "cliente prueba.csr"

Enter pass phrase for cliente prueba.key:
Loading 'screen' into random state - done
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:CR
State or Province Name [England]:SJ
Locality Name []:SJ
Organization Name [Alice Ltd]:XYZ
Organizational Unit Name []:ABC
Common Name []:CLIENTE PRUEBA
Email Address []:

Ingresar datos de pruebas. Completado este comando ya tenemos la llave privada y el CSR del cliente. El siguiente paso es firmar el CSR.

7. Firmar CSR de cliente

El comando es el siguiente.

openssl ca -extensions usr_cert -cert "Message Broker CA.cert" -days 375 -notext -md sha256 -in "cliente prueba.csr" -out "cliente prueba.cert"

Como se puede ver, es muy similar al comando que se utilizó para firmar el CSR del servidor, la única diferencia es el parámetro -extensións, en este caso se utiliza el valor usr_cert mientras que para el servidor se utilizó server_cert. Este valor le indica a la CA que al firmar el certificado debe establecerle como usos posibles la autenticación de usuarios. Si esto no se establece, es definitivo que el handshake va a fallar.

8. Exportar certificado de cliente junto a su llave privada

Completado del proceso de firma, se tendrán en la carpeta de trabajo 3 archivos para el cliente: cliente prueba.csr, cliente prueba.key, y cliente prueba.cert. Estos dos últimos serán exportados en un archivo PKCS #12. En este se unifica el certificado junto a su llave privada y será utilizado desde SoapUI al momento de consumir el servicio, su extensión es pfx.. El comando para su generación es el siguiente:

openssl pkcs12 -export -out "cliente prueba.pfx" -inkey "cliente prueba.key" -in "cliente prueba.cert"

Loading 'screen' into random state - done
Enter pass phrase for cliente prueba.key:
Enter Export Password:
Verifying - Enter Export Password:

El comando solicita la contraseña de la llave privada y pide una nueva contraseña para proteger el archivo pfx. Utilizar 12345. La salida del comando será el archivo cliente prueba.pfx ubicado en el directorio de trabajo. Este archivo pfx puede ser importado al almacén de certificados de Windows o ser utilizado directamente por algunas herramientas, en este caso, SoapUI

9. Crear truststore e importar certificados de CA

Como se indicó en el diagrama mostrado en la introducción, adicional al keystore existe tambien el truststore, cuyo propósito es contener los certificados de la cadena de confianza de la CA. Un truststore se crea exactamente igual que el keystore, mediante la herramienta ikeyman.

9.1 Crear truststore

Iniciar desde la consola la herramienta ikeyman y crear un nuevo repositorio. Guardarlo en el directorio de trabajo con el nombre truststore.jks. Protegerlo con la contraseña 12345.

9.2 Importar certificado de CA al truststore

Con el truststore creado, seleccionar la opción "Signer Certificates", y oprimir el botón "Add". Esto muestra un dialogo para seleccionar el certificado de CA a importar. Seleccionar el archivo Message Broker CA.crt. Colocar como etiqueta el valor "Message Broker CA". Esto se muestra en la siguiente imagen:

Importar certificado de CA al truststore

Debe ahora aparecer en la lista de certificados, uno con el nombre "message broker ca". Cerrar el ikeyman.

10. Asociar el keystore y el truststore al IWMB

Con el keystore y el truststore creados y configurados, es hora de asociarlos al IWMB. Esto se efectúa únicamente mediante línea de comandos (al menos en la versión 8). En primer lugar, analizaremos cuales propiedades tenemos que modificar. Para esto, ejecutamos el siguiente comando:

mqsireportproperties NOMBREBROKER -o BrokerRegistry -r BrokerRegistry

La salida en un IWMB que no haya sido configurado previamente, será similar a la siguiente:

mqsireportproperties NOMBREBROKER -o BrokerRegistry -r

BrokerRegistry
  uuid='BrokerRegistry'
  brokerKeystoreType='JKS'
  brokerKeystoreFile=''
  brokerKeystorePass='brokerKeystore::password'
  brokerTruststoreType='JKS'
  brokerTruststoreFile=''
  brokerTruststorePass='brokerTruststore::password'
  httpConnectorPortRange=''
  httpsConnectorPortRange=''
  allowSSLv3='true'
  reenableTransportAlgorithms=''
  reenableCertificateAlgorithms=''
  modeExtensions=''
  operationMode='advanced'
  shortDesc=''
  longDesc=''

BIP8071I: Successful command completion.

Este comando muestra el valor actual de múltiples propiedades, sin embargo, para esta configuración son importantes las siguientes:

- brokerKeystoreFile: Ruta completa al archivo keystore.jk
- brokerTruststoreFile: Ruta completa al archivo truststore.jk
- brokerTruststorePass: Contraseña del truststore
- brokerKeystorePass: Contraseña del keystore

Para establecer la ruta del keystore utilizar el siguiente comando:

mqsichangeproperties NOMBREBROKER -o BrokerRegistry -n brokerKeystoreFile -v "C:\tmp\Certificados\keystore.jks"

Un comando muy similar se utiliza para establecer el truststore

mqsichangeproperties NOMBREBROKER -o BrokerRegistry -n brokerTruststoreFile -v "C:\tmp\Certificados\truststore.jks"

Para establecer la contraseña del keystore ejecutar lo siguiente:

mqsisetdbparms NOMBREBROKER -n brokerKeystore::password -u temp -p 12345

y para el truststore:

mqsisetdbparms NOMBREBROKER -n brokerTruststore::password -u temp -p 12345

11. Habilitar HTTPS mediante certificado de servidor

Es hora de ir al Message Broker Toolkit a construir el flujo que utilizará esta arquitectura. Para facilitar las cosas, adjunto un sencillo flujo desarrollado en toolkit v8. Igual para otras versiones más recientes tambien debería funcionar. Este flujo simplemente retorna la hora actual del Message Broker.

ConsultarHoraIWMB.zip

Es necesario entonces publicar el flujo en nuestro ambiente de Broker y referenciarlo desde el SoapUI. El URL para agregar la referencia es el siguiente:

http://SERVIDORBROKER:PUERTO/consultas/hora?wsdl

Incluida la referencia en el SOAPUI, invocarlo mediante el siguiente mensaje:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:hor="http://www.notasinfornatica.com/consultas/horabroker">
  <soapenv:Header/>
     <soapenv:Body>
 <hor:ConsultarHoraActual/>

     </soapenv:Body>
</soapenv:Envelope>

La respuesta debería ser similar a la siguiente:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <io:ConsultarHoraActualResponse xmlns:io="http://www.notasinfornatica.com/consultas/horabroker">
         <Resultado>2017-05-26T13:57:59</Resultado>
      </io:ConsultarHoraActualResponse>
   </soapenv:Body>
</soapenv:Envelope>

Es momento de habilitar el uso HTTPS en el nodo SOAPInput. Esto permitirá crear un canal seguro entre el cliente y el servidor, sin embargo, aún no existirá autenticación mutua, es decir, el servidor aún no verificará la identidad del cliente, esto se activará más adelante.

Para habilitar HTTPS, se debe activar la propiedad "Use HTTPS" en el nodo SOAP Input del flujo MF_Principal. Realizado esto, publicar de nuevo. Si todo se ha configurado correctamente, el flujo ya puede ser consumido en un canal seguro. Verificarlo invocando nuevamente el servicio desde el SoapUI con la siguiente dirección:

https://SERVIDORBROKER:PUERTOHTTPS/consultas/hora

Como se puede observar, el URL ahora inicia con HTTPS y el puerto es distinto. Para conocer que puerto utilizar, se puede ejecutar el siguiente comando:

mqsireportproperties NOMBREBROKER -e GRUPOEJECUCION -o HTTPSConnector -n port

No se debe efectuar ningún cambio en SoapUI (aparte del URL) para efectuar la consulta, la diferencia es a nivel interno, ya que se debe efectuar un handshake entre el cliente y el servidor.

Otra forma de verificar que el mecanismo está funcionando, es copiar el URL (agregar ?wsdl) del servicio en el explorador de internet, en cuyo caso se debe desplegar el respectivo WSDL, tal y como se muestra en la siguiente imagen:

Verificar HTTPS mediante google chrome

Para evitar las advertencias de seguridad que genera el explorador, como la que se visualiza en la imagen, al lado izquierdo de la barra de direcciones (No es seguro), se debe registrar el certificado de la CA en el almacén de certificados del equipo. A pesar de estas advertencias, la conexión ya se encuentra cifrada.

12. Activar validación de certificado del cliente (autenticación mutua)

Para activar la validación de certificado de cliente, ejecutar el siguiente comando:

mqsichangeproperties NOMBREBROKER -e GRUPOEJECUCION -o HTTPSConnector  -n clientAuth -v true 


Reiniciar el grupo de ejecución

Probar de nuevo el servicio desde SoapUI. Se debería obtener un error similar al de la siguiente imagen:

Error en SoapUI al activar autenticación mutua

Igualmente desde el browser ya no se puede obtener el WSDL. Esto se muestra en la siguiente imagen:

Error de autenticación al intentar visualizar el WSDL en google chrome

Para consumir el servicio desde SoapUI, se debe referenciar el archivo pfx generado en pasos previos, tal y como se muestra en la siguiente imagen.

Esto se configura en la opción File - Preferences - SSL Settings, se selecciona el archivo pfx y se ingresa su contraseña. Realizado esto, se puede consumir el servicio nuevamente y el resultado debería ser satisfactorio.

Bueno, esto es todo, espero haberme explicado y que  les sea de utilidad.