Несоответствие сертификата SSL, веб-сайт от нескольких поставщиков

К сожалению, CNAME в этом случае работать не будет. Как вы сказали, ваш сертификат действителен только для *.mydomain.comи не будет работать для других доменов. Использование CNAME из demo.theirdomain.com к mydomain.com приведет к ошибке несоответствия сертификата, потому что клиент был убежден, что он подключается к demo.theirdomain.com но сервер (mydomain.com) предоставляет сертификат на *.mydomain.com

Вам нужно будет переосмыслить способ, которым вы пытаетесь это сделать. Я бы посоветовал изложить более подробную информацию о том, почему вы это делаете, чтобы мы могли избежать проблемы XY, но я дам вам два возможных решения:

1. Другой домен должен использовать переадресацию, например HTTP 302. Веб-сервер будет располагаться по адресу demo.theirdomain.com и передать HTTP-ответ 302, чтобы перенаправить клиента на mydomain.com. Это позволит клиенту понять, что текущий сервер является mydomain.com сервер и что *.mydomain.comсертификат действителен для него. Если это не идеально, потому что вы хотите demo.theirdomain.comчтобы быть единственным видимым доменом, попробуйте №2. Однако это перенаправление, вероятно, является лучшим решением для вас.
2. Обратный прокси-сервер может находиться на demo.theirdomain.com и обеспечить сквозной / бэкэнд на mydomain.com. Преимущество этого заключается в том, что обратный прокси-сервер будет обрабатывать переходы сертификатов, поскольку соединение завершается в demo.mydomain.comи поэтому сертификат там (надеюсь, настроен правильно) действителен. Новое соединение инициируется на обратном прокси-сервере для mydomain.comи считается действительным. Вы сказали, что не хотите, чтобы пользователи создавали свои собственные сертификаты, поэтому это решение, вероятно, не идеально для вас, тем более что оно также включает настройку обратного прокси (хотя они могут настроить запись DNS для demo.theirdomain.com чтобы указать IP-адрес на обратном прокси-сервере).

Вы могли бы иметь сертификаты на своей стороне для их доменов, но похоже, что это было бы невозможно для вас. Я бы посоветовал не использовать сертификаты с подстановочными знаками везде, где это возможно, поскольку они не являются хорошей практикой безопасности.

Если ваш пользователь хочет перенаправить свой домен https://demo.example.net в ваш домен https://demo.example.com возможны только две конфигурации:

1. Они запускают веб-сервер TLS с действующим сертификатом, который перенаправляет (используя перенаправления HTTP) все на demo.example.com,
2. Вы управляете VirtualHost названный demo.example.netс действующим сертификатом. В этом случае вы можете избавиться от перенаправления и напрямую обслуживать контент.

В любом случае они должны получить действующий сертификат для demo.example.com, но все становится проще, если вы используете сертификаты Let's Encrypt. В этом случае:

1. клиенту просто нужно разрешить вам использовать demo.example.netдомен в соответствии с условиями использования Let's Encrypt, в частности, вы должны выполнить условие:

   Вы гарантируете ISRG и широкой общественности, что являетесь законным регистрантом доменного имени в Интернете, которое является или будет являться субъектом вашего сертификата, или что вы являетесь должным образом уполномоченным агентом такого регистранта.

2. для получения такого сертификата вам достаточно demo.example.netуказать на ваш адрес (что уже сделано) и использовать клиент ACME, например certbot, для получения и обновления сертификатов.