Наша организация планирует добавить HTTPS на наши сайты. Поскольку у нашего сервера только один IP (что означает, что мы можем использовать только один сертификат), нам нужен сертификат, который действителен для всех сайтов в нашей организации с различными доменными именами. Следовательно, сертификат не должен содержать доменного имени.
Возможны ли они технически, подписывают ли центры сертификации и как с ними справляются браузеры?
Вы не можете получить сертификат X.509, в котором не указано хотя бы одно имя принципа субъекта (домен). Никакой полезный центр сертификации не позволит вам получить сертификат без сертификата, который можно привязать к домену, которым вы можете продемонстрировать, что являетесь его владельцем. Их можно использовать подстановочные знаки на том уровне, на котором вы "владеете", поэтому site1.domain.com, site2.domain.com и т. Д. Подойдут, но site1.domain2.com не будет.
Альтернативой является использование альтернативных имен субъектов или сертификатов [с поддержкой SAN], они могут содержать ряд дополнительных имен (различных типов), если ваш поставщик сертификатов готов их добавить. Для вашего случая использования это могут быть полные доменные имена для определенных сайтов в домене (site1.domain.com, site2.domain.com и т. Д.), Полные доменные имена для других доменов (site1.domain2.com, site1.domain.net). Их можно использовать для добавления дополнительных типов идентификаторов в зависимости от того, что вы хотите сделать, включая IP-адреса, однако я не знаю, насколько широко поддерживаются эти дополнительные возможности. Количество идентификаторов SAN, которые вы можете включить, также зависит от поставщика сертификата. Verisign допускает 19, пока Digicert поддерживает до 150 например.
Расширение альтернативного имени субъекта позволяет включать в файл конфигурации различные буквальные значения. К ним относятся электронная почта (адрес электронной почты), URI, универсальный индикатор ресурса, DNS (доменное имя DNS), RID (зарегистрированный идентификатор: OBJECT IDENTIFIER), IP (IP-адрес), dirName (отличительное имя) и otherName.
Опция электронной почты включает специальное значение «копия». Это будет автоматически включать и адреса электронной почты, содержащиеся в имени темы сертификата в расширении.
IP-адрес, используемый в параметрах IP, может быть в формате IPv4 или IPv6. ... subjectAltName = email: copy, email: my @ other.address, URI:http://my.url.here/ subjectAltName = IP: 192.168.7.1 subjectAltName = IP: 13 :: 17 subjectAltName = email: my @ other.address, RID: 1.2.3.4 subjectAltName = otherName: 1.2.3.4; UTF8: какой-то другой идентификатор
Нет. SSL-сертификаты привязаны к своим общим именам (CN), а CN привязаны к доменному имени, а не к IP-адресу.
К сожалению, нет другого выбора, кроме как попросить кучу IP-адресов. Большинство интернет-провайдеров предоставят вам дополнительный блок из 4 (2 используемых) без дополнительных затрат на бизнес-план.
Да, они называются SSL-сертификатами с подстановочными знаками, но они учитываются только для одного домена (* .domain.com.)
Новые сертификаты также могут содержать SAN (альтернативные имена субъектов) в сертификате, который, как я считаю, позволяет вам пересекать границу доменного имени (то есть один сертификат для www.domain.com и www.domain2.com.)
Вопреки распространенному мнению, это является теперь возможно иметь несколько сайтов SSL с разными именами на одном IP-адресе, но для этого требуется, чтобы и серверные, и клиентские приложения поддерживали SNI (см. http://en.wikipedia.org/wiki/Server_Name_Indication для информации).
Отсутствие поддержки в некоторых клиентах (особенно IE6 и IE7 / 8, если они работают в Windows XP) является основной причиной не использовать SNI, но если это не повлияет существенно на вашу базу пользователей, возможно, стоит подумать. Firefox поддерживает SNI с версии 2, а IE7 и IE8 поддерживают его в Vista / 2003/2008/7 (дополнительные сведения о поддержке клиентов см. В статье в Википедии, приведенной выше).
Еще одна проблема, если ваши серверы основаны на Windows и обслуживают HTTP (S) через IIS, - это отсутствие поддержки в IIS, но вы можете обойти это, установив lighttp или nginx в качестве обратного прокси для реального демона http (s) (IIS). .
Вам по-прежнему понадобится отдельный сертификат для каждого FQDN или, по крайней мере, сертификат с подстановкой для каждой группы имен, конечно, - но он действительно уменьшает количество IP-адресов, которые вам нужно выделить, что будет GoodThing (tm), если это дефицитный (или иным образом дорогой) ресурс, на котором расположен ваш сервер.