Pregunta

El escenario consiste en llamar a un servicio web SSL SOAP externo desde Mirth.El servicio web requiere una conexión SSL/TLS junto con un certificado de cliente.

La intención es utilizar el destino del remitente SOAP integrado para llamar al servicio web seguro remoto y de alguna manera incluir ese certificado de cliente.

Entiendo que primero necesita instalar ese certificado de cliente en el tiempo de ejecución de Java.Esto puede estar dentro del almacén de certificados del tiempo de ejecución de Java o del almacén de certificados Jetty.

La plataforma:

  • Ventanas 2003 SP2
  • Alegría 1.8
  • Java jre1.5.0_09

Pregunta:¿Qué pasos de configuración (Mirth, almacenes de certificados JRE, etc.) sugeriría para que un remitente Mirth SOAP incluya un certificado de cliente (*.cer) al llamar a un servicio web protegido por SSL?

¿Fue útil?

Solución 2

Mirth 1.8 no puede enviar un certificado de cliente al llamar a un servicio web SOAP.

Otros consejos

El tiempo de ejecución de Java, o más específicamente, el proveedor Sun JSSE, presentará un certificado de cliente si se configuran algunas propiedades del sistema.Puedes leer los detalles en el Guía de referencia JSSE, pero las propiedades importantes son javax.net.ssl.keyStore y javax.net.ssl.keyStorePassword.

Este enfoque tiene algunos inconvenientes.En primer lugar, establecer la contraseña del almacén de claves como propiedad del sistema la hace accesible a cualquier código que se ejecute en ese proceso, aunque esto se puede controlar si se SecurityManager esta instalado.En segundo lugar, esta configuración se utilizará para cualquier socket SSL creado mediante la configuración "predeterminada". SSLContext.Si necesita diferentes credenciales para diferentes puntos finales, necesitará una solución específica de Mirth.

No se especificó ningún punto de partida en la pregunta, pero si se comienza desde cero, el enfoque más sencillo es crear un nuevo almacén de claves Java (formato "JKS") y generar un nuevo par de claves y una CSR.Después de enviar la CSR a la CA y recuperar un certificado, impórtelo al mismo almacén de claves.Ese almacén de claves está listo para usar.

Si ya hay un certificado disponible, es probable que esté almacenado con su correspondiente clave privada en formato PKCS #12 (archivo .p12 o .pfx).Estos pueden ser utilizados directamente por una aplicación Java, pero el javax.net.ssl.keyStoreType La propiedad deberá establecerse en "PKCS12"

Llegué un poco tarde para esto, pero en realidad existe la posibilidad de que así sea.Al enviar algunos parámetros de configuración a la JVM, puede lograr que el motor SOAP subyacente cambie a HTTP y proporcione el certificado adecuado.

consulte esta pregunta para obtener detalles sobre qué parámetros establecer para configurar la VM

Autenticación de certificado de cliente Java HTTPS

Notarás que hay bastantes cosas de las que ocuparte.Normalmente, HTTP y la autenticación del cliente deberían "simplemente funcionar" una vez que haya configurado sus certificados adecuadamente.PERO hay algunos servidores que no son tan amigables con los clientes de estilo B2B, así que debes tener cuidado.

Usando JDK 6_21 y algunos ajustes con el certificado, pude hacer que uno de esos servidores se comportara, pero fue largo y doloroso de nuestra parte para algo que demora aproximadamente 15 minutos en configurarse correctamente en el servidor.

Aquí hay otra pregunta que aborda este mismo problema (autenticación del lado del cliente hacia servidores hostiles).

Autenticación SSL del cliente que provoca el error 403.7 de IIS

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top