SSL подписал сертификаты для внутреннего пользования
У меня есть распределенное приложение, состоящее из многих компонентов, которые связываются по TCP (для примера JMS) и HTTP. Все компоненты работают на внутренних аппаратных средствах, с внутренними IP-адресами, и не доступны для общественности.
Я хочу сделать коммуникацию безопасным использованием SSL. Имеет смысл покупать подписанные сертификаты у известного центра сертификации? Или я должен просто использовать самоподписанные сертификаты?
Мое понимание преимущества доверяемых сертификатов - то, что полномочия являются объектом, которому может доверять широкая публика - но это - только проблема, когда широкая публика должна быть уверена, что объект в конкретном домене - то, кто они говорят, что они.
Поэтому в моем случае, где та же организация ответственна за компоненты в обоих концах коммуникации и всем промежуточном, публично доверяемые полномочия были бы бессмысленны. Другими словами, если я генерирую и подписываю сертификат для своего собственного сервера, я знаю, что это защищено. И никого снаружи организации никогда не будут просить доверять этому сертификату. Это - мое обоснование - я корректен, или там некоторое потенциальное преимущество к использованию сертификатов от известных полномочий?
3 ответа
Пока ваша система работает внутри вашей группы и нет планов по ее расширению (а планы меняются, так что имейте это в виду), все в порядке. чтобы настроить собственную простую инфраструктуру PKI.
Если вы в конечном итоге выйдете за пределы своей организации, все, что вам нужно сделать, это распространить свой корневой сертификат среди сторон, с которыми вы будете общаться. Это дает вашим партнерам точный контроль над тем, насколько они доверяют вам по сравнению с общедоступной инфраструктурой центра сертификации.
Вам не нужно использовать внешний публичный ЦС для закрытого общественного проекта. Во многих более крупных организациях используется внутренняя PKI для выдачи сертификатов для таких внутренних проектов. Преимущество использования PKI заключается в том, что вы можете установить доверительные отношения между различными компонентами на основе одного надежно распределенного корневого сертификата / якоря доверия.
Однако, если проект позволял внутренним пользователям безопасно подключаться к внутренней службе через их веб-браузер, вы можете рассмотреть возможность использования сертификата, выпущенного общедоступным центром сертификации. Альтернативный вариант - убедиться, что каждый браузер, которому может потребоваться подключение к вашей службе, доверяет вашему корневому сертификату; это сделано для предотвращения сообщений браузера с предупреждениями.
Я бы сказал, что это достаточно безопасно, если только вы не думаете, что ниндзя-лазутчик поменяет ваш сервер на вас.
Третья сторона призвана усложнить создание и создание нового сертификата. Кто-то может воссоздать самозаверяющий сертификат на новом компьютере с теми же данными, это будет не тот же сертификат, вам также придется добавить исключение для него, но ваши пользователи, вероятно, не заметят разницы .