Взаимная аутентификация Tomcat SSL для нескольких служб

У меня есть веб-приложение, развернутое на tomcat 8, которое использует веб-службы из двух разных систем, каждая из которых требует взаимной аутентификации. Теперь мне нужно интегрировать мое приложение с двумя разными клиентскими сертификатами или, можно сказать, двумя разными хранилищами ключей с разными паролями. Теперь у меня возникли трудности с использованием правильного сертификата для обеих служб.

Я вызываю одну из служб, используя свой собственный код, но вторая служба вызывается из сторонней библиотеки, и я не могу контролировать ее код вызывающего абонента. Если я использую какое-либо одно хранилище ключей, соответствующий вызов службы будет успешным, а другой - неудачным.

Я пробовал следовать подходам, но не все из них -

  1. Я создал новое хранилище ключей и добавил оба сертификата в хранилище ключей и установил javax.net.ssl.keyStore, javax.net.ssl.trustStore и соответствующие пароли в переменных среды. Это делает успешным только один сервисный вызов.
  2. Я удалил указанные выше переменные среды и вызвал одну службу с программно настроенным контекстом SSL (что-то вроде Доступ к Https Rest Service с помощью Spring RestTemplate). Это приводит к тому, что одна услуга оказывается успешной, а другая не работает (очевидно).
  3. Я настроил javax.net.ssl.keyStore, javax.net.ssl.trustStore и соответствующие пароли, содержащие один ключ, только для одной службы и установил SSLContext для другой службы программно, как на предыдущем шаге. Это приводит к сбою службы, которая была успешной на шаге 2 (может быть, другое хранилище ключей отменяет это?) И успеху другой службы.
  4. Я попытался изменить пароли ключей, чтобы они совпадали друг с другом, а также с хранилищем ключей. Это также приводит к отказу одной службы.

Любые предложения, что я мог бы попробовать дальше, или в чем проблема на самом деле с вышеуказанными подходами?


person N..    schedule 03.08.2017    source источник


Ответы (1)


Извините .. не проверял должным образом .. подход 3 сработал ..

person N..    schedule 04.08.2017