none
SSL Сертификат в Exchange 2013 RRS feed

  • Вопрос

  • Добрый день, 

    Начну с описания.

    В компании есть 2 exchange сервера 2007 и 2013. Мигрирую с 2007го на 2013й. Пока транспортные роли и общие папки еще не передал на 2013, т.к. не перенес еще все почтовые ящики. Купили сертификат WildCard RapidSSL. Поставил, опубликовал, создал в DNS дополнительную зону, т.к имя домена ".local", а внешнее имя ".kz" (Казахстан). По внутрянки все работает нормально по NTLM, один раз запрашивает сертификат, ставишь и все без проблем. Веб доступ работает нормально с редиректом на https, захожу в браузере на адрес сайта, все отлично, с сертификатом. Otlook Anywer включен, по NTLM, галка разрешить загрузку SSL стоит. Настройка внутреннего и внешнего сайта одинаковая. Проблем начинаются, когда пытаюсь подключить почту по POP3 или IMAP. Проблемы по списку.

    1. Пытаюсь назначить службам POP и IMAP этот сертификат, выдает ошибку "Этот сертификат с отпечатком  не может быть использован для SSL- и TLS-подключений POP, так как субъект не является полным доменным именем. Используйте команду Set-POPSettings, чтобы задать для параметра X509CertificateName полное доменное имя службы." Гуглил, читал статьи, но так и не понял как исправить проблему, везде пишут, что надо сразу делать запрос с нормальным FQDN, при чем сертификат на серевере стоит. Че делать не знаю подскажите или дайте направление.

    2. При настройке на Outlook клиенте при использовании типа шифрования TLS проверку на сервере проходит и то, только после того, как я вчера на DNS создал SRV запись для _autodiscover, а вот при отправке тестового письма запрашивает логин и пароль постоянно.  При настройке  SSL шифрования так же логинится, но пишет что "На сервере отсутствует поддержка указанного типа шифрования подключений." Пробовал для протоколов, на сервере, поменять способ входа с TLS  на обычную проверку, не помогает, все время просит логин и пароль.

    3. Делаю Test Connectivity и если прописываю ручками RPS proxy server (вбиваю опубликованное внешнее имя) Exchange server (Имя сервера, не совпадает с опубликованным), проходит все почти нормально, вот c таким алертом  "The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.". А вот если делаю поиск автоматом по автодискавери, то выдает ошибку "Failed to validate autodiscover CNAME record in DNS. If your mailbox isn't in Office 365, you can ignore this warning." и похоже после добавления SRV записи "Host autodiscover ИМЯ ДОМЕНА couldn't be resolved in DNS InfoDomainNonexistent."

    В общем ступор у меня, не знаю куда дальше копать. Понимаю что проблема с сертификатом и его FQDN именем, но как его правильно прописать не пойму. Буду щас конечно еще гуглить, но может кто нить подскажет, в какую сторону копать или сразу решение, если кто то уже сталкивался?

    2 ноября 2016 г. 6:03

Ответы

  • у вас, как я вижу, два сервера, а почему разные имена хостов? owa на одном и owa2 на втором? Для внешних подключений лучше использовать не NTLM, а Basic аутентификацию.

    И еще, проверьте еще раз внешнюю зону DNS, пропишите там CNAME запись autodiscover, которая ссылается на внешнее имя хоста Exchange.


    Do not multiply entities beyond what is necessary

    3 ноября 2016 г. 5:18

Все ответы

  • Забыл дописать. Публикация почты идет через Kerio 9. На нем настроен обратный прокси. И на стороне провайдера созданы DNS записи на белый IP адрес с внешним и внутренним(локальным) именами сервера.  


    2 ноября 2016 г. 8:11
  • Кажись нашел откуда растут ноги. Похоже, когда подключаешь через pop или imap он подтягивает не купленный сертификат, а внутренний, самоподписаный. Но эта проблема, похоже, относится к первому пункту. Как теперь указать ему нужный сертификат?
    2 ноября 2016 г. 9:18
  • DNS записи у провайдера не должны включать в себя ваши внутренние адреса. Сертификат, как я понимаю, вы установили на сервер Exchange? В таком случае необходимо сконфигурировать веб службы Exchange так, чтобы имена совпадали с именем, указанном в сертификате, например, если CN сертификата *.domain.com, то и виртуальные каталоги Exchange должны быть сконфигурированы на использование этого имени, например: mail.domain.com/owa (для виртуального каталога OWA) и так далее.

    Насколько я помню, обратный прокси на Kerio не совсем полноценный, хоть и позволяет привязывать сертификат к правилу публикации. В любом случае, если внутри используется сертификат, выданный внутренним СА, то размещение Wildcard сертификата на Kerio не спасает от проблем при внешнем доступе (в первую очередь мобильными клиентами и клиентами Outlook).

    Если не секрет, а для чего вам POP3 и IMAP? Это же устаревшие протоколы.


    Do not multiply entities beyond what is necessary

    2 ноября 2016 г. 10:26
  • "DNS записи у провайдера не должны включать в себя ваши внутренние адреса"

    Ну сделали как на старом почтаре было настроено.

    "Сертификат, как я понимаю, вы установили на сервер Exchange?"

    Да

    "В таком случае необходимо сконфигурировать веб службы Exchange так, чтобы имена совпадали с именем, указанном в сертификате, например, если CN сертификата *.domain.com, то и виртуальные каталоги Exchange должны быть сконфигурированы на использование этого имени, например: mail.domain.com/owa (для виртуального каталога OWA) и так далее."

    Так и сконфигурено

    Про Керио... Что самое смешное, OWA то он и другие сервисы с веб мордой, например owncloud, он публикует нормально. И что самое смешное, на мобильниках поперло нормально и стало работать без проблем.

    "Если не секрет, а для чего вам POP3 и IMAP? Это же устаревшие протоколы."

    ну так пытаюсь настроить на Outlook клиенте, в удаленном офисе, и тут то как раз встреваю. И что самое интересное, на сервер то он теперь заходит, проблема возникает, при отправке тестового письма, начинает запрашивать логин и пароль и похоже пытается подтянуть не купленый вайлкард сертификат, а встроенный сертификат эксченджа, а вот почему не пойму пока. 


    2 ноября 2016 г. 10:42
  • Может быть проблема с версией клиента Outlook? Потому что если нормально работает мобильный доступ и OWA (без предупреждения о неправильном сертификате), значит и Outlook должен нормально работать.

    покажите вывод Get-OutlookAnywhere

    И еще, воспользуйтесь MS RCA для определения источника проблемы.


    Do not multiply entities beyond what is necessary


    • Изменено Dmitry.I 2 ноября 2016 г. 12:13
    2 ноября 2016 г. 12:11
  • Врятли проблема в версии оутлука, пробовал на 2103 оффисе и 2007.Что самое интересное, на мобилу похоже правильный сертификат подтягивает, а вот на комп почему то самоподписанный.

    MR RCA пользовался, говорит, что проблема в автодискавери и SRV записью на ДНС, вот часть ошибок, т.к. не могу картинки еще вставлять

    Testing TCP port 443 on host galanz.kz to ensure it's listening and open.

    The specified port is either blocked, not listening, or not producing the expected response.

    Attempting to test potential Autodiscover URL https://autodiscover.galanz.kz:443/Autodiscover/Autodiscover.xmlTesting of this potential Autodiscover URL failed.

    Attempting to resolve the host name autodiscover.galanz.kz in DNS.

    The attempt to contact Autodiscover using the HTTP Redirect method failed.

    The Microsoft Connectivity Analyzer failed to contact the Autodiscover service using the DNS SRV redirect method.

    Attempting to locate SRV record _autodiscover._tcp.galanz.kz in DNS

    The Autodiscover SRV record wasn't found in DNS.

    Get-OutlookAnywhere

    RunspaceId                         : 07494546-bdc9-49f0-9485-129b54ed605b
    ServerName                         : MX1
    SSLOffloading                      : False
    ExternalHostname                   : owa.galanz.kz
    InternalHostname                   :
    ExternalClientAuthenticationMethod : Ntlm
    InternalClientAuthenticationMethod : Ntlm
    IISAuthenticationMethods           : {Ntlm}
    XropUrl                            :
    ExternalClientsRequireSsl          : True
    InternalClientsRequireSsl          : False
    MetabasePath                       : IIS://mx1.gb.local/W3SVC/1/ROOT/Rpc
    Path                               : C:\WINDOWS\System32\RpcProxy
    ExtendedProtectionTokenChecking    : None
    ExtendedProtectionFlags            : {}
    ExtendedProtectionSPNList          : {}
    AdminDisplayVersion                : Version 8.3 (Build 83.6)
    Server                             : MX1
    AdminDisplayName                   :
    ExchangeVersion                    : 0.1 (8.0.535.0)
    Name                               : Rpc (Default Web Site)
    DistinguishedName                  : CN=Rpc (Default Web Site),CN=HTTP,CN=Protocols,CN=MX1,CN=Servers,CN=Exchange Admin
                                         istrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=GB,CN=Microsoft Exch
                                         ange,CN=Services,CN=Configuration,DC=gb,DC=local
    Identity                           : MX1\Rpc (Default Web Site)
    Guid                               : d3494524-4b88-4642-a6c0-a8b71a55c638
    ObjectCategory                     : gb.local/Configuration/Schema/ms-Exch-Rpc-Http-Virtual-Directory
    ObjectClass                        : {top, msExchVirtualDirectory, msExchRpcHttpVirtualDirectory}
    WhenChanged                        : 03.09.2014 22:21:26
    WhenCreated                        : 11.10.2011 11:27:09
    WhenChangedUTC                     : 03.09.2014 16:21:26
    WhenCreatedUTC                     : 11.10.2011 5:27:09
    OrganizationId                     :
    OriginatingServer                  : DC2-2008-SU.gb.local
    IsValid                            : True
    ObjectState                        : Changed

    RunspaceId                         : 07494546-bdc9-49f0-9485-129b54ed605b
    ServerName                         : MX2
    SSLOffloading                      : True
    ExternalHostname                   : owa2.galanz.kz
    InternalHostname                   : owa2.galanz.kz
    ExternalClientAuthenticationMethod : Ntlm
    InternalClientAuthenticationMethod : Ntlm
    IISAuthenticationMethods           : {Ntlm}
    XropUrl                            :
    ExternalClientsRequireSsl          : True
    InternalClientsRequireSsl          : True
    MetabasePath                       : IIS://MX2.gb.local/W3SVC/1/ROOT/Rpc
    Path                               : C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\rpc
    ExtendedProtectionTokenChecking    : None
    ExtendedProtectionFlags            : {}
    ExtendedProtectionSPNList          : {}
    AdminDisplayVersion                : Version 15.0 (Build 1130.7)
    Server                             : MX2
    AdminDisplayName                   :
    ExchangeVersion                    : 0.20 (15.0.0.0)
    Name                               : Rpc (Default Web Site)
    DistinguishedName                  : CN=Rpc (Default Web Site),CN=HTTP,CN=Protocols,CN=MX2,CN=Servers,CN=Exchange Admin
                                         istrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=GB,CN=Microsoft Exch
                                         ange,CN=Services,CN=Configuration,DC=gb,DC=local
    Identity                           : MX2\Rpc (Default Web Site)
    Guid                               : 00b8f316-20cc-46d4-a45c-8675ff9046db
    ObjectCategory                     : gb.local/Configuration/Schema/ms-Exch-Rpc-Http-Virtual-Directory
    ObjectClass                        : {top, msExchVirtualDirectory, msExchRpcHttpVirtualDirectory}
    WhenChanged                        : 02.11.2016 18:34:07
    WhenCreated                        : 22.01.2016 12:11:22
    WhenChangedUTC                     : 02.11.2016 12:34:07
    WhenCreatedUTC                     : 22.01.2016 6:11:22
    OrganizationId                     :
    OriginatingServer                  : DC2-2008-SU.gb.local
    IsValid                            : True
    ObjectState                        : Changed


    3 ноября 2016 г. 3:27
  • у вас, как я вижу, два сервера, а почему разные имена хостов? owa на одном и owa2 на втором? Для внешних подключений лучше использовать не NTLM, а Basic аутентификацию.

    И еще, проверьте еще раз внешнюю зону DNS, пропишите там CNAME запись autodiscover, которая ссылается на внешнее имя хоста Exchange.


    Do not multiply entities beyond what is necessary

    3 ноября 2016 г. 5:18
  • Когда использую Basic, у пользователей начинает запрашивать пароль  все время, а на pop и imap это ни как не влияет, проблема не решается. CNAME для autodiscover в своем ДНС создал, надо еще создавать такую запись у провайдера на белый IP?

    owa- это для старого почтаря

    owa2 -для нового

    3 ноября 2016 г. 5:40
  • Похоже идей больше нет?
    3 ноября 2016 г. 11:16
  • Проблема с автодискавером похоже решил, добавив во внешний DNS провайдера CNAMЕ запись autodiscover cname мой IP, спасибо Дмитрий за подсказку! Однако проблема с постоянным запросом логина и пароля с внешки осталась, при чем под любым протоколом, хоть pop, хоть imap, хоть active sync, хоть autodiscover, при чем все так же подтягивает встроенный сертификат, а не купленный. Мне кажется именно в этом проблема. А еще не переданы транспортные роли с exchange 2007, может как раз в этом то и загвоздка? Да и роли все равно надо будет передавать. 
    4 ноября 2016 г. 4:46
  • Я Олень! Все настройки делал правильно, только исходящий порт смтп надо было ставить 587, а я ставил 25.
    • Предложено в качестве ответа Pavel_f 22 февраля 2019 г. 13:27
    4 ноября 2016 г. 9:15