Почему один сертификат SSL не может использоваться для нескольких машин?

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

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

SSL-сертификаты привязаны к имени хоста. Таким образом, чтобы иметь возможность использовать его на своем компьютере разработчика, вы должны разрешить имя хоста на своем компьютере разработчика (т.е. использовать файл hosts)

Зависит от того, что вы подразумеваете под этим

Один групповой сертификат может использоваться для нескольких хостов с разными записями А.

Например, у вас есть сертификат с подстановочными знаками для домена. *.stackoverflow.com. Вы можете иметь одобренный CA протокол TLS, если на новых серверах, которые вы используете, используется поддомен домена stackoverflow.com

, т.е. mail-server.stackoverflow.com

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

Также, когда мы генерируем сертификаты с использованием инструментов PKI, вы можете предоставить произвольную строку для DN (например, «CN = xyz, OU = TTR, O = X "). Интересно, что будет, если разные машины используют один DN для создания сертификатов?

Я предполагаю, что вы описываете аутентификацию клиента SSL удаленной третьей стороне. То, что ваш продукт инициировал подключение к третьим частям как клиент, и третья сторона решает, достаточно ли ваш сертификат для подключения.

Сертификат, по сути, состоит из трех вещей:

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

Итак ... это немного больше, чем просто пароль, но это все данные, в конце концов.

Ответ на вопрос, можно ли установить SSL-сертификат клиента в нескольких местах, - да и нет. В основном это зависит от требований безопасности сторонней системы, а также от того, как вы сохранили этот закрытый ключ.

Можно сохранить пару секретного / открытого ключа и сертификат в файле - одним из стандартов для этого является PKCS # 12 . PKCS12 обычно защищаются паролем. Многие программные инструменты позволят вам создать пару ключей, сохранить ее в PKCS12 и выполнить различные протоколы сертификатов, необходимые для запроса и завершения выдачи сертификата от третьей стороны (я подозреваю, что ваша третья сторона требует, чтобы ваш сертификат был подписан одним из них). списка доверенных эмитентов). Каждый сервер приложений, который я видел, позволял вам настроить файл сертификата в качестве сертификата на стороне клиента.

Если именно так хранится сертификат QA SSL, тогда не должно возникнуть проблем с его установкой на ваш компьютер.

Вот подвох - иногда политика безопасности предписывает хранить сертификаты на аппаратном токене. Обычно это мера безопасности, гарантирующая, что только один объект может использовать сертификат. Копирование файлов сертификатов программного обеспечения прекрасно работает в тестовой среде, но это довольно плохая практика безопасности для установки работающего продукта. Если сервер QA использует аппаратный токен, аппаратное обеспечение, скорее всего, защитит копирование пары секретных ключей в другое место. Без доступа к паре секретных ключей вы не сможете выполнить запрос SSL стороннему лицу - демонстрация доступа к закрытому ключу является частью протокола.

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

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

This is definitely possible to do, how else would servers work in a web farm? All servers in a web farm have the same certificate installed.

I don't have experience on Apache but for IIS the process is documented here http://support.microsoft.com/kb/313299

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