SSL подписанные сертификаты для внутреннего использования - PullRequest
10 голосов
/ 20 апреля 2010

У меня есть распределенное приложение, состоящее из множества компонентов, которые взаимодействуют через TCP (например, JMS) и HTTP. Все компоненты работают на внутреннем оборудовании с внутренними IP-адресами и не являются общедоступными.

Я хочу сделать общение безопасным, используя SSL. Имеет ли смысл покупать подписанные сертификаты у известного центра сертификации? Или я должен просто использовать самозаверяющие сертификаты?

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

Следовательно, в моем случае, когда одна и та же организация отвечает за компоненты на обоих концах связи и все, что между ними, публично доверенный орган был бы бессмысленным. Другими словами, если я создаю и подписываю сертификат для своего собственного сервера, я знаю, что он заслуживает доверия. И никому из организации никогда не будет предложено доверять этому сертификату. Это мое рассуждение - я прав, или есть какое-то потенциальное преимущество использования сертификатов от известного авторитета?

Ответы [ 3 ]

4 голосов
/ 20 апреля 2010

Нет необходимости использовать внешний общедоступный центр сертификации для закрытого проекта сообщества. Во многих крупных организациях они используют внутреннюю PKI для выдачи сертификатов для внутренних проектов, подобных этой. Преимущество использования PKI состоит в том, что вы можете установить доверительные отношения между различными компонентами на основе одного надежно распределенного корневого сертификата / привязки доверия.

Однако, если проект позволил внутренним пользователям безопасно подключаться к внутренней службе через их веб-браузер, вы можете рассмотреть возможность использования сертификата, выданного общедоступным центром сертификации. Альтернативный вариант - убедиться, что каждый браузер, которому может потребоваться подключение к вашей службе, доверяет вашему корневому сертификату; это предотвращает появление предупреждений браузера.

0 голосов
/ 20 апреля 2010

Пока ваша система работает внутри вашей группы и нет планов по ее расширению (и планы меняются, помните об этом), просто настроить собственную простую инфраструктуру PKI.

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

0 голосов
/ 20 апреля 2010

Я бы сказал, что это достаточно безопасно, если только вы не думаете, что ниндзя-инфильтр собирается заменить ваш сервер на вас.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...