Mirth：使用客户端证书调用 SSL SOAP Web 服务
该场景围绕从 Mirth 中调用外部 SSL SOAP Web 服务进行。 Web 服务需要 SSL/TLS 连接以及客户端证书。
目的是使用内置的 SOAP 发送方目标来调用远程安全 Web 服务，并以某种方式包含该客户端证书。
据我所知，您首先需要将该客户端证书安装到 Java 运行时中。 这可能位于 Java 运行时的证书存储区或 Jetty 证书存储区中。
平台：
- Windows 2003 SP2
- Mirth 1.8
- Java jre1.5.0_09
问题：您建议采用哪些配置步骤（Mirth、JRE 证书存储等）才能成功让 Mirth SOAP 发送器包含客户端证书（ *.cer) 调用受 SSL 保护的 Web 服务时？
The scenario is around calling an external SSL SOAP web service from within Mirth. The web service is requires an SSL/TLS connection along with a client certificate.
The intention is to use the built-in SOAP Sender Destination to call the remote secure web service, and somehow include that client certificate.
I understand that you first need to install that client certificate into the Java runtime. This may be within the Java runtime's certificate store or the Jetty certstore.
The platform:
- Windows 2003 SP2
- Mirth 1.8
- Java jre1.5.0_09
Question: what configuration steps (Mirth, JRE certificate stores, etc.) would you suggest to successfully have a Mirth SOAP Sender include a client certificate (*.cer) when calling a web service secured by SSL?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果设置了某些系统属性，Java 运行时（或更具体地说，Sun JSSE 提供程序）将提供客户端证书。 您可以在 JSSE 参考中阅读详细信息指南，，但重要的属性是
javax.net.ssl.keyStore和javax.net.ssl.keyStorePassword。这种方法有一些缺点。 首先，将密钥存储密码设置为系统属性，使得该进程中运行的任何代码都可以访问该密码，尽管如果安装了
SecurityManager，则可以控制这一点。 其次，这些设置将用于通过“默认”SSLContext创建的任何 SSL 套接字。 如果您需要针对不同端点使用不同的凭据，则需要特定于 Mirth 的解决方案。问题中没有指定起点，但如果从头开始，最简单的方法是创建一个新的 Java 密钥存储（“JKS”格式）并生成新的密钥对和 CSR。 将 CSR 发送到 CA 并取回证书后，将其导入到同一密钥存储中。 该密钥库已准备好使用。
如果证书已可用，则它可能与相应的私钥一起以 PKCS#12 格式（.p12 或 .pfx 文件）存储。 这些可以直接由 Java 应用程序使用，但
javax.net.ssl.keyStoreType属性需要设置为"PKCS12"The Java runtime, or more specifically, the Sun JSSE provider, will present a client certificate if some system properties are set. You can read details in the JSSE Reference Guide, but the important properties are
javax.net.ssl.keyStoreandjavax.net.ssl.keyStorePassword.There are a few drawbacks to this approach. First, setting the key store password as a system property makes it accessible to any code running in that process—although this can be controlled if a
SecurityManageris installed. Second, these settings will be used for any SSL sockets created through the "default"SSLContext. If you need different credentials for different endpoints, you'll need a Mirth-specific solution.No starting point was specified in the question, but if starting from scratch, the easiest approach is to create a new Java Key Store ("JKS" format) and generate a new key pair and a CSR. After sending the CSR to the CA and getting a certificate back, import it into the same key store. That key store is ready to use.
If a certificate is already available, it is likely to be in a stored with its corresponding private key in PKCS #12 format (.p12 or .pfx file). These can be used directly by a Java application, but the
javax.net.ssl.keyStoreTypeproperty will need to be set to"PKCS12"Mirth 1.8 在调用 SOAP Web 服务时无法发送客户端证书。
Mirth 1.8 cannot send a client cert when calling a SOAP web service.
我来晚了一点，但实际上有可能。 通过向 JVM 发送一些配置参数，您可以让底层 SOAP 引擎切换到 HTTP 并提供正确的证书。
请参阅此问题，详细了解要设置哪些参数来配置 VM
Java HTTPS 客户端证书身份验证
您会注意到有很多事情需要注意。 通常，一旦正确配置了证书，HTTP 和客户端身份验证就应该“正常工作”。 但有些服务器对 B2B 类型的客户不太友好，所以你必须小心。
使用 JDK 6_21 并对证书进行一些调整，我能够让其中一台服务器正常运行，但对于我们来说，需要大约 15 分钟才能在服务器上正确配置，这对我们来说是漫长而痛苦的。
这是解决这个问题的另一个问题（对不友好服务器的客户端身份验证）。
客户端 SSL 身份验证导致 IIS 出现 403.7 错误
I'm late a bit here for this but actually there is a possibility that it could. By sending a few config parameters to the JVM you could get the underlying SOAP engine to switch to HTTPs and provide the proper certificate.
refer to this question for details on which parameters to set for configuring the VM
Java HTTPS client certificate authentication
you will notice there are quite a few things to take care of. Normally HTTPs and client authentication should "just work" once you configured your certificates appropriately. BUT there are some servers out there that are not so friendly to B2B style clients so you have to watch out.
Using JDK 6_21 and a few tweaks with the certificate I was able to get one of them servers to behave but it was long and painful on our side for something that takes about 15 minutes to configure properly on the server.
here is another question that address this very issue (client side authentication towards unfriendly servers).
Client SSL authentication causing 403.7 error from IIS