Из любопытства: в чем причина?
Для ясности: я проверил несколько веб-сайтов корневого центра сертификации в поисках подходящего сертификата SSL (это уже другая история). Каждый из них иллюстрирует полезность многодоменных сертификатов для нужд MS Exchange Server.
Обычно потому, что различные приложения и соглашения об именах используют разные внешние имена. Outlook RPC через HTTPS ищет autodiscover.domain.com, веб-почта обычно указывает на webmail.domain.com, имя SMTP может быть представлено как mail.domain.com
Подстановочные сертификаты полезны, если у вас есть много поддоменов, которые вы хотите обслуживать.
Или вы можете получить сертификат SAN / UCC SSL от третьего лица для:
- mail.yourdomain.com
- autodiscover.yourdomain.com
- exchange.yourdomain.local
- remote.yourdomain.local <- Доступ к VPN / RDP.
С новым объявлением о том, что будущий IIS8 будет поддерживать SNI (http://blogs.iis.net/wonyoo/archive/2012/03/01/iis-8-0-platform-features-for-web-hosters-and-service-providers.aspx), это, вероятно, изменит способ применения сертификатов для обмена и все остальное. В будущем мы могли бы переключиться с использования подстановочного знака или UCC на использование одного сертификата SSL для каждого имеющегося у нас SSL-приложения и одного сертификата UCC для Exchange.
Подробнее о SNI в IIS8:
IIS 8.0 поддерживает указание имени сервера (SNI), которое имеет расширенный TLS для включения имени виртуального домена, которое будет передаваться от клиента во время «SSL Hello». Это эффективно позволяет IIS 8.0 включать «привязку имени хоста» для сайтов SSL, что устраняет необходимость в выделенном IPv4-адресе для каждого сайта SSL.