Решения для подписи сертификатов

Для системы с несколькими серверами приложений и несколькими клиентами я хотел бы ввести взаимную аутентификацию, а также другие меры безопасности, предоставляемые TLS.

Серверы и клиенты могут находиться как в разных сетях, так и в одной сети.

У каждого объекта (клиента или сервера) есть собственное хранилище ключей, в котором хранится пара закрытый/открытый ключ и сертификат X.509, в который заключен открытый ключ. Но на данный момент сертификат является самоподписанным. Таким образом, это не будет проверено другими взаимодействующими объектами. После некоторых исследований я рассмотрел некоторые решения:

  1. Создание частного ЦС, который будет подписывать сертификаты. Насколько я понимаю, сертификат ЦС должен присутствовать в хранилище доверенных сертификатов каждого объекта, чтобы сертификаты других объектов можно было проверить с использованием сертификата ЦС.
  2. Создание частного центра сертификации в качестве первого решения. Но сертификат частного ЦС подписан коммерческим ЦС (например, Verisign). Я не знаю, что это добавляет к предыдущему решению.
  3. Подписание сертификата каждого объекта коммерческим ЦС. Но это решение кажется дорогим.
  4. Использование только самоподписанных сертификатов. Сертификат каждого объекта является самоподписанным им и должен быть добавлен в хранилище доверенных сертификатов каждого объекта, с которым он хочет взаимодействовать.

Это мой первый опыт работы с безопасностью. Какое из решений, которые вы считаете правильными, вы рекомендуете?

Спасибо


person Mickael Marrache    schedule 19.07.2012    source источник
comment
Обратите внимание на CAcert.   -  person    schedule 19.07.2012


Ответы (1)


Я пронумеровал ваши варианты для облегчения чтения.

Ваш вариант 4 имеет такие же особенности безопасности и управления, как и первый. т.е. ваши варианты ограничены собственными или сторонними службами CA. Хотя вы можете купить свой собственный сертификат ЦС в органе ЦС, это будет стоить, ммм, дорого. Но сколько это "много" определяется в каждом конкретном случае продавцами CA.

По сложности управления я бы расположил их в следующем порядке (первый самый простой): 3, 1, 2, 4.

В вариантах 1, 2, 4 вы должны управлять своими сертификатами, что требует как знания PKI, так и процедур ее безопасности (помимо чисто технических, вам нужно будет убедиться, что закрытые ключи защищены), а также программного обеспечения для создания сертификатов и управления ими (openssl и т.п.). для большинства активностей будет недостаточно, и, скорее всего, вам потребуется написать собственный код для генерации сертификата).

Также неплохо иметь сервер OCSP, который вам придется запускать самостоятельно в случае вариантов 1, 2, 4.

person Eugene Mayevski 'Callback    schedule 19.07.2012
comment
Я также надеюсь, что не все могут получить промежуточный ЦС (вариант 2), поскольку они могут выдавать сертификаты для чужих машин и распознавать их любым браузером. - person Bruno; 19.07.2012
comment
Спасибо за Ваш ответ. Знаете ли вы о какой-либо документации по созданию вашего частного центра сертификации? - person Mickael Marrache; 19.07.2012
comment
@MickaelMarrache, вас может заинтересовать этот вопрос. - person Bruno; 19.07.2012
comment
@Бруно Спасибо за ссылку. Я также нашел это руководство — fusesource.com/docs/broker/5.3/security/ i305153.html. Что вы думаете? - person Mickael Marrache; 19.07.2012
comment
@MickaelMarrache Я бы посоветовал прочитать одну или две книги об инфраструктуре PKI (например, amazon.com/gp/product/0072131233). Статей будет недостаточно, потому что помимо кода в вашем вопросе есть аспект управления инфраструктурой, и это очень важно, даже важнее, чем кодирование. - person Eugene Mayevski 'Callback; 19.07.2012
comment
@Bruno, поскольку они могут выдавать сертификаты для машин, которые им не принадлежат, и распознавать их любым браузером. ЦС может ограничить имена, для которых суб-ЦС может генерировать сертификаты. См. расширения ExtendedKeyUsage и NameConstraints (раздел 4.2.1.10 RFC5280). - person Patrick Mevzek; 13.09.2019