Нужна помощь в настройке цепочки полномочий склада доверенных сертификатов (в Tomcat)

Question

Примите участие ... Я пока не являюсь экспертом в области безопасности приложений через SSL, но я пытаюсь создать тестовую среду, включающую все возможные сценарии, с которыми мы можем столкнуться в производственном процессе.Для этого у меня есть дерево Центров сертификации (CA), которые являются источниками набора тестовых клиентских сертификатов и сертификатов узлов / серверов (сложная тестовая среда, представляющая различные опубликованные веб-службы и другие приложения, с которыми мы интегрируемся).

Структура этих CA является следующей: Корневой CA, который подписал / выпустил Sub CA1, Sub CA2 и Sub CA3.Затем эти подпрограммы подписали / выпустили все сертификаты этих различных узлов и клиентов в среде.

Теперь вопрос ... В доверенном хранилище моего приложения я бы хотел доверять всему, что подписано Sub CA1 и SubCA2, но не Sub CA3 (ненадежный).Означает ли это, что мое доверенное хранилище должно (1) ТОЛЬКО включать Sub CA1 и Sub CA2, или (2) должно ли оно включать Root CA, Sub CA1 и Sub CA2?

Я не знаю, как правильнопредставлять эту цепочку доверия в хранилище доверенных сертификатов.В будущем я также хотел бы добавить Sub CA4 (также подписанный / выданный корневым CA), но добавить его в список отзыва сертификатов (CRL) для целей тестирования.

Заранее спасибоза любую помощь по этому поводу.Это очень ценится.

Answer 1

ПРЕДУПРЕЖДЕНИЕ: Я не собираюсь проверять это, поэтому я надеюсь, что мой ответ правильный.

Я думаю, что ваше основное предположение верно. Я не верю, что вы можете выборочно отозвать доверие без написания собственного кода, поэтому ваше хранилище доверенных сертификатов должно содержать только сертификаты, которым доверяют полностью. Так что оставьте корневой CA вне и выберите ваш вариант (1).

Как вы можете видеть, попытка обеспечить такой точный контроль доступа не подходит для модели аутентификации на основе сертификатов X509 в Java (и в большинстве других систем). Они в основном предназначены для аутсорсинга проверки идентичности Verisign, Thawte, GoDaddy, GlobalSign и т. Д. Для сертификатов SSL и сертификатов подписи кода. Он может поддерживать другие модели, включая самозаверяющие сертификаты, но не без значительных предварительных проблем и постоянных проблем с обслуживанием.