Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

Установка SSL сертификата Exchange 2019.

https://letsencrypt.org/

с помощью acme клиента получаем сертификат *.pfx (мы используем его в ручном режиме Manual и клиент автоматически не подтверждает доменное имя на который выпускается сертификат и оно должно проверяться снаружи, а также он не устанавливает сертификат автоматически).

Чуть подробнее про обновление (или выпуск) сертификата:

Запустим клиента.

Manage renewals (A)

Видим, что один (в нашем случае №2) сертификат due now, то есть готов к обновлению.

Выбираем его:

Выбираем наше действие (R):

Здесь нам говорят, что надо подтвердить домен методом dns-01 вручную и показывает, что нам надо сделать:

Authorizing sso(mail).yourdomain.ru using dns-01 validation (Manual)

А именно, добавить указанную запись TXT (на внешнем dns сервере):  _acme-challenge.sso

В поле Text вставляем содержимое нашего черного окошка из поля content (я вставил без кавычек).

Выгружаем зону.

До нас изменения могут приходить долго, поэтому все равно его проверяем в acme, acme снаружи проверит это достаточно скоро.

Удаляем ранее созданную запись во внешнем DNS.

И нажимаем Enter

Как мы видим Renewals success

Посмотрим информацию про сертификат.

В папке у нас он тоже появился:

Устанавливаем его в локальное хранилище сервера Exchange (если нод несколько, то на все ноды):

Импортируем его себе в ЛИЧНОЕ ХРАНИЛИЩЕ СЕРТИФИКАТОВ СЕРВЕРА.

Здесь потребуется пароль от закрытого ключа.

Запустим клиента.

Manage renewals (A)

D: Show details for *all* renewals

Нас интересует поле .pfx password (и в последствии нужен будет Thumbprint, его тоже надо будет запомнить или записать).

Копируем пароль и вставляем в нужное нам окно.

После этого на сервере Exchange запускаем certmgr, и здесь у нас появляется наш сертификат и сертификат промежуточный издающего центра.

Далее, необходимо поставить его на сервер Exchange.

https://docs.microsoft.com/ru-ru/powershell/module/exchange/enable-exchangecertificate?view=exchange-ps

https://gist.github.com/Kimanibob/5531884

Enable-ExchangeCertificate -Thumbprint 5113ae0233a72fccb75b1d0198628675333d010e -Services POP,IMAP,SMTP,IIS

(SMTP мы его не ставим, у нас тут самоподписный сертификат Exchange), поэтому вот так

Enable-ExchangeCertificate -Thumbprint 5113ae0233a72fccb75b1d0198628675333d010e -Services POP,IMAP,IIS

Thumbprint отпечаток, берем из wacs.exe, который открывали ранее:

Версия о том, что после этого обязательно надо «ребутнуть» IIS, пока остается не подтвержденной:

Далее, у нас должен появится наш новый сертификат вот здесь:

Можно посмотреть его свойства:

Старый сертификат можно удалить прям из графической оболочки.

Посмотреть  действующий сертификат:

https://docs.microsoft.com/ru-ru/powershell/module/exchange/get-exchangecertificate?view=exchange-ps

Get-ExchangeCertificate | Format-List

Get-ExchangeCertificate | select Thumbprint, Services, NotAfter, Subject, CertificateDomains

Get-ExchangeCertificate | select Thumbprint, Services, NotAfter, Subject, CertificateDomains | where {$_.Services -match «SMTP»} | fl

На вторую ноду перетаскиваем pfx, также импортируем в ЛОКАЛЬНОЕ ХРАНИЛИЩЕ СЕРТИФИКАТОВ НЕ ПОЛЬЗОВАТЕЛЯ, А СЕРВЕРА

И делаем тоже самое:

Enable-ExchangeCertificate -Thumbprint 5113ae0233a72fccb75b1d0198628675333d010e -Services POP,IMAP,SMTP,IIS

В итоге, видим сертификаты на обоих нодах. На этом все.

Выше рассмотрен вариант установки сертификата в готовом pfx формате.

А вот в случае если сертификат и закрытый ключ мы получаем отдельными файлами,

Мы попробовали просто импортировать сертификат *.crt, оснастка Эксченжда ECP его успешно приняла, но в списке сертификатов Эксченджа он не появился.

Оказалось, что для импорта этой пары в Эксчендж их  необходимо упаковать в контейнер формата PKCS#12 (расширение .pfx).

Онлайн утилитам я бы такое доверять наверно не стоит, здесь лучше опять же использовать openssl. Конвертируем пару закрытый ключ+сертификат в контейнер командой

openssl pkcs12 -export -out output-cert-name.pfx -inkey key-file-name.key -in input-cert-name.crt

на запрос пароля вводим новый пароль создаваемого контейнера.

Далее импортируем результат в Эксчендж :

Import-ExchangeCertificate -Server EX2019-01 -FileName «\\Server-Name\Share-Name\output-cert-name.pfx» -Password (ConvertTo-SecureString -String ‘Your-Password‘ -AsPlainText -Force)

если предварительно попробовать импортировать голый сертификат в консоль Эксча, то вывалится ошибка:

Не удается импортировать сертификат. Сертификат с отпечатком 12312312301178A455F7852D6519464123123123 уже существует.

однако сертификата с таким отпечатком в Эксче нет:

get-exchangecertificate -Thumbprint 12312312301178A455F7852D6519464123123123

 

На сервере ******* возникает характерная для Rpc ошибка: Сертификат с отпечатком 12312312301178A455F7852D6519464123123123 не найден.
Проблема исправляется: запуском mmc сертификаты компьютера, и ручным удалением ранее импортированного сертификата (того который без закрытого ключа). После этого контейнер успешно импортируется.

Для информации: https://www.petenetlive.com/KB/Article/0001528

Всем хорошей работы!!!

22.07.2020 Posted by | ms exchange 2019 | Комментарии к записи Установка SSL сертификата Exchange 2019. отключены

Exchange 2019. Troubleshooting.

Наш проект внедрения Office 365 продолжается.

Недавно получили от нашей иностранной группы поддержки Office365, что мы (точнее наше доменное имя) вроде как, авторизовано у них в домене Office365.

Не просто нам это далось, вроде уже хорошо, но спустя час-полтора, начали происходить странные события:

Outlook стал вылетать с окошком авторизации (при том у всех пользователей), в то время, как OWA и мобильные клиенты, благополучно у всех работали:

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

Первым делом подозрения пали на контроллеры, но все проверив, они были исключены из подозрения.

Решили посмотреть куда «стучится» Outlook (зажимаем Ctrl+Значек Outlook  в трее- Проверить Автонастройку)

https://docs.microsoft.com/ru-ru/outlook/troubleshoot/domain-management/unexpected-autodiscover-behavior

Оказалось, что стучится теперь не туда, куда нам надо:

В цепочке появилась ссылка:

И «отлуп» с авторизацией по ней.

Вероятно, необходимо править Autodiscover…

Пара полезных ссылок на эту тему:

https://docs.microsoft.com/ru-ru/exchange/architecture/client-access/autodiscover?view=exchserver-2019

https://blog.bissquit.com/mail-servers/exchange-server/virtualnyj-katalog-autodiscover/

Временно придется прибегнуть вот к этому решению, «навесить» политику по изменению реестра через GPO:

Direct Connect to Office 365

После применения политики на компах, авторизация благополучно исчезла, ровно так как и появилась ранее:

На ноутах, которые не в домене, пришлось запустить файл реестра руками:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
«ExcludeExplicitO365Endpoint»=dword:00000001

В конце своего поста хотел бы поблагодарить коллег : Алексея, Станислава и Андрея за совместный траблешутинг.

Всем хорошей работы!!!

10.06.2020 Posted by | ms exchange 2019 | Комментарии к записи Exchange 2019. Troubleshooting. отключены

Защищено: Exchange 2019. DAG. (part 5).

Это содержимое защищено паролем. Для его просмотра введите, пожалуйста, пароль:

12.05.2020 Posted by | ms exchange 2019 | Комментарии к записи Защищено: Exchange 2019. DAG. (part 5). отключены