Exchange 2010 и SSL сертификат
 

обрый день!
Имеется Exchange 2010 Версия: 14.03.0224.002.
Необходимо выпустить OWA/ActiveSync/Outlook Anywhere наружу.
Как бы в основном проблем нет, но возник один вопрос
В DNS есть 2 MX записи
mail.domain.ru 10
mx.domain.ru 20
Соответственно каждой MX записи соответствует своя А-запись. И у каждого из провайдера прописана PTR.
Теперь вопрос:
заказать один сертификат с SAN mx.domain.ru и mail.domain.ru (ну и соответственно с autodiscover и локальными FQDN) и при публикации на TMG 2010 повесить сертификат на один веб-прослушиватель привязанный к Внешней сети
или заказать 2 сертификата один с mx.domain.ru, другой с mail.domain.ru, и повесить эти сертификаты к разным веб-прослушивателям привязанные к разным IP-адресам.

Самое главное, что бы не было такой ошибки msexchangetransport 12014 http://www.eventid.net/display-event...55-phase-1.htm при смене FQDN на коннекторе отправки c mail.domain.ru на mx.domain.ru ?!
Или достаточно того что mx.domain.ru - будет прописан в SAN, не смотря на то что в сертификате будет CN=mail.domain.ru???

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

Oleg Krylov, добрый день!
Начну по порядку.
Да, действительно RuCenter отказал в выдаче такого типа сертификата. Хотя я точно знаю, что такие сертификаты выпускали
http://www.buldakov.ru/?p=2289

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

Внутри домена нет своего 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????

они очень дорогие, нашел решение чуть дешевле Geotrust True BusinessID SAN
Тогда не пойму, какие имена должны быть в сертификате от внешнего поставщика
mail.domain.ru, mx.domain.ru, autodiscover.domain.ru - Так???
Мне для веб-сервисов это и не нужно, я хотел одним сертификатом закрыть все службы. И еще я писал
Так как ранее писал, что - 2 интернет канала

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

И еще один вопрос
Если идти по этому варианту
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?????

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

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

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 пишет
не понятно для какой службы он используется в CAS????? Для IIS нельзя, для SMTP? - зачем?! В моем варианте с самоподписанным сертификатом, он должен использоваться на CAS? И если да, то для какой из служб. И Вы о том же говорили
и потом вот это
Что это значит??? Как TMG/UAG решит ошибку с внутренним AutoDiscover ??? http://support.microsoft.com/kb/940726
Может Вы доходчиво объясните!

То было раньше, сейчас не выпускают. Стас довольно подробно описал ситуацию. Стасу надо верить.
Что не есть хорошо. Outlook умеет обрабатывать исключение SSL Certificate self-signed, но другие клиенты не умеют. Поэтому проще поднять СА и выпустить себе сертификатов по душе. Если вы делаете его Enterprise CA, то корневой сертификат вашего СА автоматически распространится на все машины-члены домена. Поднять СА не так уж сложно (в базовой конфигурации, понятно, но тут не до Best Practice) в интернетах можно найти достаточно инструкций, как это сделать в стиле Next-Next-Finish.
359$ по текущему курсу это 23 тысячи рублей. Хорошее решение wildcard от GoDaddy (21 тысяча или 19 если брать на срок более одного года). В России нет поставщиков SSL-сертификатов, которые прошли процедуру верификации и входят в партнерскую программу Microsoft (да и других). Т.е. их корневые сертификаты не размещаются в продуктах по умолчанию и использование их не отличается от использования собственного СА. А все иностранные поставщики продают за доллары, отсюда и рост цен на них в последнее время. Я еще раз отмечу - wildcard будет лучшим решением для вас.
Зависит от того, зачем вам сертификат для 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).
Есть мнение, что вы путаете SRV и CNAME...
А еще переписыванием всех InternalURL. Глупость, на мой взгляд. Так можно делать, но только в случае если нет reverse proxy с поддержкой SSL Terminating.
Олег все правильно пишет. Сертификат на CAS висит на тех службах, которые вы видите в поле Services при выводе Get-ExchangeCertificate. По умолчанию он самоподписной, т.е. CAS пи установке выдает его сам себе. Но Microsoft настоятельно рекомендует его менять на внутренний (с использованием внутреннего СА вы вольны делать какие угодно сертификаты, ограничиваясь только своей фантазией, и опять же, у вас не будет проблем с доверием между TMG и CAS).
Внутри автообнаружение работает через Service Connection Point, специальная запись, публикуемая в Active Directory (без нашего участия, обычно) и клиент ищет ее LDAP-запросом.
Ну а если у вас hostname в URL не совпадает ни с одним из имен в сертификате (не забудьте, что то имя, которое у вас в SubjectName, должно обязательно дублироваться в SAN, при этом не идти первым именем в списке, иначе TMG может сойти с ума) ошибку вы получите в любом случае. Ну и Outlook 2007 морально устарел, а если вы его используете до сих пор - надо обновить его до последней доступной версии.
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 и ошибке.

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

Oleg Krylov, У меня нет слов, одни эмоции!!!! Это действительно развернутый ответ и, огромное Вам спасибо!
И если позволите, хотел немного уточнить
1.Что в это случае 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. нет не путаю, об этом говорил Алексей Богомолов
Вот у меня и возник вопрос, сделать это как CNAME к А-записи mail.domain.ru или отдельную А-запись aoutodiscover.domain.ru.
Сможет ли клиент резолвить CNAME.
3.так от куда там взяться внутренним именам, если сертификат не поддерживает .local., а этот сертификат назначен службе IIS. Тогда что не было ошибки делаема до этого Вы писали, что
Так получается что это не глупость, а в случае с SSL-сертификатом от внешнего поставщика - это НЕОБХОДИМОСТЬ!