У нас есть продукт (размещенное приложение PHP), для которого мы будем предоставлять людям сертификаты SSL вместе с некоторым хостингом.
Мы полностью контролируем среду хостинга, настраивая конфигурацию виртуального хоста пользователей, корень документа и т. Д.
Мы рассматриваем мультидоменные сертификаты, которые позволят нам объединить многие домены в один сертификат, что в конечном итоге сэкономит пользователям немало денег.
Насколько я понимаю, при добавлении / удалении домена из сертификата старый необходимо отозвать и создать новый - это правильно?
Есть ли у них какой-нибудь API для этого?
Здесь, кажется, упоминается, что их сайты хороши для общего хостинга, а также для работы с одиночными IP-адресами. У кого-нибудь был опыт?
http://www.comodo.com/business-security/digital-certificates/multi-domain-ssl.php
Вам нужно отозвать сертификат только в том случае, если вы считаете его скомпрометированным. Если вы просто хотите добавить или удалить имена, новый сертификат может быть выдан без отзыва старого. Новый сертификат можно удалить вместо старого и перезагрузить конфигурацию веб-сервера, не требуя значительных усилий по перенастройке или простоев.
Что делать, если плата за выдачу этого нового сертификата - это бизнес-решение для отдельного ЦС. Некоторые могут рассматривать это как «переиздание» и делать это бесплатно, другие - нет.
Помимо стоимости преимуществом наличия нескольких доменов на одном сертификате является то, что вы можете обслуживать их с одного IP-адреса, не полагаясь на SNI.
С тех пор, как был опубликован этот вопрос, на сцене появилось слово «давайте шифровать». Они кажутся чертовски хорошими для этого приложения. Они позволяют использовать несколько доменов на одном сертификате. Ничего не заряжайте и изначально предназначены для автоматизации.
Я бы не рекомендовал использовать многодоменный сертификат (не говоря уже о том, чтобы покупать их у Comodo на основе недавней истории безопасности их реселлера) из-за отзыва и повторной выдачи, которые вам нужно будет делать всякий раз, когда вы подписываетесь на нового размещенного клиента. Если бы у вас было 50 клиентов и вы подписались на нового, вы не захотите повлиять на этих 50 клиентов просто потому, что вы добавляете нового, а также ваши сотрудники системного администратора не захотят изменять более 50 конфигураций сайта каждый раз, когда вы регистрируетесь (или теряете ) клиент.
Я думаю, вам будет намного лучше, если вы структурируете свои сайты так, чтобы имя клиента находилось в хостовой части вашего домена. Например, customer1.yourdomainname.com, customer2.yourdomainname.com и т. Д.
Возможно, вы захотите рассмотреть решение с управляемым pki от одного из центров сертификации, потому что у вас есть гораздо больший контроль над управлением и обслуживанием сертификатов.
Если вы не хотите вкладывать средства в управляемый маршрут pki, возможно, лучше подойдет подстановочный сертификат. Обслуживание сертификатов по-прежнему удаляется из процесса подготовки клиентов (если, конечно, ваш закрытый ключ для вашего сертификата с подстановочными знаками не будет скомпрометирован).
При этом я не уверен, есть ли у кого-либо из центров сертификации API, кроме OpenSSL, NSS, GNU-TLS и JSSE. являются API-интерфейсы, поэтому значительная часть процесса предоставления сертификатов может быть написана сценариями и / или автоматизирована