Немного про сертификаты… или как починить постоянный redirect owa в Exchnage


ssl

Не все знают, что мощные и современные продукты, такие, как S4B/Lync, Exchnage 2013/16, ADFS 2012R2, и даже другие продукты (например, VMware View) не поддерживают сертификаты CNG.

Screenshot_4

В Lync ошибка может быть при назначении сертификатов Error: An error occurred: “System.Security.Cryptography.CryptographicException” “The buffer supplied to a function was to small””

В TMG при назначении сертификата на листнер, можете получить ошибку “Incorrect key type”

В Exchange мы получим бесконечный редирект в OWA и ECP при использовании FBA.

Но, как показала практика, администраторы серверов и слыхом не слыхивали, что вместо FBA можно использовать SSO.

VMware Horizon View тоже откажется пускать пользователей после смены сертификата на новый, v3.

Как же проверить, все ли с сертификатом в порядке, особенно, если запрашивали его не Вы, а другой человечек, который мог что-нибудь напутать при создании CSR.

Проверяем вывод команды Certutil.exe -v -store my <thumbprint>, и берем отпечаток нашего сертификата.

Смотрим вывод строки Provider. Если вывод «Provider = Microsoft Software Key Storage Provider», то это плохо. И работать такой сертификат не будет.

Должно быть “Microsoft Enhanced Cryptographic Provider v1.0” либо “Microsoft RSA SChannel Cryptographic Provider”.

Рассмотрим варианты, как бороть проблему. Вариант первый- читать гайды по запросу сертификатов для продукта, где указывается, КАК и почему надо делать. Например, в гайдах Exchnage или Lync администратору зачем-то дают готовый шаблон, который остается скопировать в записную книжку, и администратор этой проблемы если он не боится powershell даже не увидит. Сделайте выводы, если у вас есть проблема с сертификатами, подумайте о ее первопричинах. Возможно, не во всем виноват проклятый Майкрософт, который не поддерживает в данных продуктах CNG, а использует legacy CryptoAPI, работающий на старых добрых Cryptographic Service Providers (CSP). Поэтому- просто ПРАВИЛЬНО перезапросите сертификат, используя предложенную документацию.

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

Ну, например, это не бесплатно, и это не наш метод!

Наш метод такой: Качаем openssl и экспортируем наш проблемный сертификат в pfx , либо берем готовый.

Открываем командную строку с повышенными привилегиями, переходим в каталог \openssl\bin.

Конвертируем наш .pfx в .pem
openssl.exe pkcs12 -in certificate.pfx -out certificate.pem -nodes

Затем конвертируем обратно из .pem в  .pfx
openssl.exe pkcs12 -export -in certificate.pem -out new_certificate.pfx

Cамые внимательные читатели знают, что можно использовать еще и certutil:

certutil -csp «Microsoft RSA SChannel Cryptographic Provider» -importpfx <CertificateFilename>

На сегодня все, любите powershell, читайте документацию по продуктам.

Ссылки по теме:

https://blogs.perficient.com/microsoft/2013/12/lync-support-for-cryptoaping-certificates/

https://anotherexchangeblog.wordpress.com/tag/importpfx-command-failed-0x80090029/

http://blogs.technet.com/b/jasonsla/archive/2015/01/15/the-owa-and-ecp-fba-redirect-loop.aspx

http://blog.vaglid.net/?p=4

Реклама

One thought on “Немного про сертификаты… или как починить постоянный redirect owa в Exchnage

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s