none
Именя сертификатов для CAS-Array RRS feed

  • Вопрос

  • Доброго дня! 

    что-то я засомневался, правильно ли я делаю. 

    необходимо запросить сертификат для массива CAS серверов. 

    домен организации abc.com, внутренний домен abc.local. 

    сервера cas1.abc.local, cas2.abc.local  собраны в массив cas.abc.local

    имя сертфиката: mail.abc.com

    SAN:  abc.com

    cas1.abc.local 

    cas2.abc.local

    cas.abc.local

    cas1.abc.com

    cas2.abc.com

    cas.abc.com

    autodiscover.abc.local

    autodiscover.abc.ru

    все ли имена я перечислил?  и мне кажется что я лишнего понаписал. 


    bye-bye!

    15 июня 2012 г. 4:30

Ответы

  • Скорее о купленном сертификате не должен знать внешний клиент. Сценарий простой:

    1. Устанавливаете в Personal Store на ISA Server купленный сертификат с внешними именами, и ОБЯЗАТЕЛЬНО с закрытым ключом.

    2. Создаете Listener на 443 порт внешнего IP, на котором публикуете ОА, и вешаете него этот самый сертификат.

    3. На сервере CAS у вас либо самоподписной сертификат, тогда его надо будет импортировать в Trusted Root CA Store ISA Server (это на самом деле довольно хреновый сценарий), либо вы выписываете сертификат своим внутренним СА (лучше, чтобы он был Enterprise, меньше проблем с доверием доменных машин), а корневой сертификат внутреннего СА импортируете в Trusted Root CA Store ISA Server (если ISA в домене, а СА таки Enterprise, то этого делать не нужно).

    4. Создаете правило публикации на ISA, и на вкладке From в свойствах правила указываете, что запросы приходят не от клиента, а от ISA Server.

    Все должно заработать.

    P.S. Если у вас балансировщик внутри сети (WNLB, HLB, CAS Array) вы в сертификате должны указать FQDN всех CAS и имя массива. И этот сертификат растащить по всем CAS'ам, входящим в массив. Тогда избежите проблем с SSL-доступом внутри сети. Внешние же клиенты о внутренних именах не знают. За всеми веб-сервисами, типа книжки, автообнаружения и т.п. они лезут на внешнее имя, указанное во внешнем сертификате, а на внутренние серверы они полезут RPC MAPI через SSL туннель, построенный до ISA, а для MAPI, как мы выяснили, сертификаты не нужны. Как-то так :)


    MVP Exchange Server from Russia. Please sorry for my English, it's not my native language.

    • Помечено в качестве ответа XobbiT 15 июня 2012 г. 10:49
    15 июня 2012 г. 9:59
    Модератор

Все ответы

  • сертификат будет WildCard?

    для чего autodiscover.abc.ru? если домен com?

    на мой взгляд минимума будет достаточно 

    mail.abc.com (для OWA, т.к. abc.com юзается вероятно как сайт конторы)

    autodiscover.abc.com

    cas.abc.local

    хотя если предусматривать разбор массива по каким либо обстоятельствам можно добавить и 

    cas1.abc.local 

    cas2.abc.local

    • Изменено Sergey33Rus 15 июня 2012 г. 5:59
    15 июня 2012 г. 5:50
  • В данном случае неплохо бы поинтересоваться, а что будет использоваться в качестве файрвола? Будет ли использоваться SSL Bridging? Если это будет ISA\TMG\UAG - можно обойтись двумя именами mail.abc.com и autodiscover.abc.com. SAN имена у коммерческих сертификатов недешевое удовольствие...


    MVP Exchange Server from Russia. Please sorry for my English, it's not my native language.

    15 июня 2012 г. 6:03
    Модератор
  • можно обойтись двумя именами mail.abc.com и autodiscover.abc.com

    не правильный ответ, потому что, клиенты outlook будут дико возмущаться о не соответствии сертификата  mail.abc.com с подключением на cas.abc.local, и придется при каждом запуске всегда соглашаться по 2 раза с тем что сертификат негодный
    15 июня 2012 г. 6:11
  • Сергей, погуглите на тему TMG SSL Bridging, прежде чем диагнозы ставить, ок? :)


    MVP Exchange Server from Russia. Please sorry for my English, it's not my native language.

    15 июня 2012 г. 6:16
    Модератор
  • мое дело предупредить, в последствии гуглить на разные темы уже придется Вам)) Удачи! ;) при чем тут TMG когда речь о локальных клиентах MAPI outlook? если не брать во внимание их, либо отовсюду юзать OWA (из инета оутлук овер HTTP работать тоже будет) то достаточно 1й! записи mail.abc.com и все будет работать при соответствующих настройках и без Wildcard




    • Изменено Sergey33Rus 15 июня 2012 г. 6:52
    15 июня 2012 г. 6:47
  • Предупредить можно, когда разговор предметный. А в сценарии "Я вот пробовал, и у меня выскакивало окошко" - аргументации мало. В сценариях SSL Bridging происходит разрыв https сессии, проверка траффика и повторное шифрование другим ключом. Для этого используются два сертификата: один хранится на файрволе и првизан к прослушивателю внешнего траффика, второй на внутренних серверах CAS. Соответственно при подключении снаружи используется внешний сертификат, при подключении изнутри - внутренний. В каждом сертификате свой набор имен. И никаких окошек :)

    Технология немолодая. В полном объеме поддерживается продутами линейки Forefront. Доступна на решениях Cisco, но стоит каких-то космических денег.

    http://www.isaserver.org/tutorials/Understanding_SSL_bridging_and_tunneling_within_ISA.html

    Да, а TMG при том, что использовать два имени я предложил только при наличии возможности рвать SSL сессии. MAPI-клиентам плевать на сертификаты, они Kerberos используют. Именно поэтму иммена CAS Array не добавляют в сертификаты, т.к. к нему не выполняется SSL подключений.


    MVP Exchange Server from Russia. Please sorry for my English, it's not my native language.


    15 июня 2012 г. 7:29
    Модератор
  • по поводу 2х сертификатов и разрыве сессии, скажу спасибо за наводку, т.к. поиск информации как отказаться от WildCard ибо цены астрономические не дал результатов, искал ответа на вопрос и тут на форуме когдато, решил вопрос по другому, а вот по поводу "MAPI-клиентам плевать на сертификаты, они Kerberos используют" сам так думал и не мог(у) до сих пор понять, отчего же оутлук подключенный по MAPI постоянно плевался на несоответсвие сертификатов? даже при отключенном шифровании трафика, хотя вроде бы подключение не юзает сертификаты шифрует своими методами, докапываться до сути не было времени. Могу сказать по факту как бы там не было, использует оутлук не использует, ну плеваться плюются и это порядком надоедает


    снаружи, из инета все прекрасно


    • Изменено Sergey33Rus 15 июня 2012 г. 8:28
    15 июня 2012 г. 8:20
  • Да-да, именно так они и лаются. Но только при установлении SSL-сессии. Куда лезет Outlook по SSL что снаружи, что изнутри? Правильно в Autodiscover, Availability Service и Offline Address Book. Но само MAPI- подключение, которое MAPI RPC сертификаты не использует.


    MVP Exchange Server from Russia. Please sorry for my English, it's not my native language.

    15 июня 2012 г. 8:49
    Модератор
  • Куда лезет Outlook по SSL что снаружи, что изнутри? Правильно в Autodiscover, Availability Service и Offline Address Book. Но само MAPI- подключение, которое MAPI RPC сертификаты не использует.

    да-да-да))) почитал сейчас, действительно это и есть корень зла)))

    Хотелось бы уточнить по поводу  SSL Bridging т.е. можно внутри сети юзать самопальный сертификат который будет иметь доверие внутри домена, а на TMG опубликовать купленный и все будет работать? т.е. чтобы о купленном сертификате чанга ничего не знал?

    • Изменено Sergey33Rus 15 июня 2012 г. 9:34
    15 июня 2012 г. 9:30
  • Скорее о купленном сертификате не должен знать внешний клиент. Сценарий простой:

    1. Устанавливаете в Personal Store на ISA Server купленный сертификат с внешними именами, и ОБЯЗАТЕЛЬНО с закрытым ключом.

    2. Создаете Listener на 443 порт внешнего IP, на котором публикуете ОА, и вешаете него этот самый сертификат.

    3. На сервере CAS у вас либо самоподписной сертификат, тогда его надо будет импортировать в Trusted Root CA Store ISA Server (это на самом деле довольно хреновый сценарий), либо вы выписываете сертификат своим внутренним СА (лучше, чтобы он был Enterprise, меньше проблем с доверием доменных машин), а корневой сертификат внутреннего СА импортируете в Trusted Root CA Store ISA Server (если ISA в домене, а СА таки Enterprise, то этого делать не нужно).

    4. Создаете правило публикации на ISA, и на вкладке From в свойствах правила указываете, что запросы приходят не от клиента, а от ISA Server.

    Все должно заработать.

    P.S. Если у вас балансировщик внутри сети (WNLB, HLB, CAS Array) вы в сертификате должны указать FQDN всех CAS и имя массива. И этот сертификат растащить по всем CAS'ам, входящим в массив. Тогда избежите проблем с SSL-доступом внутри сети. Внешние же клиенты о внутренних именах не знают. За всеми веб-сервисами, типа книжки, автообнаружения и т.п. они лезут на внешнее имя, указанное во внешнем сертификате, а на внутренние серверы они полезут RPC MAPI через SSL туннель, построенный до ISA, а для MAPI, как мы выяснили, сертификаты не нужны. Как-то так :)


    MVP Exchange Server from Russia. Please sorry for my English, it's not my native language.

    • Помечено в качестве ответа XobbiT 15 июня 2012 г. 10:49
    15 июня 2012 г. 9:59
    Модератор
  • Коллеги, большое спасибо за ответы!

    про abc.ru - очепятка. извиняюсь. конечно же abc.com.

    Да, планируется использование TMG. и спасибо, почитаю про SSL Bridging.

    балансировщик планируется Windows NLB.  и по вашему совету как раз соберу схему с 2мя сертификатами.

    и я правильно понимаю, что для внутреннего сертификата - для внутренних клиентов, и лисенера на TMG - необходимо указывать все внутренние netbios и fqdn CAS-массива и членов массива.  а внешнее не надо. (Exchange же сам определяет - внешний клиент или внутренний).

    и в этом случае, клиентский outlook не будет ругаться, как на скриншоте от Sergey33Rus?

    и если я правильно помню, использование wildcard сертификатов ведет к проблемам с ActiveSync?

    и последний вопрос - насколько правильно указать 3 одинаковых MX записи, с одинаковым весом на разные сервера? (аналог внешней балансировки).  или лучше сделать 3 MX с разными именами и разным весом?   используется 3 сервера в разных филиалах, но имя abc.com - одно на всех. нет желания вводить поддомены 3го уровня. 


    bye-bye!


    • Изменено XobbiT 15 июня 2012 г. 10:53
    15 июня 2012 г. 10:49
  • Нет для внешнего сертификата, который будет на прослушивателе TMG достаточно указать autodiscover.abc.com и mail.abc.com. Это если вы публикуете EAS, OWA и OA на одном IP. Если на разных, то либо несколько сертификатов по одному на каждый IP, либо в этот же добавить еще имен (например owa.abc.com, outlook.abc.com). Внешние клиенты не должны видеть внутренние серверы по https. А для внутреннего сертификата достаточно имен всех узлов CAS и имени CAS Array, если он будет или имя WNLB. При этом, рекомендую во внутренний сертификат добавить как FQDN, так и NetBIOS имена, что позволит без ошибок ходить по коротким URL внутри сети, например на OWA. А SAN для внутреннего сертификата бесплатные же :)


    MVP Exchange Server from Russia. Please sorry for my English, it's not my native language.

    15 июня 2012 г. 10:58
    Модератор
  • Да, wildcard имели проблемы с устройствами на базе Windows Mobile 5 и ниже. Но это очень старые девайсы уже. По поводу балансировки входящего SMTP - да, это абсолютно поддерживаемое решение, будет работать DNS RoundRobin. Единственный минус, письмо может принять хаб из удаленного сайта, а потом тащить его по внутреннему каналу\VPN в тот сайт, где находится ящик.


    MVP Exchange Server from Russia. Please sorry for my English, it's not my native language.

    15 июня 2012 г. 11:32
    Модератор