none
Проблемы с сертификатами или с чем-то еще RRS feed

  • Вопрос

  • Ситуация такая: всё сделали по описанной в "известных роликах" методике: Lync 2010 server + Edge. Единственное, что у нас это хозяйство за NAT. Никаких проблем/ошибок - внутри сети все замечательно. Извне вот какая ситуация при тестировании через testexchangeconnectivity (см. ниже).

    Вопрос: что не так?! Сертификаты сгенерили, привязали. На эдже загрузили в доверенные сертификат ROOT CA. Пробовали перегенерить сертификаты и перепривязать их - никаких ошибок, но извне так все и остается.

    Testing remote connectivity to Microsoft Lync server through the Lync Access Edge server sip.lyncsm.ru on port 443 to verify user a.v.lizunkov@lyncsm.ru can connect remotely.
    Specified remote connectivity test(s) to Microsoft Lync server failed. See details below for specific failure reasons.
    Этапы проверки
    Attempting to resolve the host name sip.lyncsm.ru in DNS.
    The host name resolved successfully.
    Дополнительные сведения
    IP addresses returned: xxx.3.143.251
    Testing TCP port 443 on host sip.lyncsm.ru to ensure it's listening and open.
    The port was opened successfully.
    Testing the SSL certificate to make sure it's valid.
    The SSL certificate failed one or more certificate validation checks.
    Этапы проверки
    ExRCA is attempting to obtain the SSL certificate from remote server sip.lyncsm.ru on port 443.
    ExRCA successfully obtained the remote SSL certificate.
    Дополнительные сведения
    Remote Certificate Subject: CN=sip.lyncsm.ru, Issuer: CN=Lyncsm Root CA, DC=lyncsm, DC=ru.
    Validating the certificate name.
    The certificate name was validated successfully.
    Дополнительные сведения
    Host name sip.lyncsm.ru was found in the Certificate Subject Common name.
    Certificate trust is being validated.
    Certificate trust validation failed.
    Этапы проверки
    ExRCA is attempting to build certificate chains for certificate CN=sip.lyncsm.ru,
    A certificate chain couldn't be constructed for the certificate.
    Дополнительные сведения

    14 декабря 2012 г. 7:46

Все ответы

  • Доброе утро.

    У вас возникают какие-либо проблемы при работе внешних пользователей с линком или вас просто смущает что тест не пройден?

    Вы используете публичный сертификат или сгенерированный локальным центром сертификации?

    Какие CAN имеются в вашем сертификате?

    17 декабря 2012 г. 6:19
  • Не то чтобы смущает, - внешние пользователи не могут приконнектиться - клиент линка говорит, что возникли проблемы с сертификатом.

    Используется сертификат, выданный локальным центром сертификации.

    SANы кроме sip.lyncsm.ru Добавлены av. и webconf.


    17 декабря 2012 г. 7:19
  • для Lync Edge External сертификат кроме CN - sip.lyncsm.ru, должен содержать SAN: sip.lyncsm.ru и webconf.lyncsm.ru. av не обязательно.

    Do not multiply entities beyond what is necessary

    17 декабря 2012 г. 7:30
  • Так, давайте разбираться... Вот как это выглядит у нас:

    17 декабря 2012 г. 7:52
  • поле CN этого сертификата покажите пожалуйста.

    Do not multiply entities beyond what is necessary

    Одну минуту. А вы сертификат Root CA вашего центра сертификации клиентам в хранилище "корневые доверенные центры сертификации" положили?
    • Изменено Dmitry.I 17 декабря 2012 г. 8:05
    17 декабря 2012 г. 8:01
  • Да! Конечно и рутовый и этот даже.


    17 декабря 2012 г. 8:17
  • этот не надо, а вот рутовый в какое хранилище размещали, компьютера или пользователя?

    Do not multiply entities beyond what is necessary

    17 декабря 2012 г. 8:23
  • В компьютера. Я вот думаю уже, может быть проблема в чем-то другом?! Вообще, тест доступности с сайта скалывается именно на проверке цепочки сертификата. Но, возможно проблема не в этом?!

    17 декабря 2012 г. 8:29
  • ну так то все вроде здорово.

    У вас сертификат Root CA в единственном числе? А то встречал ситуацию, когда рутовый сертификат был перевыпущен, а сертификат Lync содержал в своей цепочке прежний, недействительный.


    Do not multiply entities beyond what is necessary

    17 декабря 2012 г. 8:34
  • Нет. Всё в единственном числе. Ничего не перевыпускалось.
    Значит дело не в сертификатах... А вот если работоспособный Линк извне потестировать на доступность через сайт майкрософтовский, то он тоже ругнется на построение цепочки и дальше пойдет?! Может на самом деле проблема не в этом? Но тогда непонятно почему тестирование доступности скалывается на этом шаге.
    17 декабря 2012 г. 9:29
  • Внешние пользователи не смогут подключиться из интернета к вашему серверу Lync, так как сертификат ему выдан локальным центром. Для того что бы у внешних пользователей не появлялась ошибка проверки сертификата, им необходимо поставить сертификат вашего корневого центра, или для сервера Lync издать публичный.

    17 декабря 2012 г. 9:30
  • да есть у внешних клиентов рутовый сертификат, проблема не в нем.

    Александр, если клиент ругается на сертификат, значит все же дело в нем. Попробуйте в свойствах IE внешнего клиента убрать галочку "Проверять аннулирование сертификатов издателей"


    Do not multiply entities beyond what is necessary


    • Изменено Dmitry.I 17 декабря 2012 г. 9:58
    17 декабря 2012 г. 9:55
  • То что Вы говорите, - правда! Но посмотрите предыдущую картинку: это скрин с удаленного компьютера. В доверенных корневых центрах болтается сертификат ROOT CA. Может быть дело в чем-то другом?! Вообще на клиенте удаленном ошибка, что сервер временно недоступен, но он доступен.

    17 декабря 2012 г. 9:59
  • так все таки какая ошибка на клиенте? Ошибка сертификата, или "Сервер недоступен"?


    Do not multiply entities beyond what is necessary

    17 декабря 2012 г. 10:02
  • Так... сейчас еще раз посмотрел: на клиенте ошибка "не удается выполнить вход, так как сервер недоступен... пожалуйста попробуйте позже." Но меня смущает ошибка на testexchangeconnectivity: там ошибка проверки сертификата.

    И как он может быть недоступен, если testexchangeconnectivity на него заходит?!

    Коллеги, а может кто-нибудь кинуть результаты проверки своего сервера черезе testexchangeconnectivity?! чтобы увидеть, какие там дальше шаги и есть ли они?!

    17 декабря 2012 г. 10:07
  • а адрес сервера каким образом вы прописываете на клиенте -  ручками? Или у вас во внешнем DNS заведены записи A и SRV?

    Если руками, то какой указываете адрес - точно.


    Do not multiply entities beyond what is necessary

    17 декабря 2012 г. 10:13
  • если у вас нет публичного сертификата то сервис testexchangeconnectivity не пройдет валидацию в принципе и всегда будет на него ругаться. Прогоните проверку поставив галочку не проверять сертификат. Если на клиенте пишет что сервер не доступен то это уже совершенно другое дело. Если Lync опубликован через TMG, проверяйте правила портов, наты и тому подобное.
    17 декабря 2012 г. 10:15
  • Заведены во внешнем DNS. Вот так:

    На клиенте пишу внешний адрес входа: sip.lyncsm.ru:443

    В принципе, можно вообще ставить автоматическое определение, как я понимаю, если srv-запись проставлена.

    Вот у меня все же есть сомнения принципиальное отличие от того, что в известном видео-примере - то, что у нас Линк за NAT. Может быть есть какие-то особенности?! Может NAT оказывать какое-то воздействие на проверку сертификатов?! (хотя это уже отдает бредом)...

    17 декабря 2012 г. 10:23
  • Нет не оказывает и у Станкевича с Мамышевым есть отличное видео как перенести Lync за нат, лично у меня 2 сервера за натом прекрасно живут. Включайте Logging Tool на линке и начинайте искать проблему, смотрите журнал на TMG, проверяйте порты. Причин недоступности миллион.

    Lync с чистого листа (видео-демонстрации)
    17 декабря 2012 г. 10:26
  • мне кажется, что проблема в конфигурации TMG. Вы не включали логирование? Посмотреть что куда разрешается?

    Edge за NAT является поддерживаемой конфигурацией, просто в топологии указывается, что Edge расположен за NAT, там даже чекбокс такой есть :) 


    Do not multiply entities beyond what is necessary

    17 декабря 2012 г. 10:28
  • у нас нет TMG.
    17 декабря 2012 г. 10:55
  • у нас нет TMG.

    А каким образом у вас опубликован Lync в Интернет?
    17 декабря 2012 г. 11:02
  • Мммм... У нас сделаны записи в DNS и сделан проброс портов на нашем маршрутизаторе, я так понимаю, что тоже самое делает и TMG.
    17 декабря 2012 г. 11:15
  • Мммм... У нас сделаны записи в DNS и сделан проброс портов на нашем маршрутизаторе, я так понимаю, что тоже самое делает и TMG.

    А что отвечает за NAT?
    Проверьте доступность портов.
    На пограничном транспортном сервере запустите Logging Tools и начинайте смотреть что пишет в SIP во время не удачного соединения.

    17 декабря 2012 г. 11:21
  • в топологии определено, что Lync за NAT? External адреса Edge фейковые?

    Do not multiply entities beyond what is necessary

    17 декабря 2012 г. 11:58
  • Отвечает Cisco PIX, порты доступны 443 и 5061. Про Логгинг тулз - правильная мысль пожалуй. Будем пробовать.
    17 декабря 2012 г. 12:10
  • 1-Да.

    2-Да.

    17 декабря 2012 г. 12:10
  • Коллеги! Ситуация разрешилась но только наполовину...

    Чтение логов ничего не дало, но одно слово not Autorized  натолкнуло на мысли!

    Мы вспомнили, что в настройках линка есть что-то про виды авторизации. В итоге мы сняли галки с авторизации с помощью сертификатов и с кербероса заодно. Оставили только NTLM. И... О, чудо! Все заработало.

    Но эксперимент-то не завершен! На удаленном компе выкидываем ROOT CA из хранилища... - не пускает! Закидываем - пускает. То есть что означает эта опция типа авторизации в консоли мы до конца так ине поняли, раз сертификат все равно нужен. Мы также не поняли, в чем проблема была, вернее она и есть, мы просто её обошли.

    • Помечено в качестве ответа Alexandr Lizunkov 17 декабря 2012 г. 16:35
    • Снята пометка об ответе Alexandr Lizunkov 17 декабря 2012 г. 16:35
    • Помечено в качестве ответа Alexandr Lizunkov 17 декабря 2012 г. 16:35
    • Снята пометка об ответе Alexandr Lizunkov 17 декабря 2012 г. 16:35
    17 декабря 2012 г. 16:35
  • Сертификат нужен будет всегда! Не забывайте что Lync шифрует трафик! Что бы не раздавать всем ваш рутовый сертификат, вам нужно приобрести публичный, например от COMODO.
    18 декабря 2012 г. 5:27
  • Вероятно, - да! Ну, сейчас придется настроить RP для мобильников, тогда и подумаем.

    18 декабря 2012 г. 8:51
  • RP не только для мобильников нужен вообще то :). Для обычных внешних клиентов тоже желателен.

    Do not multiply entities beyond what is necessary

    18 декабря 2012 г. 8:59
  • Alexandr Lizunkov, вопрос актуален?

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий

    16 января 2013 г. 13:26