Я написал приложение ASP.NET MVC, которое позволяет пользователю указать свой собственный домен. У меня настроен IIS для отправки всех запросов на веб-сайт по умолчанию, поэтому мне не нужно использовать заголовки хоста. Все работает отлично. Единственная проблема — SSL.
Я знаю, что этот вопрос задавался много раз на многих форумах, но ответы, как правило, противоречивы или говорят в абсолютных выражениях, например (это невозможно сделать). Это не совсем вариант для меня. Я ищу здесь некоторые варианты; я открыт для нетрадиционного :).
Я видел несколько конструктивных ответов, которые предлагают использовать ISA-сервер в качестве SSL-прокси. Кто-нибудь знает об этом больше? Или кто-нибудь настраивал это и добился успеха?
По сути, я хочу предоставить своим пользователям возможность запросить CSR из приложения, купить и загрузить SSL-сертификат, вернуться в свое приложение и загрузить сертификат, выданный авторизованной сертифицирующей компанией.
Я хотел бы сделать это без необходимости предоставлять отдельные IP-адреса клиентам, которые хотят использовать пользовательский домен и ssl на своем сайте. Это просто потому, что мое приложение размещено в облаке Amazon, и они не хотят давать мне большой блок IP-адресов.
Мое приложение может быть размещено на IIS6 или IIS7.
РЕШЕНИЕ: Спасибо за всю вашу помощь, ребята. Я, конечно, не понимал эту проблему так хорошо, как сейчас. Я думаю, что моим решением на данный момент будет сгенерировать wildcard-сертификат и заставить моих клиентов использовать clientname.someshareddomain.com, если им нужно защищенное соединение. Для клиентов, которых это просто не устраивает, я, вероятно, предоставлю другой эластичный IP-адрес через вызов API к веб-сервисам Amazon, создам новый веб-сайт в IIS и укажу его на корневую папку моего приложения, а затем программно сгенерирую CSR с этого нового сайта. Мне просто нужно будет заключить какую-то сделку с Amazon, чтобы он дал мне приличный блок IP-адресов.
решение1
Мне очень жаль, что вам не нравится ответ "вы не можете этого сделать", но вы не можете сделать то, что хотите. Технология просто не позволяет этому работать так, как вы хотите.
Вот почему.
Протокол HTTP позволяет нескольким серверам совместно использовать IP-адрес. Это делается через заголовок HTTP/1.1 Host:
Host: servername.example.com
Происходит SSL-рукопожатиедопроисходит HTTP-рукопожатие. Это означает, что сервер не имеет представления, какой сертификат предоставить клиенту, исходя из того, какой сервер хочет клиент.
Так что, старайтесь как хотите, но несколько сертификатов не могут быть использованы на одном IP-адресе. Как бы вы ни старались, как бы сильно вы ни старались, это не вариант для вас.
решение2
Как сказал Майкл, если что-то невозможно, топанье ногой и надутые губы ничего не изменят.
С технической точки зрения размещение отдельных SSL-сертификатов на отдельных IP-адресах не является проблемой; это всего лишь вопрос подготовки (что является простым вопросом программирования) и наличия сетевого провайдера, который понимает потребности крупных компаний и готов заранее выделить приличный блок адресов для доменов SSL.
Однако есть и другой вариант, известный как «Индикация имени сервера", посредством чего браузер может сообщить серверу, с каким виртуальным хостом он хочет общаться во время согласования SSL, чтобы сервер мог предоставить правильный сертификат. К сожалению, поддержка этого не является универсальной; согласно приведенной выше странице Википедии, ни IIS 6, ни 7 не могут обрабатывать это на стороне сервера, и вам нужно запустить Vista, чтобы использовать это с IE на стороне клиента (Firefox, Opera и Chrome уже некоторое время поддерживают это).
Итак, если вы готовы перейти на приличный веб-сервер и оттолкнуть любую часть вашей пользовательской базы, которая все еще использует устаревшие браузеры на старых ОС Microsoft, то вы можете это сделать. Хотя, похоже, никто не хочет раздражать тетю Тилли, использующую IE 5.5 на Windows 98...
решение3
Если проблема заключается в обеспечении защищенных сеансов (а не в том, чтобы каждый клиент имел свой собственный сертификат), почему бы не устранить нагрузку и сложность, используя универсальный SSL-сертификат?