У меня есть веб-сайт, размещенный на *.mydomain.com, мой веб-сервер Apache в сочетании с PHP будет возвращать / отображать некоторый простой текст на основе предоставленного поддомена. *.mydomain.com защищен SSL-сертификатом с подстановочным знаком.
Мне нужно разрешить пользователям перенаправлять запросы из своего домена в мой домен, например: demo.theirdomain.com к demo.mydomain.com
Я сделал это с помощью HTTP, используя записи CNAME, однако я читал, что это не идеально. И мне нужно, чтобы мой веб-сайт обслуживался по HTTPS. Когда я пытаюсь подключиться к сайту на https://demo.theirdomain.com через HTTPS я получаю сообщение об ошибке несоответствия сертификата.
Как лучше всего разрешить другим поддоменам безопасно перенаправлять свои запросы в мой домен? ПРИМЕЧАНИЕ. Я НЕ хочу, чтобы пользователи создавали свои собственные сертификаты.
К сожалению, CNAME в этом случае работать не будет. Как вы сказали, ваш сертификат действителен только для *.mydomain.com и не будет работать для других доменов. Использование CNAME из demo.theirdomain.com к mydomain.com приведет к ошибке несоответствия сертификата, потому что клиент был убежден, что он подключается к demo.theirdomain.com но сервер (mydomain.com) предоставляет сертификат на *.mydomain.com
Вам нужно будет переосмыслить способ, которым вы пытаетесь это сделать. Я бы посоветовал изложить более подробную информацию о том, почему вы это делаете, чтобы мы могли избежать проблемы X-Y, но я предложу два возможных решения:
demo.theirdomain.com и передать HTTP-ответ 302, чтобы перенаправить клиента на mydomain.com. Это позволит клиенту понять, что текущий сервер является mydomain.com сервер и что *.mydomain.com сертификат действителен для него. Если это не идеально, потому что вы хотите demo.theirdomain.com чтобы быть единственным видимым доменом, попробуйте №2. Однако это перенаправление, вероятно, является лучшим решением для вас.demo.theirdomain.com и обеспечить сквозной / бэкэнд на mydomain.com. Преимущество этого заключается в том, что обратный прокси-сервер будет обрабатывать переходы сертификатов, поскольку соединение завершается в demo.mydomain.com и поэтому сертификат там (надеюсь, настроен правильно) действителен. Новое соединение инициируется на обратном прокси-сервере для mydomain.com и считается действительным. Вы сказали, что не хотите, чтобы пользователи создавали свои собственные сертификаты, поэтому это решение, вероятно, не идеально для вас, тем более, что оно также включает настройку обратного прокси (хотя они могут настроить запись DNS для demo.theirdomain.com чтобы указать IP-адрес на обратном прокси-сервере).Вы могли бы иметь сертификаты на своей стороне для их доменов, но похоже, что это было бы невозможно для вас. Я бы посоветовал не использовать сертификаты с подстановочными знаками везде, где это возможно, поскольку они не являются хорошей практикой безопасности.
Если ваш пользователь хочет перенаправить свой домен https://demo.example.net в ваш домен https://demo.example.com возможны только две конфигурации:
demo.example.com,VirtualHost названный demo.example.net с действующим сертификатом. В этом случае вы можете избавиться от перенаправления и напрямую обслуживать контент.В любом случае они должны получить действующий сертификат для demo.example.com, но все станет проще, если вы воспользуетесь Давайте зашифровать сертификаты. В таком случае:
demo.example.net домен согласно Условия использования Let's Encrypt, в частности, вы должны удовлетворять условию: Вы гарантируете ISRG и широкой общественности, что являетесь законным регистрантом доменного имени в Интернете, которое является или будет объектом вашего сертификата, или что вы являетесь должным образом уполномоченный агент такого регистранта.
demo.example.net указать на ваш адрес (что уже сделано) и использовать клиент ACME, например Certbot для получения и продления сертификатов.