У нас есть облачная многопользовательская система SaaS. AKA: платформа. Платформа предоставляет услуги нашим клиентам, позволяя их конечным пользователям выполнять определенную работу. В качестве примера представьте, что у нас есть служба ведения блогов, которую мы продаем компаниям, а затем они могут публиковать блоги и взаимодействовать с ними со своими пользователями.
На сегодняшний день, чтобы в некотором роде добавив услугу в белый цвет и сделав это безопасно, мы купили для каждого клиента домен и выпустили для него SSL-сертификат (проверка домена на сертификате UCC). Например. если у нас есть клиент с именем «корпоративный», мы обычно покупаем домен с именем «blogcorporate1.com» и управляем им.
Мы хотим полностью обесцветить решение, то есть иметь возможность обслуживать наших клиентов с blog.corporate1.com.
Как это сделать?
Можно ли это сделать таким образом, чтобы мы могли быть полностью независимыми от клиента? Это означает, что если они просто перенаправляют на нашу службу, и мы меняем наш сервер на другой IP-адрес, нам нужно, чтобы они указывали на новый IP-адрес.
Могут ли они делегировать нам управление поддоменом blog.corporate1.com, и мы будем управлять зоной для этого поддомена, а также выпустить для него SSL-сертификат (также настроить пересылку электронной почты и другие функции DNS, которые мы делаем)?
Здесь есть несколько вопросов, что не является хорошей практикой для SF. При этом, насколько я понимаю, у вас есть заказчик, давайте позвоним ему example.com, и вы хотите предоставить им службу блогов на blog.example.com, используя SSL.
На них размещается DNS. Что делать, если IP нашего сервера изменится?
Они обновляют свои DNS, чтобы рекламировать ваш новый IP, и все продолжает работать.
Могут ли они делегировать
blog.example.comподдомен к нашим серверам имен?
Да, при условии, что у них есть некоторые подсказки по DNS и приличная инфраструктура DNS. Тогда вы можете запланировать изменение IP без привязки к клиенту.
Могу ли я получить сертификат SSL для
blog.example.com?
Если бы это вообще было возможно, это полностью разрушило бы саму идею SSL. Некоторые провайдеры будут рассматривать контроль службы HTTP на blog.example.com как доказательство того, что у вас есть право на сертификат SSL с этим CN (как указывает Лалокин в своем ответе, letsencrypt является одним из таких провайдеров), так что как только вы получите http://blog.example.com настроил и заработал, можно было получить сертификат от такого провайдера. Некоторым центрам сертификации нужно больше доказательств того, что вы имеете право использовать полное доменное имя (например, контроль над работающим почтовым сервером на blog.example.com), и если (скажем) клиент хочет получить сертификат EV, все довольно быстро усложняется.
В целом верное решение здесь - создать CSR, передать его клиенту и сообщить их чтобы подписать его любым поставщиком, который им подходит. Как только они дадут вам подписанный сертификат, вы установите его, и будет установлен SSL.
В зависимости от того, какой сертификат SSL вы хотите использовать для этих доменов, вы можете запросить сертификат, подтвержденный доменом, который требует, чтобы вы контролировали только указанный sub.domain.tld.
Хорошим примером в наши дни было бы шифрование. Пока имя хоста указывает на ваш сервер, вы можете запросить сертификат.
certbot-auto certonly --webroot -d blog.domain.tld -w /var/www/blog.domain.tld