[Oleg Krylov]

С локальными именами сертификат вам могут и не дать, особенно если у вас используется резервированная Domain Part типа .local. Да и не нужны вам они, потому что TMG маскирует их. Понятное дело, что внутри сети вам стоит повесить на Exchange сертификаты, выписанные вашим внутренним СА.
Самым простым решением для публикации будет использование wildcard-сертификата, вида *.domain.com.
MX-записи для публикации веб-сервисов не используются совсем, вам это имя (mx.domain.ru) нужно для работы MTLS на SMTP.

[zhuk09]

Oleg Krylov, добрый день!
Начну по порядку.

С локальными именами сертификат вам могут и не дать, особенно если у вас используется резервированная Domain Part типа .local. »

Да, действительно RuCenter отказал в выдаче такого типа сертификата. Хотя я точно знаю, что такие сертификаты выпускали

1.Компания, выпускающая сертификат должна предупредить, что использование внутренних IP/FQDN в поле SAN с октября 2016 года не допускается. Все сертификаты с такими именами будут отозваны 1 октября 2016 года. 2.Компания, выпускающая сертификат не должна выпускать сертификаты с внутренними IP/FQDN в поле SAN, срок жизни которых истекает 1 ноября 2015 года и позднее. Поле Subject Name в обозримой перспективе рискует исчезнуть совсем.

http://www.buldakov.ru/?p=2289

Да и не нужны вам они, потому что TMG маскирует их »

Можно об этом по подробней!!!

Понятное дело, что внутри сети вам стоит повесить на Exchange сертификаты, выписанные вашим внутренним СА. »

Внутри домена нет своего CA, использую самоподписанный сертификат, а точнее 2 сертификата
1. Назначен для службы SMTP
Субъкт DC = ru, DC = dmain, DC = mx CN = mx.domain.ru
SAN DNS-имя=mx.domain.ru
2. Назначен для служб IMAP, POP, IIS, SMTP
Субъкт DC=ru, DC = dmain, DC = mail CN = mail.domain.ru
SAN DNS-имя=exchange DNS-имя=exchange.domain.local DNS-имя=mail.domain.ru
В данном случае, если у меня нет внутреннего СА, какой из сертификатов оставить или лучше создать один и в SAN добавить DNS-имя=mx.domain.ru и autodiscover.domain.local????

Самым простым решением для публикации будет использование wildcard-сертификата, вида *.domain.com. »

они очень дорогие, нашел решение чуть дешевле Geotrust True BusinessID SAN

В стоимость сертификата GeoTrust True BusinessID Multi-Domain включено до 6 дополнительных доменных имен. Дополнительные доменные имена добавляются за отдельную плату. Этот сертификат создавался для Microsoft Exchange или Microsoft Communications Servers,

Тогда не пойму, какие имена должны быть в сертификате от внешнего поставщика
mail.domain.ru, mx.domain.ru, autodiscover.domain.ru - Так???

MX-записи для публикации веб-сервисов не используются совсем, вам это имя (mx.domain.ru) нужно для работы MTLS на SMTP. »

Мне для веб-сервисов это и не нужно, я хотел одним сертификатом закрыть все службы. И еще я писал
Так как ранее писал, что

В DNS есть 2 MX записи mail.domain.ru. A 1.1.1.1 ; HELO/EHLO = mail.domain.ru mx.domain.ru. A 1.1.2.2 ; HELO/EHLO = mx.domain.ru domain.ru. MX 10 mail.domain.ru. domain.ru. MX 20 mx.domain.ru. »

- 2 интернет канала

ЗЫ: Как я понял, с самоподписанным сертификатом опубликовать OWA, ActiveSync, Outlook Anywhere - НЕ ПОЛУЧИТСЯ!!!!

[zhuk09]

И еще один вопрос
Если идти по этому варианту

Варианты публикации Autodiscover`a 1. Используя один сертификат с несколькими именами хостов (с полем SAN): Публикуем службы OWA, ActiveSync и Outlook Anywhere на адресе, к примеру, https://mail.alexxhost.ru/... а службу AutoDiscover – на адресе https://autodiscover.alexxhost.ru/au...todiscover.xml

http://www.alexxhost.ru/2011/05/autodiscover-1.html
Для того что бы работал Autodiscover необходимо создать CNAME ???, допустим так autodiscover.domain.ru CNAME mail.domain.ru.
Но если произойдет переключение на резервного провайдера, и вместо основной MX записи mail.domain.ru будет активна MX запись mx.donain.ru - как в этом случае отработает Autodiscover?????

Или не надо создавать запись такого типа????!

[zhuk09]

UP!!!! Нужна помощь!

[zhuk09]

Oleg Krylov, надеюсь только на Вас!
Почитал я форум technet, а конкретно вот эти темы
1. exchange сертификат SSL в локальной сети зоты local
2. Outlook anywhere, ошибка 8004010F
3. Публичный SSL сертификат
И пришел к выводу, что SSL сертификатом от внешнего поставщика, где нет SAN с зоной .local, будет работать только
1. с некоторой настройкой внутреннего DNS. Как я понял эта настройка называется Split DNS (создание зоны domain.ru на локальном DNS сервере) и конфигурирование Split DNS.
2. Прописываете URL (Outlook 2007 security warning: "The name of the security certificate is invalid or does not match the name of the site")
Но тут же Oleg.Kovalenko пишет

обратите внимание, что публичный сертификат устанавливается на Proxy (TMG|UAG) и HTTPS сесия транслируется на CAS. На CAS используется внутренний сертификат PKI.

не понятно для какой службы он используется в CAS????? Для IIS нельзя, для SMTP? - зачем?! В моем варианте с самоподписанным сертификатом, он должен использоваться на CAS? И если да, то для какой из служб. И Вы о том же говорили

Понятное дело, что внутри сети вам стоит повесить на Exchange сертификаты, выписанные вашим внутренним СА. »

и потом вот это

Если нет TMG/UAG, тогда Split zona. При отказоустойчивых каналах (при отсутствии PKI инфраструктуры), покупаем публичный сертификат. Дешевле стоимость владения

Что это значит??? Как TMG/UAG решит ошибку с внутренним AutoDiscover ??? http://support.microsoft.com/kb/940726

URL-адрес службы автообнаружения хранится в объекте точки подключения служб. По умолчанию он ссылается на внутреннее полное доменное имя сервера клиентского доступа, который использовался во время установки этой службы, например: https://имя_сервера.contoso.local/au...todiscover.xml В этом примере полное доменное имя ссылается на внутреннее пространство имен. Как правило, оно не совпадает с внешним пространством имен, например mail.contoso.com.

Может Вы доходчиво объясните!

[Oleg Krylov]

Хотя я точно знаю, что такие сертификаты выпускали »

То было раньше, сейчас не выпускают. Стас довольно подробно описал ситуацию. Стасу надо верить.

Внутри домена нет своего CA, использую самоподписанный сертификат »

Что не есть хорошо. Outlook умеет обрабатывать исключение SSL Certificate self-signed, но другие клиенты не умеют. Поэтому проще поднять СА и выпустить себе сертификатов по душе. Если вы делаете его Enterprise CA, то корневой сертификат вашего СА автоматически распространится на все машины-члены домена. Поднять СА не так уж сложно (в базовой конфигурации, понятно, но тут не до Best Practice) в интернетах можно найти достаточно инструкций, как это сделать в стиле Next-Next-Finish.

они очень дорогие, нашел решение чуть дешевле Geotrust True BusinessID SAN »

359$ по текущему курсу это 23 тысячи рублей. Хорошее решение wildcard от GoDaddy (21 тысяча или 19 если брать на срок более одного года). В России нет поставщиков SSL-сертификатов, которые прошли процедуру верификации и входят в партнерскую программу Microsoft (да и других). Т.е. их корневые сертификаты не размещаются в продуктах по умолчанию и использование их не отличается от использования собственного СА. А все иностранные поставщики продают за доллары, отсюда и рост цен на них в последнее время. Я еще раз отмечу - wildcard будет лучшим решением для вас.

Тогда не пойму, какие имена должны быть в сертификате от внешнего поставщика mail.domain.ru, mx.domain.ru, autodiscover.domain.ru - Так??? »

Зависит от того, зачем вам сертификат для SMTP. Обычно такое решение используется для MTLS, но для этого надо быть уверенным, что на той стороне тоже стоит сертификат, которому доверяет ваш сервер. А это, поверьте, редкость. Для создания же партнерских коннекторов (когда MTLS - обязательное условие работы) - можно обойтись своим СА, в любом случае вам партнерские коннекторы настраивать при участии администраторов вашего визави, следовательно, передать им ваш корневой сертификат не проблема.
Однако, если вы хотите использовать Outlook Anywhere и OWA да еще и с преаутентификацией FBA на TMG, то вы не сможете опубликовать все это на одном прослушивателе, т.к. Outlook не понимает FBA и не умеет вводить логин\пароль в формочку.
Следовательно вам нужно разделить пространство имен OWA и Outlook Anywhere. Тут еще один вопрос: Exchange ActiveSync умеет аутентифицироваться только в Basic или в Certificate-based authentication. А для Outlook Anywhere неплохо бы сделать NTLM. Следовательно вы получаете третье пространство имен и третий прослушиватель. Все зависит от того, сколько в вашем распоряжении IP-адресов. По-хорошему надо три, но можно все сделать и на одном (OWA без FBA, Outlook Anywhere в Basic, EAS в Basic).
Если адресов три, тогда получаем:
mail.domain.com - Outlook Anywhere, IP-адрес №1
owa.domain.com - Outlook Web App, IP-адрес №2
eas.domain.com - Exchange ActiveSync, IP-адрес №3
autodiscover.domain.com - Autodiscover Service, IP-адрес №1
mx.domain.com - SMTP, IP-адрес любой из трех.
Если адрес один, то получаем вот что:
mail.domain.com - Outlook Anywhere, OWA, EAS
autodiscover.domain.com - Autodiscover Service
mx.domain.com - SMTP.
Есть еще хинт - использовать для Autodiscover Service не А-запись, а SRV. Тогда вы создаете в вашем DNS SRV-запись вида _autodiscover._tcp.domain.com 443 mail.domain.com, тогда клиент поймет, что автообнаружение за адресом mail.domain.com. Но тут есть момент - это работает только в новых клиентах (сейчас можно сказать во всех). Если вдруг есть динозавры типа Windows Mobile 5 или 6, то они не поймут где им и что искать.
А теперь, внимание, самый хитрый хинт:
SMTP использует TCP 25 (клиентский может использовать TCP 587\465, т.н. explicit\implicit TLS), а все остальные сервисы, за исключением POP3 и IMAP, используют TCP 443. Следовательно у вас нет пересечения по сокетам (паре IP:port) и это означает что? А то, что вы можете использовать ОДНО имя.
mx.domain.com
Все. Все сервисы висят на нем, autodiscover висит на записи типа SRV, которая указывает на это же имя (_autodiscover._tcp.domain.com 443 mx.domain.com).

Для того что бы работал Autodiscover необходимо создать CNAME ???, допустим так autodiscover.domain.ru CNAME mail.domain.ru. Но если произойдет переключение на резервного провайдера, и вместо основной MX записи mail.domain.ru будет активна MX запись mx.donain.ru - как в этом случае отработает Autodiscover????? »

Есть мнение, что вы путаете SRV и CNAME...

с некоторой настройкой внутреннего DNS. Как я понял эта настройка называется Split DNS (создание зоны domain.ru на локальном DNS сервере) и конфигурирование Split DNS. »

А еще переписыванием всех InternalURL. Глупость, на мой взгляд. Так можно делать, но только в случае если нет reverse proxy с поддержкой SSL Terminating.

Но тут же Oleg.Kovalenko пишет Цитата: обратите внимание, что публичный сертификат устанавливается на Proxy (TMG|UAG) и HTTPS сесия транслируется на CAS. На CAS используется внутренний сертификат PKI. не понятно для какой службы он используется в CAS????? Для IIS нельзя, для SMTP? - зачем?! В моем варианте с самоподписанным сертификатом, он должен использоваться на CAS? И если да, то для какой из служб. И Вы о том же говорили »

Олег все правильно пишет. Сертификат на CAS висит на тех службах, которые вы видите в поле Services при выводе Get-ExchangeCertificate. По умолчанию он самоподписной, т.е. CAS пи установке выдает его сам себе. Но Microsoft настоятельно рекомендует его менять на внутренний (с использованием внутреннего СА вы вольны делать какие угодно сертификаты, ограничиваясь только своей фантазией, и опять же, у вас не будет проблем с доверием между TMG и CAS).

Что это значит??? Как TMG/UAG решит ошибку с внутренним AutoDiscover »

Внутри автообнаружение работает через Service Connection Point, специальная запись, публикуемая в Active Directory (без нашего участия, обычно) и клиент ищет ее LDAP-запросом.
Ну а если у вас hostname в URL не совпадает ни с одним из имен в сертификате (не забудьте, что то имя, которое у вас в SubjectName, должно обязательно дублироваться в SAN, при этом не идти первым именем в списке, иначе TMG может сойти с ума) ошибку вы получите в любом случае. Ну и Outlook 2007 морально устарел, а если вы его используете до сих пор - надо обновить его до последней доступной версии.

Цитата: URL-адрес службы автообнаружения хранится в объекте точки подключения служб. По умолчанию он ссылается на внутреннее полное доменное имя сервера клиентского доступа, который использовался во время установки этой службы, например: https://имя_сервера.contoso.local/au...todiscover.xml В этом примере полное доменное имя ссылается на внутреннее пространство имен. Как правило, оно не совпадает с внешним пространством имен, например mail.contoso.com. Может Вы доходчиво объясните! »

Outlook внутри сети работает по RPC MAPI, которая не использует https и SSL. Подключение же к веб-сервисам происходит к двум точкам: каталогу адресной книги (OAB) и сведениям о занятости (EWS). Достаточно сменить InternalURL у каталогов EWS и OAB, чтобы этой ошибки не было.
И последнее. Про SSL Bridge или SSL Terminating. Если вы на прослушиватель TMG вешаете сертификат внешний (коммерческий), а на внутренние серверы ваши внутренние сертификаты (не self-signed, а выданные внутренним СА), то можно настроить работу следующим образом:
1. Клиент подключается к TMG по URL https://mail.domain.com на котором висит сертификат mail.domain.com, выданный доверенным СА. Имя может быть как в SN, так и в SAN.
2. Устанавливается шифрованное SSL-соединение.
3. Далее, TMG имея закрытый ключ от этого сертификата, расшифровывает сессию, проверяет ее своими фильтрами (если они включены).
4. После проверки, он берет ОТКРЫТЫЙ ключ сертификата, который висит на внутреннем CAS (cas01.domain.local), зашифровывает сессию им, и отдает на CAS.
Вот так и работает маскировка.
Для этого нужны следующие условия:
1. Коммерческий сертификат должен стоять на TMG ОБЯЗАТЕЛЬНО с закрытым ключом.
2. TMG должен доверять сертификату на CAS (а этого невозможно добиться, если вы используете self-signed), т.е. на TMG должен быть корневой сертификат внутреннего СА (без закрытого ключа, разумеется).
3. В правиле публикации должно быть настроено прохождение пакетов ОТ СЕВРЕРА TMG, а не от клиента. Т.е. TMG пакеты принимает, а потом передает уже от себя.
4. В правиле публикации должна быть отключена опция Keep original header, иначе пакеты, адресованные mail.domain.com, пойдут на cas01.domain.local, что очевидно приведет к несовпадению hostname и ошибке.

Больше этого объяснять не вижу смысла, читайте документацию, иначе это превращается в частные уроки

[zhuk09]

Oleg Krylov, У меня нет слов, одни эмоции!!!! Это действительно развернутый ответ и, огромное Вам спасибо!
И если позволите, хотел немного уточнить
1.

mx.domain.com - SMTP, IP-адрес любой из трех. »

Что в это случае MX - это запись почтового обменника MX???! объясню по чему спрашиваю, у меня в DNS реально есть такие А-записи.
mail.domain.ru. A 1.1.1.1 ; HELO/EHLO = mail.domain.ru
mx.domain.ru. A 1.1.2.2 ; HELO/EHLO = mx.domain.ru
domain.ru. MX 10 mail.domain.ru.
domain.ru. MX 20 mx.domain.ru.
2.

Есть мнение, что вы путаете SRV и CNAME.. »

нет не путаю, об этом говорил Алексей Богомолов

Публикация Autodiscover Чтобы Outlook Anywhere работал правильно, необходимо опубликовать сервис Autodiscover. Находясь в домене Outlook берет адрес сервиса Autodiscover из Active Directory, а находясь за пределами корпоративной сети, Outlook пытается найти этот сервис обращаясь по двум адресам – firma.ru и autodiscover.firma.ru. Я буду использовать адрес autodiscover.firma.ru, следовательно мне нужно на DNS сервере, обслуживающем зону firma.ru зарегистрировать узел с соответствующим именем.

Вот у меня и возник вопрос, сделать это как CNAME к А-записи mail.domain.ru или отдельную А-запись aoutodiscover.domain.ru.
Сможет ли клиент резолвить CNAME.
3.

Внутри автообнаружение работает через Service Connection Point. Ну а если у вас hostname в URL не совпадает ни с одним из имен в сертификате ошибку вы получите в любом случае»

так от куда там взяться внутренним именам, если сертификат не поддерживает .local., а этот сертификат назначен службе IIS. Тогда что не было ошибки делаем

Достаточно сменить InternalURL у каталогов EWS и OAB, чтобы этой ошибки не было. »

а до этого Вы писали, что

А еще переписыванием всех InternalURL. Глупость, на мой взгляд. Так можно делать, но только в случае если нет reverse proxy с поддержкой SSL Terminating. »

Так получается что это не глупость, а в случае с SSL-сертификатом от внешнего поставщика - это НЕОБХОДИМОСТЬ!