Как перенаправить субдомен к альтернативному серверу с поддержкой SSL?
Исправление вашего приложения для использования window.history.pushstate .
У ваших клиентов есть веб-сервер в app.clientdomain.tld, который обслуживает iframe вашего сайта.
Надеюсь, что пользователи вашего клиента используют совместимые браузеры (и у них включен javascript).
Тем не менее, первая идея Кристофера Эванса (перенаправление на уровне DNS) лучше всего, если вы можете. (Используйте CNAME, чтобы ваши клиенты могли запустить и забыть.) Однако, поскольку ни один объект не должен иметь возможность получать действительный сертификат для другого, многодоменные сертификаты не помогут, если только один клиент не имеет более одного домена. Ваши клиенты должны будут сгенерировать действительные сертификаты и передать вам сертификаты и связанные ключи. (Ключи должны передаваться безопасным образом.)
Или вы можете подождать http://www.ietf.org/rfc/rfc2817.txt (Не делайте этого! Это правда, но бесполезно ).
Изменить:
Вариант, который не Стоимость IP-адресов (по крайней мере, пока у вас не закончатся легкодоступные порты) состоит в том, чтобы ваш веб-сервер обслуживал каждый сертификат клиента на альтернативном порту, а не на альтернативном IP-адресе. например, клиентская ссылка https: //app.client.tld: 7703 /
Вам все равно придется заняться DNS.
Если вы не хотите изменять адресную строку, вам нужно либо использовать фрейм HTML, либо вам нужно настроить свой сервер в качестве прокси. Таким образом, запросы, которые достигают https://sub.domain.com , проксируются на https://sub.otherdomain.com
. Вы не можете выполнить перенаправление HTTP без изменения адресной строки.
Есть небольшая вероятность, что вы сможете заставить что-то работать, но вам придется начать с сертификата с подстановочными знаками, который поддерживает оба доменных имени.
Один из способов сделать это - использовать прокси-сервер Apache на передней панели, который обслуживает групповой сертификат с несколькими соединителями и использует мод-прокси. В этой конфигурации клиент может переключаться между доменами и не сталкиваться с ошибкой «проверить этот сертификат».
Затем передний прокси-сервер будет интеллектуально пересылать запросы на внутренний HTTP-сервер (например, экземпляр Tomcat), используя mod-proxy, mod-ajp и / или mod-rewrite, где внутренний сервер работает на разных портах для каждого сайта сервера. Ваши правила перезаписи мода могут обрабатывать все детали выбора способа маршрутизации.
1) У вас может быть точка DNS sub.domain.com на IP-адрес / сервер, которым вы управляете. Тогда у вас будет установлен сертификат ssl для sub.domain.com. 2) Если вы ограничены IP-адресами, вы можете получить Многодоменные сертификаты . Go Daddy ограничивает вас 99 доменами, и это может быть сложной перетасовкой для каждого добавляемого домена. 3) Вы также можете сделать так, чтобы клиент получил сертификат ssl и должен действовать как прокси, подключающийся к вашему сайту.