[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 и ошибке.

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