这似乎应该很简单。我希望能够信任来自Mirth依赖的服务的证书,而无需修改全局Java证书存储(或为SSL插件在每个实例中删除一些盛行)。我尝试了以下方法:
键盘工具命令:
keytool -genkey -keystore appdata\my.jks -storetype PKCS12 -keyalg RSA -keysize 2048 -storepass xxxxxxxx
keytool -importcert -alias my-ca-cert -file myCaCert.pem -keystore appdata\my.jks -trustcacerts -storepass xxxxxxxx
keytool -importcert -alias my-server-cert -file myServerCert.pem -keystore appdata\my.jks -trustcacerts -storepass xxxxxxxx
Mirth.properties:
keystore.path = ${dir.appdata}/my.jks
keystore.storepass = xxxxxxxx
keystore.keypass = xxxxxxxx
keystore.type = pkcs12
在这种情况下,Mirth完全无法启动。日志中的第一个错误是
java.io.IOException: Invalid keystore format
at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:724)
at java.security.KeyStore.load(Unknown Source)
at com.mirth.connect.server.MirthWebServer.createSSLConnector(MirthWebServer.java:370)
at com.mirth.connect.server.MirthWebServer.<init>(MirthWebServer.java:150)
at com.mirth.connect.server.Mirth.startWebServer(Mirth.java:385)
at com.mirth.connect.server.Mirth.startup(Mirth.java:265)
at com.mirth.connect.server.Mirth.run(Mirth.java:154)
键盘工具命令:
keytool -importcert -alias my-ca-cert -file myCaCert.pem -keystore appdata\keystore.jks -trustcacerts -storetype jceks -storepass xxxxxxxx
keytool -importcert -alias my-server-cert -file myServerCert.pem -keystore appdata\keystore.jks -trustcacerts -storetype jceks -storepass xxxxxxxx
Mirth.properties:
keystore.path = ${dir.appdata}/keystore.jks
keystore.storepass = xxxxxxxx
keystore.keypass = xxxxxxxx
keystore.type = JCEKS
在这种情况下,Mirth完全启动,但是服务器证书无效。错误日志为
DETAILS: JavaException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at 69352923-b68f-4e96-95a3-ad7681a7f3c1_Deploy:112 (doScript)
at 69352923-b68f-4e96-95a3-ad7681a7f3c1_Deploy:118
at com.mirth.connect.server.util.javascript.JavaScriptUtil.executeScript(JavaScriptUtil.java:547)
at com.mirth.connect.server.util.javascript.JavaScriptUtil$2.doCall(JavaScriptUtil.java:379)
at com.mirth.connect.server.util.javascript.JavaScriptTask.call(JavaScriptTask.java:113)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
键盘工具命令:
keytool.exe -importcert -alias my-ca-cert -file myCaCert.pem -keystore cacerts -storepass xxxxxxxx
keytool.exe -importcert -alias my-server-cert -file myServerCert.pem -keystore cacerts -storepass xxxxxxxx
Mirth.properties :(与上面相同)
keystore.path = ${dir.appdata}/keystore.jks
keystore.storepass = xxxxxxxx
keystore.keypass = xxxxxxxx
keystore.type = JCEKS
这行得通,但并不理想,因为它使部署变得复杂(我们无法控制客户环境),而且我不确定Java升级不会简单地覆盖商店。
答案 0 :(得分:2)
通过方式反复尝试,这是我能学到的:
本机Mirth发送者/接收者本身使用Mirth.properties中定义的Mirth密钥库。如上所述导入证书将适用于这些渠道。
如果您使用Rhino引擎(例如Java / JavaScript)发送/接收http请求,则会忽略Mirth密钥库,并使用全局Java存储。再次,上述过程起作用。由于我的证书来自Windows,事实证明,我可以通过在Mirth.properties中添加-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT
来简化一点,而我的现场技术人员不会对Java的keytool感到困惑
之所以我最初没有看到Mirth通道起作用的原因是,我的通道的部署脚本从auth提供商获取了访问令牌,因此我不认为要独立测试通道发送者。我不认为我是通过编程方式执行操作还是通过UI配置通道都无关紧要,但是,这对您来说是一件好事。 :/
无论如何,希望有一天能对某人有所帮助。