Добавить сертификат в Mirth Keystore - PullRequest
Новая
       34

Добавить сертификат в Mirth Keystore

1 голос
/ 25 апреля 2020

Кажется, это должно быть просто. Я хотел бы иметь возможность доверять сертификатам, полученным от сервисов, от которых зависит Mirth, без изменения глобального хранилища сертификатов Java (или без добавления нескольких штук на экземпляр для плагина SSL). Я пробовал следующее:

Создание собственного хранилища ключей:

Команды Keytool: 

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

In этот экземпляр Мирт полностью не запускается. Первая ошибка из журнала: 

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)

Обновление встроенного хранилища ключей Mirth:

Команды Keytool: 

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)

Обновление Java глобального хранилища ключей

Команды Keytool: 

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 просто не перезапишут магазин.

1 Ответ

1 голос
/ 03 мая 2020

Через путь слишком много проб и ошибок, вот что я смог выучить:

  1. Собственные отправители / получатели Mirth используют хранилище Mirth Keystore, определенное в Mirth. свойства. Импорт сертификатов, как описано выше, будет работать для этих каналов.

  2. Если вы используете движок Rhino (например, Java / JavaScript) для отправки / получения http-запросов, хранилище ключей Mirth игнорируется и используется глобальное хранилище Java. Опять же, процесс, описанный выше, работает. Так как мои сертификаты получены из Windows, оказалось, что я смог немного упростить, добавив -Djavax.net.ssl.trustStoreType=WINDOWS-ROOT к Mirth.properties, и мои полевые техники не суетились с Java keytool

Причина, по которой я не видел, чтобы каналы Mirth работали изначально, заключается в том, что сценарий развертывания моего канала получает токен доступа от поставщика аутентификации, и я не думал проверять отправителя канала независимо. Я не думал, что будет иметь значение, буду ли я делать что-то программно или настраивать каналы с помощью пользовательского интерфейса, но, в общем-то, это Мирт для вас. : /

В любом случае, надеюсь, это когда-нибудь кому-нибудь поможет.

...