Как использовать бесплатный SSL сертификат Comodo для роли Lync Server 2010 Edge

2011-03-04, 01:30 / Argon

В этой заметке я расскажу, как использовать бесплатный публичный сертификат (включающий только одно доменное имя и не имеющий списка альтернативных имён SAN) для полноценной работы всех функций роли Lync Server 2010 Edge.

Требования к сертификатам

В документации к Lync Server на TechNet (Certificate Requirements for External User Access, Planning for Certificates) приведены требования, которым должен отвечать публичный сертификат для роли Edge сервера Lync Server 2010. Как можно заметить, сертификат должен содержать несколько альтернативных имен (SAN), удовлетворяющих прихотям нескольких сервисов Lync Server Edge:

  • адрес Access Edge (например, чтоугодно1.argon.pro)
  • адрес Web Conferencing Edge (например, чтоугодно2.argon.pro)
  • адрес SIP Domain для авто-конфигурации клиентов и федерации (только sip.argon.pro)

К несчастью, бесплатных сертификатов с возможностью использовать SAN не выдают. В документации к Lync явно об этом не говориться, но выход есть следующий…

Если все Edge-сервисы расположены на одном публичном IP адресе (на разных портах, естественно), то для обращения к ним можно использовать всего одно доменное имя, и, соответственно, для сертификата — тоже. Из трех перечисленных выше имен только одно является фиксированным: sip.argon.pro, его одного и достаточно для функционирования сервисов Edge.

Установка единого сертификата

Хоть в интернете и можно найти много различных сервисов, предоставляющих бесплатные публичные SSL-сертификаты, для гарантированной работы Edge во всех конфигурациях (доступ клиентов, федерация, работа с аппаратными клиентами) годятся только поставщики, перечисленные в статье Unified Communications Certificate Partners for Exchange Server and for Communications Server. Среди них есть Comodo, который предлагает бесплатный пробный сертификат на 90 дней.

Именно такой сертификат для домена вида sip.argon.pro я и предлагаю использовать. Для этого нужно:

  1. в Certificate Wizard на сервере с ролью Edge генерировать запрос «внешнего» сертификата
  2. убедиться, что в запросе присутствует только одно доменное имя вида sip.argon.pro в параметре Subject CN и списке SAN
  3. подать полученный запрос через веб-интерфейс к центру сертификации Comodo
  4. подтвердить права на домен
  5. после получения сертификата, назначить его на Edge-сервер

С последним пунктом могут возникнуть проблемы. Certificate Wizard в упор не признаёт полученный от Comodo сертификат как корректный (valid). Видимо потому, что ожидает увидеть в свойстве сертификата Enhanced Key Usage значение Server Authentication (1.3.6.1.5.5.7.3.1), а в сертификате от Comodo видит следующее:

  • Server Authentication (1.3.6.1.5.5.7.3.1)
  • Client Authentication (1.3.6.1.5.5.7.3.2)
  • Unknown Key Usage (1.3.6.1.4.1.311.10.3.3)
  • Unknown Key Usage (2.16.840.1.113730.4.1)

И из-за последних двух неопознанных записей считает сертификат непригодным…

Чтобы через силу прописать на Edge полученный от Comodo сертификат, на помощь приходит следующая команда PowerShell:

Set-CSCertificate -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -Thumbprint 7D7E76B3A4582168992DF09F788D96AA42833A81 -Verbose -Confirm:$false -Report "C:\Argon\CertInstall.html"

Значение Thumbprint можно посмотреть в свойствах выданного сертификата; по адресу, указанному в значении Report будет сформирован отчет об успехах в установке сертификата.

После назначения такого сертификата на роль Lync Server 2010 Edge будут без проблем доступны все его сервисы:

  • подключения клиентов
  • конференции
  • федерация
  • работа аппаратных телефонов

Не Edge’ом единым

Хочу напомнить, что для полноценного функционирования всех сервисов Lync Server 2010 через интернет также должны быть опубликованы Lync Web Services, предоставляющие доступ к адресной книге, веб-морде конференции и т. п. Для этого удобно использовать возможности публикации веб сайтов Forefront Threat Management Gateway. Данная тема очень хорошо разобрана на следующих ресурсах:

PS: Если схитрить, то и для Lync Web Services можно использовать тот же SSL сертификат, что и на Edge…

Полезные ссылки



67 комментариев

Alexander Donin
# Комментарий от 2011-03-04, 22:52

Отличная статься. Маленькое уточнение. Для federation не обязательно чтоб имя начиналось на «SIP.»

Argon
# Комментарий от 2011-03-04, 23:44

Согласен, я столкнулся с некоторыми противоречиями на TexНете:

  • в статье Certificate Requirements for External User Access пишут «If you are using client auto-configuration or federation, also include any SIP domain FQDNs used within your company (for example, sip.contoso.com, sip.fabrikam.com).»
  • в статье Planning for Certificates под SIP Domain понимают уже адреса вида sipdomain01.contoso.com
  • сам же Certificate Wizard неприменно включает домен вида sip.contoso.com в список SAN

Где правда?..

Alexander Donin
# Комментарий от 2011-03-05, 02:08

Правда в том, что запись sip. используется для входа поиска сервера, если клиент не может найти SRV запись. Нопример, мой домашний шлюз, скатина такая, не пропускает SRV зпросы.
Для таких случаев и нужно имя SIP.
в документации по Lync почему-то это не описано.
Вот описание из документации к OCS 2007 R2
http://technet.microsoft.com/en-us/library/dd425235(office.13).aspx

Alexander Donin
# Комментарий от 2011-03-05, 02:13

в догонку. в первой статье говорится что дложно быть имя в SIP домене. имеется в виду случай, когда у вас несколько SIP доменов. Для подключения пользователей достаточно одной А записи в любом домене на которую будут ссылаться несколько SRV записей в разных доменах. Но Federation требует четкого соотвествия.

Argon
# Комментарий от 2011-03-05, 09:38

Спасибо, Александр! Я пришел к тем же выводам, основываясь на практике и опыте c OCS-ом, а вот документация Линка слегка смутила.

Кстати, несчет автоконфигурации, интересно, к каким портам клиенты пробуют подключаться, если SRV записи не находят, а видят только имя домена вида sip.controso.com. К 5061 точно подключается, а вот интересно, к каким еще пробуют…

Alexander Donin
# Комментарий от 2011-03-05, 12:08

wireshark :-)
да, 443.

Илья
# Комментарий от 2011-03-22, 18:21

Вот мне интересно как настроить веб прослушиватель для Lync когда порт 443 настроен на веб прошлушиватель OWA? )))

Вот это замануха! Если есть опыт решения данного вопроса поделитесь, пожалуйста!

Argon
# Комментарий от 2011-03-22, 18:36

Если Lync Web Services публикуются через TMG, то очень просто. OWA работает всего с нескольким подкаталогами, типа /owa, /ecp и т. п. Их и перенаправляем на сервер Exchange. На одном прослушивателе, по одному и тому же доменному имени (sip.contoso.com) будут работать и OWA, и сервисы Lync.

Илья
# Комментарий от 2011-03-22, 19:33

Но там же другие настройки авторизации на прослушивателе чем на OWA/Anywhere/ActiveSync
Эти настройки подойдут???
Если да, то это супер…

Argon
# Комментарий от 2011-03-22, 19:43

Если не выполнять авторизацию средствами TMG, а включить возможность авторизации средствами публикуемого веб сервера (делегирование авторизации), то никаких проблем.

Илья
# Комментарий от 2011-03-22, 19:53

а каике риски для owa??? Т.е. безопастность?

Argon
# Комментарий от 2011-03-22, 19:55

Никаких рисков, всё же по SSL шифруется ;)

Илья
# Комментарий от 2011-03-22, 19:56

Большое Спасибо!

Илья
# Комментарий от 2011-03-22, 21:26

правило на TMG для публикации ActiveSync не позволяет в веб прослушивателе отменить аунтификацию… т.к. в этом правеле выбрана обычная проверка для делегирования.

Или можно поставить в не делегированная, но клиент может выполнять и т.д.???

Argon
# Комментарий от 2011-03-22, 21:30

Да, аутентификация силами клиента. Я все свои ресурсы (OWA, SharePoint, Certification Authority, Dynamics CRM, Lync Web Services…) именно так публикую.

Илья
# Комментарий от 2011-03-23, 12:24

И ещё раз Спасибо!.

Argon
# Комментарий от 2011-03-23, 12:26

Рад помочь!

Илья
# Комментарий от 2011-03-25, 02:09

Lync Web App — заработало
У меня ещё вопрос:
Как мне опубликовать EDGE через TMG? Или это не получиться?

Argon
# Комментарий от 2011-03-25, 09:40

Я не рекомендую публиковать Edge через TMG при больших нагрузках, всеж-таки не для риалтайм данных TMG предназначен. Рекомендую железкой разруливать, самая дешевая, но совсем не плохая — Mikrotik.

Если хочется через TMG:

  1. Настроить в Topology Builder-е для Edge-a NAT=[публичный адрес TMG] и свободные на TMG публичные порты (например, Access=5061, A/V=50443, WebConf=50444)
  2. Опубликовать эти порты на TMG правилом публикации произвольного TCP-протокола
Илья
# Комментарий от 2011-03-25, 17:06

нагрузка будет не большая. Это человек 50, ну максимум за год-два вырастет до 100-150.

Спасибо!

Argon
# Комментарий от 2011-03-25, 17:21

50 — это приличная нагрузка, если все через Edge будут сидеть. Если всего человек 10 из них, то да, если через TMG торренты не качают, проблем не будет.

Илья
# Комментарий от 2011-03-25, 17:43

Торренты я закрыл через репутацию на TMG )))

Илья
# Комментарий от 2011-03-25, 17:46

Сейчас решил Edge дать второй внешний интерфейс куда проброшен внешний vlan который смотрит на циску и уже на циске сделать нат TCP на порты 5061, 50444, 50443 на Edge сервер.
Посмотрим что получится…

Argon
# Комментарий от 2011-03-25, 18:35

У меня сделано подобным образом, на Mikrotik-е.

Илья
# Комментарий от 2011-03-26, 15:55

чего-то ни чего не получилось…
телнет должен проходить на эти порты..

Argon
# Комментарий от 2011-03-29, 19:08

Должен ;)

Илья
# Комментарий от 2011-03-30, 10:20

Получилось! За NAT в топологи необходимо было указать внутренний IP адрес интерфейса который смотрит в Интернет, а не публичный IP адрес. И службы все запустились!

Argon
# Комментарий от 2011-03-30, 10:25

Верно, для исключения неприятностей на Edge-сервере лучше иметь 2 сетевых интерфейса, которые смотрят в не пересекающиеся сети. Один — в локалку, второй — в DMZ, в котором на NAT. В качестве DNS указывать внутренний, доменный сервер.

Я, кстати, сегодня получил подтверждения успешной сдачи экзаменов на звание «MCITP: Lync Server 2010 Administrator» ;)

Илья
# Комментарий от 2011-03-30, 11:07

Оооо…!!! Поздравляю! :)
Сложный экзамен?

Argon
# Комментарий от 2011-03-30, 11:31

Как обычно ;)

TS-экзамен скучный и задротский; PRO-экзамен сложный, но интересный. Для подготовки чтения ТехНета было достаточно.

Илья
# Комментарий от 2011-04-04, 10:17

Аргон,

не приводилось ли Вам интегрировать Lync(OCS) с Avaya IP Office 500 на прошивке 6.х???

Сейчас пытаюсь интегрировать данный продукты, но пока как-то ни как…

Argon
# Комментарий от 2011-04-10, 00:27

Нет, с Аваей скрещивать еще не приходилось.

Илья
# Комментарий от 2011-04-10, 14:28

После долгих мучений, у меня получилось их скрестить и плюс ко всему к этому интегрировал Exchange UM. Но пока не всё гладко:
Заметил такую вещь!

Когда звонк проходит на сотовый Lync его сбрасывает и пишет время 00:00

Такое ощущение что успешный дозвон Lync воспринимает как поднятие трубки и не видя голоса или чего там сбрасывает и говорит что вызов завершён или занято… Или лучше так: IPO говорит(возвращает) Lync что соединение установлено и Lync воспринимает это как поднятие трубки…

что-то типа того, думаю суть понятна. Где копать, на АТС или Lync?

Argon
# Комментарий от 2011-04-10, 15:06

Я бы смотрел логи SIP с обеих сторон.

Есть предположение, что может быть проблема с кодеками. То есть соединение по SIP установлено, сигнализация идет, но когда трубку поднимают, должен побежать голосовой трафик. А это по-каким то причинам не происходит. Поэтому соединение разрывается.

С такими вопросами лучше писать комментарии к другим моим заметкам, типа Маршрутизация вызовов в Lync Server 2010.

Artyom Sinitsyn
# Комментарий от 2011-04-24, 20:45

Argon, можно полюбопытствовать, с чего Вы взяли, что «всеж-таки не для риалтайм данных TMG предназначен» и 50 пользователей Edge — это большая нагрузка для TMG?!

Argon
# Комментарий от 2011-04-24, 22:04

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

Реальных измерений не имею, но по моему опыту, TMG всеж-таки заточен на некритичный к задержкам трафик, типа HTTP, FTP и т. п.

50 активных пользователей, да еще если в конференции — разве мало?

Ну и в довершение, TMG официально поддерживается только для публикации Lync Web Services, службы Edge допускают либо прямую публикацию в инете, либо hardware load balancers.

Artyom Sinitsyn
# Комментарий от 2011-04-26, 12:15

Вот я и интересуюсь, откуда у Вас информация, что «TMG всеж-таки заточен на некритичный к задержкам трафик, типа HTTP, FTP и т. п.»?!
TMG включает в себя специализированный SIP Filter для поддержки различных сценариев VoIP (http://technet.microsoft.com/en-us/library/ee690384.aspx).

Тем более, что в официальных тестах «минимальная» конфигурация TMG, выполняющая помимо прочих ролей SIP/VoIP Protection, поддерживает 750(!) пользователей, что «немногим» больше, чем указанные 50 :)

Отмечу, что в случае с SIP/VoIP Protection TMG проводит инспекцию сетевого трафика на уровне приложений, чего в случае «публикации» Lync Edge не происходит. Так что нагрузка в последнем случае будет еще меньше, а значит исходная конфигурация сможет поддерживает еще больше пользователей.

«Ну и в довершение» TMG/ISA *поддерживаются* в роли reverse proxy И firewall для Lync/OCS! Единственное ограничение — нельзя использовать NAT для интерфейса Edge A/V Server.

Argon
# Комментарий от 2011-04-26, 14:59

Артём, возражений против использования TMG как фэрвола и маршрутизации трафика не имею. Вот в том-то и вопрос, если без нат, то зачем нам TMG?

Насчат эффективности работы SIP фильтра хочу проверить. Но пока нет доверия, TMG уже разочаровывал меня.

Artyom Sinitsyn
# Комментарий от 2011-04-26, 16:35

Технически публикация Lync/OCS Edge с помощью TMG c ENAT *работает*! Другой вопрос, что такая конфигурация не поддерживается.
А можно полюбопытстовать, чем же Вас так разочаровал TMG? Может Вы «просто не умеете их готовить»? ;)

Argon
# Комментарий от 2011-04-26, 18:38

Насчет того, что работают все роли Lync через нат TMG — я сам и убеждался, о чем писал несколько выше.

Сейчас расскажу, чем TMG разочаровал… Представим конфигурацию. 2 интернетовских сетевых интерфейса. На каждом по шлюзу. Настроен failover. Все работает. Даже «policy-based routing».

Добавляем на любой из интерфейсов второй IP-адрес. А он не работает. Выключаем failover — работает.

А это значит, что с TMG мы имеем либо failover, либо DirectAccess. Но не оба сразу. В свое время я этим был очень сильно расстроен и потянулся к железкам.

Stanky
# Комментарий от 2011-04-26, 21:02

1. Использовать SAN вовсе не является требованием — можете сделать три одноимённых сертификата и каждый повесить на соответствующий сервис.

2. Для Autodiscovery и уж тем более федерации нет такого требования, чтоб имя в сертификате было вида sip.domain.ru! Использовать можно абсолютно любое! Про вариант с недоступностью SRV-записи Шура пояснил :) .

3. Сертификаты моего постовщика не входят в этот список, но проблем с ним нет, даже на мобильных устройствах! На самом деле, главное, чтоб корень был доверенным на всех устройствах, которыми вы будете пользоваться. Для поставщиков из приведённого списка это просто гарантируется.

Argon
# Комментарий от 2011-04-26, 22:25

Я согласен, что в некоторых частных случаях все работает (использование сертификатов без SAN, без sip.домен, от не поддерживаемых ЦС).

Но всеж-таки «Certificate Requirements for External User Access» говорят вполне конкретные вещи. И если им не следовать, то велика вероятность ступить на детские грабли. То федерация не заработает, то аппаратный Lync-телефон из интернетов не залогинится.

Test
# Комментарий от 2011-06-30, 15:58

Поставил edge все работае нормально, вот только клиенты снаружи заходят без авторизации, в чем может быть глюк?

Argon
# Комментарий от 2011-06-30, 16:44

Предполагаю 2 варианта:

1. Пароль сохранен.
2. Юзеры каким-то образом авторизованы в домене.

Test
# Комментарий от 2011-07-01, 16:40

Компьютер не в домене, снаружи через Линк клиента захожу под любым SIP аккаунтом без авторизации(например, user@test.domain), хотя внутри сети просит авторизацию.
Схема следующая:
1. FE, Mediation server(роли совмещенные на одном сервере)
2. Edge (без нат, с одним IP в наружу, и одним в локалку).

Argon
# Комментарий от 2011-08-17, 00:28

Test, прости что поздно отвечаю, упустил твой коммент.

Логин/пароль, видимо, сохранён в Win Secure Store, посмотреть его можно из панели управления, либо командой:
cmdkey /list

Vladimir
# Комментарий от 2011-12-22, 16:31

Здравствуйте.
настроен lync mobility и работает
внутреннее имя edge server — lync-edge-srv01.xxx.o (оно фигурирует в топологии)
внешнее имя edge server — lync-edge.xxx.ru
внешний сертификат на edge не установлен (для lync-edge.xxx.ru), только для внутреннего домена (xxx.o)
не работает push notification
при тестах:
Test-CsMcxPushNotification -AccessEdgeFqdn lync-edge-srv01.xxx.o
Test-CsFederatedPartner -TargetFqdn lync-edge-srv01.xxx.o -Domain push.lync.com -ProxyFqdn sipfed.online.lync.com
выдаётся ошибка
Test-CsMcxPushNotification : A 504 (Server time-out) response was received from the network and the operation failed. See the exception details for more information.
Подскажите, пожалуйста, поможет ли приобретение сертификата по запросу:
Request-CSCertificate -New -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -FriendlyName «Lync Edge External» -DomainName «lync-edge.xxx.ru,sip.xxx.ru» -KeySize 2048 -PrivateKeyExportable $True -ClientEKU $True -output c:\cert.txt
или нужно что то другое?
Заранее спасибо.

Argon
# Комментарий от 2011-12-22, 17:31

Привет. Push уведомления работают через сервисы на площадке Microsoft, и соответсвенно, требуют настройки федерации с ними. А федереация не возможна без валидного SSL сертификата.

Более полробно по настроеке Lync Mobility Push я нашел здесь.

Vladimir
# Комментарий от 2011-12-22, 18:34

Спасибо!
По этой ссылке я как раз и настраивал))
Все команды прошли без ошибок, только тесты выходят с ошибкой 504 — как я выше писал.
Если есть опыт — не знаете какой лучше запрос на сертификат сделать?
Request-CSCertificate -New -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -FriendlyName «Lync Edge External» -DomainName «lync-edge.xxx.ru,sip.xxx.ru» -KeySize 2048 -PrivateKeyExportable $True -ClientEKU $True -output c:\cert.txt
И запрашивать надо UCC сертификат?

Argon
# Комментарий от 2011-12-22, 18:52

Для формирования запросов я всегда использовал GUI, через PowerShell не так наглядно и вероятность ошибки больше.

Для публикации Edge достаточно сертификата на имя sip.xxx.ru, если в SRV-записях используется оно же.

UC-сертификат отличается от остальных SAN сертификатов, что позволяет добавить в SAN локальные DNS-имена типа lync.domain.local. Нам на эдж это не требуется.

Vladimir
# Комментарий от 2011-12-22, 19:49

у нас в srv записи используется lync-edge как раз ))
и при создании запроса чз GUI в запрос как то прописывается SAN sip, хотя это не указываю.
а из power shell только lync-edge, без SAN
попробую бесплатный триальный сертификат на lync-edge получить и с ним попробовать push notification

Argon
# Комментарий от 2011-12-22, 23:27

Я бы рекомендовал поправить SRV-записи на sip.xxx.ru, и на это имя выписать сертификат. Собственно, об этом и статья.

Vladimir
# Комментарий от 2011-12-23, 13:34

поменять SRV запись несложно (так как и sip.xxx.ru и lync-edge.xxx.ru ссылаются на один и тот же ip адрес)
а вот выписать сертификат на sip проблематично,
так как имя сервера lync-edge и в топологии lync везде фигурирует именно это имя
а сервер уже в работе и менять имя, топологию, а следовательно и переустанавливать lync на edge как то нехорошо))

Vladimir
# Комментарий от 2011-12-23, 19:00

получили временный сертификат на lync-edge.xxx.ru
импортировал в wizard`е, пишит invalid как и в статье.
чз power shell выполнил
Set-CSCertificate -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -Thumbprint «отпечаток из сертификата lync-edge.marya.ru» -Verbose -Confirm:$false -Report «C:\Argon\CertInstall.html»
выполняет с 1 warning
и в отчёте пишет:
Warning: The chain of the certificate «отпечаток из сертификата lync-edge.marya.ru» is invalid.
и в wizard так же сертификат invalid и тест
https://www.testocsconnectivity.com/
не проходит по ошибке: The SSLCertificate failed one or more certificate
может быть есть какие-нибудь идеи?
заранее спасибо.

SIDERMAN
# Комментарий от 2012-01-08, 22:29

Vladimir, у меня подобная ситуация: SRV-запись lync-edge.domain.com, но имя сервера lync01.domain.com
в топологии указано имя edge-сервера — lync01.domain.com а в настройках топологии edge — в разделе SIP Access, Conferencing, A/V… — lync-edge.domain.com
появляется путаница, так как в доках технета сказано «Even though the certificate subject name is equal to the access Edge FQDN» — отсюда вопрос Edge FQDN — это имя сервера топологии, либо имя прописанное в настройках Edge, во внешнем днсе?
И вообще работает ли при такой конфигурации Edge с внешним сертификатом
Я так понял, что у вас возникли проблемы, хотя судя из ошибки такое чувство что просто ошибка в написании отпечатка..

Argon
# Комментарий от 2012-01-09, 00:38

Коллеги, хочу уточнить следующие моменты

Vladimir
так как имя сервера lync-edge и в топологии lync везде фигурирует именно это имя
а сервер уже в работе и менять имя, топологию, а следовательно и переустанавливать lync на edge как то нехорошо))

Нельзя менять внутреннее имя сервера, это так. Однако, в редакторе топологии можно легко поменять внешнее имя в разделе Edge server configuration > External Settings.

Именно это имя (или имена) должно содержаться во внешнем SSL сертификате.

Сообщение «Warning: The chain of the certificate ### is invalid» говорит о том, что не вся цепочка сертификатов валидна на локальном компьютере. Скорее всего, пропущен какой-то Intermediate центр сертификации. Проверить это легко, если открыть свойства выданного сертификата (.cer) и проверить цепочку. Если там есть какие-то проблемы, то доустановить пропущенные CA в хранилища Root или Intermediate компьютера. Цепочка должна заканчиваться на корневом, самоподписанном CA.

SIDERMAN
# Комментарий от 2012-01-09, 21:50

а в subject name должно тоже быть имя из external settings или нетбиос имя сервера указанное в топологии?

Argon
# Комментарий от 2012-01-09, 21:55

Для внешнего сертификата в Subject (Common) Name либо в SAN должно быть имя из External Settings (access/sip, webconf, av).

Кстити, netbios имена вообще нигде не должны использоваться, только FQDN. Для внутреннего сертификата, соответсвенно, внутренее полное DNS-имя. Если Edge развернут на компе в рабочей группе, то на этом компе должен быть прописан осоновной DNS-суффикс.

SIDERMAN
# Комментарий от 2012-01-10, 10:56

понятно, спасибо. Просто сбила с толку фраза:
Even though the certificate subject name is equal to the access Edge FQDN

Argon
# Комментарий от 2012-01-10, 14:47

Кстати, поставил себе на тестовыю лабу бесплатный сертификат от startssl — все тесты проходит, федерация работает.

Zuz666
# Комментарий от 2012-03-11, 20:06

1. С StartSSL не буедт пока работать федерация с sipfed.online.lync.com (push-нотификации и офис365). По информации от StartSSL в этом направлении работы идут. Но пока мне детально не подтвердили в чём затык. Надо M$ в этом направлении тоже помучать.
2. Так же можно получить сертификат для каждого «сервиса» отдельно (не надо их разносить по портам), например, для Acees Edge (федерации и доступа по sip) можно получить халявный комодо сертификат Request-CSCertificate -New -Type AccessEdgeExternal … , а для всего остального StartSSL. Естетсвенно, всё тогда проще делать через повершел. Мастер в линке слегка глючит.

Zuz666
# Комментарий от 2012-03-11, 22:29

Stanky: «3. Сертификаты моего постовщика не входят в этот список, но проблем с ним нет, даже на мобильных устройствах!»
А можно поинтересоваться, кто ваш постовщик? Я бы указал M$ на то, что есть те, кто всписок не входит и с ними всё работает. )))

Argon
# Комментарий от 2012-03-11, 23:27

Zuz666, спасибо за комменты. Особенно мне кажется полезной идея использовать одновременно серты от Comodo и StarSSL на разных сервисах.

SIDERMAN
# Комментарий от 2012-04-11, 00:29

http://blog.schertz.name/2011/02/wildcard-certificates-in-lync-server/
в этой статье описываются ньюансы использования wildcard сертификата — мегаудобного сертификата, который как выясняется полностью не поддерживается Lync Server. Из статьи я понял, что в Common Name должно быть имя Edge и выше об этом писалось, но достаточно ли будет в SAN — *.domain.com?
Кто-нибудь использовал на практике?

Argon
# Комментарий от 2012-04-13, 14:29

На практике я сталкивался с тем, что аппаратным телефонам Polycom сносило крышу от wildcard-сертификатов. Конкретнро в моем случае они не подключались к веб-службам Exchange (были недоступны календари и прочее). Wildcard на сами службы Lync еще ставить не пробовал.

Zuz666
# Комментарий от 2012-06-11, 01:12

Как-то забыл рассказать, что заработала на сертификатах StartSSL федерация с sipfed.online.lync.com (push-нотификации и офис365).

Василий
# Комментарий от 2012-10-31, 16:10

Для внешнего доступа запросил бесплатный сертификат у COMODO, как рекомендуется вот тут: http://argon.pro/blog/2011/03/lync-edge-ssl-certificate/
собственно в логе установки сертификата пишет вот такое:
Warning: The chain of the certificate “3C1CCD4C4660085A67A5BD037D7E284D683712DA” is invalid.
в менеджере сертификатов также пишет INVALID
сертификат выписан на одно имя lync.tdabbat.ru собственно использую 1 белый IP и одно доменное имя для внешнего доступа.
Все сертификаты что пришли вместе с заказаным добавил в доверенные, сейчас любой из серт. из цепочки является доверенным, что ещё можно ковырнуть?

Добавить комментарий