Как тиражировать SSL-сертификаты для настраиваемого домена в разных регионах

Question

TL; DR;

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

Объяснение :

У нас есть Azure веб-приложение, в которое мы добавляем пользовательские домены для пользователя . Мы хотим масштабировать приложение в разных географических c регионах за менеджером traffi c, чтобы при доступе к веб-сайту из Австралии оно отображалось в веб-приложении Auatralia, а при поступлении запроса из Европы - через Интернет. Приложение в Европе будет обслуживать запрос. Таким образом, в текущей ситуации, независимо от того, откуда поступает запрос, он всегда будет обслуживаться из одного места, например: Европа.

Сложность заключается в том, что мы можем добавить пользовательский домен только в одно веб-приложение, поскольку вам нужна запись CNAME, указывающая на отдельный URL-адрес. Он не может указывать на два разных URL-адреса одновременно. Можно направить запросы отдельным приложениям, но другое веб-приложение не сможет обслуживать сертификат SSL, если он сопоставлен с приложением App1 в регионе 1.

Как распространять или поддерживать пул сертификатов какие могут быть доступны через веб-приложения в разных регионах? Есть ли способ с Microsoft Azure?

Обновление : у нас будет N количество пользовательских доменов и, следовательно, N количество сертификатов SSL для обработки. AFAIK, Azure Front Door и Azure Traffi c Manager - мы можем сопоставить настраиваемый домен с их собственными конечными точками и ограничен одним настраиваемым доменом. Здесь я говорю об обработке тысяч внешних пользовательских доменов / сертификатов SSL.

Заранее спасибо! ?

Answer 1

Что я понял из вопроса, так это то, что в основном вы хотели бы адресовать запрос из того же региона, а не из одного места. В этом случае я бы посоветовал взглянуть на azure шлюз приложения. Здесь вы можете определить правила балансировки нагрузки на основе пути. На этом пути, в основном, вы можете иметь один атрибут, который идентифицирует местоположение, скажем / api / emea / images, / api / apac / images. Конечно, вам нужно сначала определить API в этих строках, чтобы разместить какой-то идентификатор. После этого вы можете создать это правило балансировки нагрузки в шлюзе приложения. Тогда у вас могут быть разные бэкэнд-пулы, скажем, один в регионе EMEA с четырьмя-пятью виртуальными машинами, которые могут обрабатывать трафик c из региона EMEA. Точно так же это касается и другого региона. Попробуйте реализовать то же самое в этих строках. Вы также можете исследовать опцию входной двери, а также глобальную балансировку нагрузки, и ваши вещи, связанные с сертификатами, также должны быть учтены. Это должно решить вашу проблему.

Answer 2

Вместо использования Traffi c Manager, я бы использовал Azure Front Door. Это встроенный SSL-сертификат управления . Вам даже не нужно приобретать сертификат самостоятельно.