Скажем, у меня есть две службы приложений (включен только HTTPS):
https://myapp1.azurewebsites.net
https://myapp2.azurewebsites.net
Я могу успешно вызывать обе конечные точки службы приложений с помощью HTTPS.
Затем я создал диспетчер трафика и добавил две вышеперечисленные конечные точки в диспетчер трафика, скажем:
myapps.trafficmanager.net
После создания диспетчера трафика и добавления конечной точки имя узла диспетчера трафика myapps.trafficmanager.net также автоматически добавляется в пользовательские домены двух служб приложений. Но без привязки SSL к имени хоста диспетчера трафика.
Затем, если я вызову конечную точку диспетчера трафика, используя https: https://myapps.trafficmanager.net, я получу ошибку/предупреждение о ненадежном SSL-сертификате. Это ожидаемо.
Поскольку диспетчер трафика работает только на уровне DNS, реальный запрос фактически отправляется в конечную точку службы приложений, которая имеет правильную привязку сертификата SSL. Мой вопрос:
С точки зрения безопасности безопасно ли вызывать endpopint диспетчера трафика без сертификата с помощью HTTPS в моем коде (скажем, с помощью .NET HttpClient), но просто игнорировать ошибку сертификата?
Недавно я тоже установил один из них и немного поборолся с ним. Короткий ответ: это, вероятно, безопасно, но похоже, что вы неправильно используете диспетчер трафика. Вы не должны использовать URL-адрес в диспетчере трафика в качестве конечной точки, если хотите использовать SSL. Вместо этого настройте имя собственного домена mycoolsite.com
, чтобы оно указывало на myapps.trafficmanager.net
, используя запись DNS CNAME.
Если вы хотите использовать SSL и один URL-адрес, вам следует настроить собственный URL-адрес и установить сертификат SSL на уровне службы. Это должен быть один и тот же настраиваемый URL-адрес в обеих службах приложений. Это должно быть настроено в службе приложений, нет в диспетчере трафика.
Мне пришлось прочитать это несколько раз, чтобы понять, как это работает внутри, но это было полезно.
Таким образом, чтобы настроить его правильно, шаги будут такими:
Нет необходимости привязывать сертификат к диспетчеру трафика, начиная с сертификат сервера не проверен при использовании тестов работоспособности диспетчера трафика через HTTPS. Причем диспетчер трафика работает на уровне DNS. Клиенты подключаются к выбранной конечной точке напрямую, а не через диспетчер трафика.
В этом случае вы можете использовать HTTPS для конечных точек и использовать проверку работоспособности через HTTPS. Даже если вы не можете связать сертификат с диспетчером трафика, вы можете убедиться, что порт мониторинга настроен правильно в диспетчере трафика (например, 443 вместо 80), а также ваш путь мониторинга указывает на действительную страницу для вашей службы.
Другой ТАК ответ объясняет это более подробно. Если вы все еще хотите, чтобы это предупреждение исчезло, вы можете получить бесплатный SSL от letsencrypt.org и добавить его в свой личный домен с помощью *.trafficmanager.net
.
Я думаю, что это безопасно, поскольку клиент напрямую подключается к выбранной конечной точке, а не через диспетчер трафика. Кроме того, транзакция данных HTTPS происходит выше уровня DNS.
да, я настроил протокол зонда на HTTPS и порт на 443. И я могу успешно получить результат от myapps.trafficmanager.net, за исключением предупреждения о ненадежном сертификате. Я просто хочу убедиться, что безопасно использовать конечный пункт HTTPS trafficmanager и игнорировать предупреждение о сертификате с точки зрения безопасности.