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

Сертификат SSL привязан к фактическому имени хоста. Если у вас есть сертификат SSL для «qa.example.com», он не будет работать на вашем компьютере с именем «dev.example.com».

Возможно, это проблема, с которой вы столкнулись.

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

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

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

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

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

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

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

Это определенно возможно сделать, как иначе серверы будут работать в веб-ферме? На всех серверах веб-фермы установлен один и тот же сертификат.

У меня нет опыта работы с Apache, но для IIS процесс задокументирован здесь http://support.microsoft.com/kb/313299

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

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

Есть несколько выходов из этого.

1. Используйте wildcard-сертификат.
2. Отключите проверку имени хоста и примите на себя повышенный риск.
3. Настройте проверку имени хоста.

См. http://support.godaddy.com/help/article/567/what-is-a-wildcard-ssl-certificate и http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HostnameVerifier.html

@Kyle Jones - Мой вопрос: почему я не могу использовать SSL-сертификат с сервера QA на своем локальном компьютере?

@autonomatt -- Подвопрос: VeriSign и другие компании спрашивают вас, на скольких серверах вы устанавливаете SSL-сертификат ... вам звонит странный клиент и сообщает, что их браузер сообщает о проблеме с сертификатом ...

Легально? Вы можете установить SSL-сертификат более чем на один компьютер, но, возможно, не сможете сделать это легально. Компания Signing CA, как и Network Solutions, имеет юридические ограничения на вашу покупку. Приобретая SSL-сертификат, вы приобретаете его для установки только на один компьютер. Вам следует прочитать условия подписывающего ЦС, у которого вы покупаете сертификат.

Технически? Технически, за исключением некоторых SSL-серверов с аппаратным ускорением, да, вы можете скопировать KEY и CRT на любой веб-сервер для обслуживания действительного SSL-соединения. Обратите внимание, что некоторые SSL-сертификаты поставляются/предоставляются из ЦС с цепочкой сертификатов, которая также должна быть установлена ​​на стороне серверов. Без установленной цепочки сертификатов веб-браузер клиента не может правильно проверить сертификат SSL. Вы должны проверить, предоставлена ​​ли цепочка ЦС с сертификатом SSL, предоставленным подписывающим ЦС.

Требования к разрешению IP-адресов. И сертификат SSL привязан к имени хоста. Когда клиентский веб-браузер отправляет запрос серверу, он подключается к IP-адресу, полученному из доменного имени, а затем начинает процесс рукопожатия SSL/TLS. Веб-сервер, отвечающий на этот IP-адрес, должен представить сертификат SSL с общим именем, которое клиентский веб-браузер запрашивает через IP-адрес. Это означает, что можно настроить только один SSL-сертификат на один IP-адрес. Клиент отправляет только зашифрованные запросы HTTP 1.1, поэтому сервер понятия не имеет, каков фактический доменный запрос клиента, до тех пор, пока не будет выполнено рукопожатие SSL/TLS.

Непроизводственное разрешение IP-адресов. Для установки в другом месте веб-браузер должен правильно преобразовать имя хоста в IP-адрес. Поэтому, если вы находитесь в непроизводственной среде, клиент должен разрешать IP-адрес иначе, чем в производственной среде. Это может быть выполнено с альтернативными DNS-серверами или локальным файлом hosts всех машин, которым требуется альтернативное разрешение DNS.

Технический процесс установки. Чтобы установить сертификат SSL на другой компьютер, скопируйте KEY, SSL CRT и цепочку ЦС в соответствующие файлы, настроенные для веб-сервера. Если Apache, все это может быть в одном файле PEM для сертификата SSL.

Затем убедитесь, что веб-сервер обслуживает этот файл PEM по IP-адресу, который разрешается для общего имени в сертификате SSL.

Подстановочные SSL-сертификаты. Некоторые ЦС также предоставляют SSL-сертификаты Willdcard, например *.domain.com . Обратите внимание, что веб-браузер должен распознавать этот тип сертификата, и он защищает только один уровень поддомена. Таким образом, www.domain.com может быть защищен, но www.sub1.domain.com приведет к тому, что веб-браузер клиента выдаст пользователю клиента ошибку проверки.

Некоторые причины, по которым клиентские веб-браузеры получают ошибки проверки SSL-сертификата:

1. если CA Chain необходима, но не предоставляется веб-сервером.
2. если корневой ЦС подписи не является доверенным ЦС в полномочиях SSL веб-браузера клиента — это всегда верно для самозаверяющих сертификатов SSL.
3. если веб-браузер клиента запрашивает домен через SSL, который не соответствует общему имени сертификата SSL.
4. если браузер клиента не может получить доступ к точкам распространения CRL x509 из подписывающего ЦС, поэтому клиент в ограниченной или закрытой сети не сможет проверить SSL-сертификат. URL-адрес CRL предоставляется во время рукопожатия SSL/TLS. См. также: http://en.wikipedia.org/wiki/Revocation_list#Problems_with_CRLs.

Сертификат содержит следующую информацию: 1) Такие сведения, как имя, домен, адрес, дата истечения срока действия ключа и т. д. о компании/частном лице, владеющем сертификатом. 2) У него есть открытый ключ. 3) Некоторые зашифрованные данные. В этом суть.

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

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

Итак, суть в том, что если кто-то публикует (как это делают веб-сайты), что я являюсь владельцем сертификата, это означает, что человек/компания владеет соответствующей парой закрытых ключей.

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

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

Я знаю, что этот ответ бесполезен, но я подумал, что лучше написать то, что я чувствую.

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

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

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

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

Я понимаю, что мой ответ на этот вопрос слишком запоздал в ветке ... но сегодня я столкнулся с той же проблемой при установке одного и того же сертификата на 2 сервера в конфигурации балансировщика нагрузки, ОС = Windows 2008/IIS 7.5 и смог выяснить решение.

Я смог установить его на первый сервер, нажав «Завершить запрос сертификата» и перейдя к месту, где находится сертификат «abc.cer» (предположим, что у вас уже есть сертификат). Затем я скопировал тот же «abc.cer» на второй сервер и попробовал «Завершить запрос сертификата», но это не сработало. Сертификат будет отображаться как установленный, но исчезнет, ​​как только я обновлю диспетчер IIS. Затем я попробовал вариант «экспорта» сертификата с первого сервера (он генерирует файл с расширением .pfx), а затем импортировал его на второй сервер. Этот метод сработал.

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

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

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

i.e. mail-server.stackoverflow.com