Несколько доменов SSL для одного сайта службы Azure Cloud

У нас есть веб-приложение, работающее на Windows Azure Cloud Service на нашемapp.cloudapp.net. Мы создали запись CName из my.ourapp.com, чтобы указать на этот облачный сервис. Этот домен защищен SSL.

Теперь у нас есть требование разрешить доступ другому домену (my.secondapp.com) именно к тому, что видно на my.ourapp.com.

Мы могли бы создать новое облачное развертывание, но мы не хотим, чтобы дополнительные затраты на размещение и поддержку отдельного развертывания. Мы также подумали о добавлении еще одного https EndPoint в порт, отличный от 443, но из того, что я прочитал, это означало, что нашим пользователям пришлось бы перемещаться по нашему сайту с помощью суффикса ": 444".

После некоторого рытья в Интернете мы столкнулись с этой статьей: http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/. В нем говорится, что с использованием IIS8 и SNI мы можем иметь несколько сертификатов для одной облачной службы.

Однако мы не можем заставить это работать - переход на my.secondapp.com дает предупреждение о сертификате, указывающее, что предоставленный сертификат действительно для my.ourapp.com.

Вот еще несколько указателей:

Сертификат для my.ourapp.com и my.secondapp.com отображается правильно (один через обычный метод Azure и один через код SNI в статье выше). Когда я удаляюсь в наши веб-роли и перехожу на МКС - они оба присутствуют в разделе "Сертифицированные серверы".

Не уверен, что это имеет значение, но я прочитал его в какой-то статье ранее: в разделе "Веб-хостинг" в MMC нет сертификатов. Я вручную добавил Snap-In для сертификатов и импортировал сертификат my.secondapp.com, но безрезультатно.

В IIS у нас есть обычный сайт веб-роли Azure под нашим сервером - что-то вроде "RD0001683008". Когда я смотрю на опции привязки сайта, я вижу:

Тип | Имя хоста | Порт | IP

http | (пробел) | 80 | 10.26.130.10

https | (пробел) | 443 | 10.26.130.10

https | my.secondapp.com | 443 | 10.26.130.10

Я попытался ввести my.ourapp.com в часть имени хоста в первых двух строках, надеясь, что он только подберет это имя хоста, а не my.secondapp.com, но не повезло. Я попытался изменить комбинацию IP-адресов на "All Unassigned", но опять же, не повезло. Нужно ли мне перезапустить сайт или пул приложений?

Я удалил привязку для my.secondapp.com и добавил новый сайт в IIS с теми же данными, что и my.ourapp.com (то же приложение Бассейн и веб-пространство). Это дало мне 503 Service Unavailable, что было чем-то другим, но я не уверен, буду ли я продолжать изучение этой опции.

Еще одна вещь, которую стоит отметить сам сертификат SSL. Он был создан третьей стороной и несколько отличается от сертификата my.ourapp.com. Обычно мы получаем один .crt файл и экспортируем его в .pfx. Когда я пытаюсь экспортировать новый сертификат, параметры .pfx выделены серым цветом, и я могу выбрать только .cer. Я сделал некоторую магию и смог импортировать и как-то экспортировать ее в pfx, предоставляя пароль на этом пути. Может быть, третья сторона должна создать сертификат с паролем ранее в этом процессе? Кроме того, третья сторона предоставила три сертификата (AddTrustExternalCARoot.crt, my_secondapp_com.crt, PositiveSSLCA2.crt). Я использовал только my_secondapp_com.crt - следует ли использовать другие или связывать их?

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

Наконец, при просмотре сертификата в разделе "Сертификаты" на лазурном портале. Субъект для нового сертификата имеет "CN = my.secondapp.com, OU = PositiveSSL, OU = Hosted by Hosting Ireland, OU = Domain Control Validated", в то время как наш обычный сертификат имеет еще много вариантов: "CN = my.ourapp.com, OU = Проверено управление доменами - RapidSSL (R), OU = См. Www.rapidssl.com/resources/cps (c) 11, OU = GT1234567, O = my.ourapp.com, C = IE, SERIALNUMBER = sOmESerIalNumBEr". Может ли это иметь к этому какое-то отношение?

Извините за длинный вопрос - я думал, что предоставление максимально подробных сведений может помочь.

Я бы очень признателен за любую помощь.

Ответы

Ответ 1

На всякий случай кому-то нужна помощь в этом, возникли две проблемы:

Сертификат SSL, который я использовал, не был правильно скован. Если вы получаете 3 сертификата от своего провайдера, вам необходимо установить их правильно, используя IIS и MMC. См. здесь для получения дополнительной информации.
Статья SNI работала. Проблема для нас была обязательной. Мы пришли к следующему порядку:

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

Вы заметите, что мы добавили в my.ourapp.com два раза - один с включенным SNI и IP-адресом, а другой без него. SNI не работает с IE в Windows XP - мы добавили последний вариант как привязку по умолчанию, а не SNI, поэтому наш основной домен всегда работал, даже в IE и XP.

Надеюсь, что это поможет кому-то.