Огромное преимущество использования Azure Websites заключается в том, что я могу получить защищенный HTTP (HTTPS), ничего не делая: просто наберите https://xyz.azurewebsites.net, и он работает. Мне не нужно беспокоиться о сертификатах, потому что я использую субдомен, который дает Azure (в примере это будет xyz)
Итак, что я обычно делаю, так это то, что люди проходят через какой-то зарегистрированный домен, который у меня есть, например. http://www.my-application-homepage.com, и там, если они хотят использовать мое приложение, я перенаправляю их в поддомен в azurewebsites.net, с помощью HTTPS.
Теперь, сказав это:
Я нуждаюсь в обновлении до Azure Cloud Services или Azure Virtual Machines, потому что у них есть возможности, которые Azure Websites не поддерживают. Эти два также предлагают свободный субдомен: xyz.cloudapp.net, но мой вопрос: я тоже получу HTTPS? и как?
Я искал в Google для некоторых примеров cloudapp, и то, что я тестировал, было следующим:
1) Подключитесь через HTTP (т.е. введите http://xyz.cloudapp.net). Результат: сработал
2) Подключить через HTTPS (т.е. тип https://xyz.cloudapp.net). Результат: не работал (хром дал ERR_CONNECTION_TIMED_OUT)
Нет. На данный момент HTTPS не предлагается для домена .cloudapp.net. Кроме того, поскольку у вас нет домена .cloudapp.net, я не думаю, что вы можете купить сертификат SSL для этого. Если вы хотите, вы можете создать самозаверяющий сертификат и использовать его.
Я бы просмотрел приведенную здесь документацию: http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Поскольку вы получаете тайм-аут с HTTPS (а не с ошибкой сертификата), убедитесь, что у вас есть конечная точка HTTPS, определенная в ServiceDefinition.csdef.
Кроме того, имейте в виду, что подход переадресации к субдомену не намного безопаснее, чем использование самозаверяющего сертификата. Причина, по которой браузеры отказываются от самоподписанных сертификатов, заключается в том, что они уязвимы для подмены атак: пользователь не может определить, мог ли атакующий, например, угнать DNS, чтобы указать на его IP-адрес вместо вашего, где он размещает фасад ваш сайт, который просто собирает пароли или что-то еще.
В вашем сценарии клонированный сайт может перенаправить на другой второй клон, который является фасадом вашего сайта cloudapp.net. Его можно даже защитить с помощью SSL-сертификата злоумышленника. Если пользователь не был обучен распознавать имя хоста реального cloudapp.net, она не знала, что она находится на защищенном сайте злоумышленника.
** Обновление: этот метод также недействителен, мы получили сертификат, отозванный через неделю, используя его **
Мы используем этот подход для серверов/серверов:
Если вы не хотите использовать самозаверяющий сертификат, один из вариантов заключается в покупке дешевого сертификата SSL, например:
https://www.ssls.com/comodo-ssl-certificates/positivessl.html
Затем, как только вам нужно его одобрить, вы должны обратиться за поддержкой, чтобы изменить процесс проверки утверждений: вместо отправки электронной почты на адрес [email protected] вы можете попросить изменить процесс проверки на размещение данного файла с помощью заданный файл в корне вашего сайта (вы должны спросить в комнате поддержки/чата об этом).
Дополнительная информация: