none
Проблемы с ключами? на сервере Exchange 2016 RRS feed

  • Вопрос

  • Добрый день, засбоил Exchange, посре восстановления системы почта заработала, но при обращении с локальной машины к сайтам OWA EWS и всем остальным выдает ошибку в браузере:

    Неправильный зарегистрированный набор ключей.
    Описание: Необработанное исключение при выполнении текущего веб-запроса. Изучите трассировку стека для получения дополнительных сведений о данной ошибке и о вызвавшем ее фрагменте кода.

    Сведения об исключении: System.Runtime.InteropServices.COMException: Неправильный зарегистрированный набор ключей.


    Ошибка источника:

    Код ресурса, сгенерировавший это необработанное исключение, может быть отображен только после компиляции в режиме отладки. Для этого выполните одно из указанных ниже действий, а затем перейдите по следующему URL-адресу:

    1. Добавьте директиву "Debug=true" в начало файла, сгенерировавшего ошибку.  Пример:

      <%@ Page Language="C#" Debug="true" %>

    или:

    2) Добавьте следующий раздел в файл конфигурации приложения:

    <configuration>
       <system.web>
           <compilation debug="true"/>
       </system.web>
    </configuration>

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

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

    Трассировка стека:

    [COMException (0x8009001a): Неправильный зарегистрированный набор ключей.
    ]
       System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) +563482
       System.DirectoryServices.DirectoryEntry.Bind() +45
       System.DirectoryServices.DirectoryEntry.get_Parent() +47
       Microsoft.Exchange.Clients.Owa.Core.VdirConfiguration.GetWebSiteName(String webSiteRootPath) +71
       Microsoft.Exchange.Clients.Owa.Core.VdirConfiguration.BaseCreateInstance() +378
       Microsoft.Exchange.Clients.Owa.Core.VdirConfiguration.get_Instance() +127
       Microsoft.Exchange.HttpProxy.Logon.get_UserNamePlaceholder() +47
       ASP.auth_logon_aspx.__Render__control1(HtmlTextWriter __w, Control parameterContainer) +1446
       System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) +260
       System.Web.UI.Page.Render(HtmlTextWriter writer) +39
       System.Web.UI.Control.RenderControlInternal(HtmlTextWriter writer, ControlAdapter adapter) +79
       System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +4104
    

    Перерыл что мог, в упор не понимаю где проблема, то ли в IIS, то ли в самих файлах сайтов.

    Понятно что проблема с какими-то ключами. По данной ошибке нашел единственное тут же https://answers.microsoft.com/ru-ru/windows/forum/all/%D0%BD%D0%B5%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB/e1f7884c-ef65-4ca3-a7a0-7e06e3eeb50c

    Но там чистили папку пользователя, тут же ИИС запускается под системой, не понимаю куда копать.

    Windows server 2012 R2 STD + Exchange 2016.

    • Перемещено Vector BCO 6 сентября 2020 г. 18:42 перенесено из ветки другие серверные продукты
    6 сентября 2020 г. 17:49

Ответы

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

    При восстановлении системы вы восстанавливали закрытые ключи сертификатов (обычное их место хранения для наиболее часто используемого криптопровайдера RSA- C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys (это - скрытая папка) )?

    Для диагностики можете найти конкретный сертификат из списка установленных сертификатов в хранилище персональных компьютера (командой certutil -store -privatekey My), посмотреть имя файла-контейнера (в поле Key Container записи для сертификата в выдаче команды) и проверить наличие этого файла в указанной папке. Если файл есть, то стоит его заменить файлом из резервной копии (файл мог быть поврежден).

    Если файла ключа нет и взять неоткуда, то что делать дальше - зависит от типа сертификата: если самоподписанный - проще  сгенерить новый сертификат, если коммерческий - установить сертификат на сервер заново.


    Слава России!


    6 сентября 2020 г. 20:17

Все ответы

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

    При восстановлении системы вы восстанавливали закрытые ключи сертификатов (обычное их место хранения для наиболее часто используемого криптопровайдера RSA- C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys (это - скрытая папка) )?

    Для диагностики можете найти конкретный сертификат из списка установленных сертификатов в хранилище персональных компьютера (командой certutil -store -privatekey My), посмотреть имя файла-контейнера (в поле Key Container записи для сертификата в выдаче команды) и проверить наличие этого файла в указанной папке. Если файл есть, то стоит его заменить файлом из резервной копии (файл мог быть поврежден).

    Если файла ключа нет и взять неоткуда, то что делать дальше - зависит от типа сертификата: если самоподписанный - проще  сгенерить новый сертификат, если коммерческий - установить сертификат на сервер заново.


    Слава России!


    6 сентября 2020 г. 20:17
  • Сертификат используется не самоподписанный, полноценный wildcard, попробую переустановить сертификат, боюсь что бэкапа данной папки у меня не найдется...
    7 сентября 2020 г. 6:12
  • Скорее всего, IIS не может найти закрытый ключ для используемого им сертификата.

    При восстановлении системы вы восстанавливали закрытые ключи сертификатов (обычное их место хранения для наиболее часто используемого криптопровайдера RSA- C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys (это - скрытая папка) )?

    Для диагностики можете найти конкретный сертификат из списка установленных сертификатов в хранилище персональных компьютера (командой certutil -store -privatekey My), посмотреть имя файла-контейнера (в поле Key Container записи для сертификата в выдаче команды) и проверить наличие этого файла в указанной папке. Если файл есть, то стоит его заменить файлом из резервной копии (файл мог быть поврежден).

    Если файла ключа нет и взять неоткуда, то что делать дальше - зависит от типа сертификата: если самоподписанный - проще  сгенерить новый сертификат, если коммерческий - установить сертификат на сервер заново.


    Слава России!


    Проблема действительно была с ключами из этой папки. При восстановлении из бэкапа, система их не подменила из-за отсутствия разрешения в конечной папке. После замены валидными файлами все заработало, Спасибо!

    7 сентября 2020 г. 7:21
  • Если у коммерческого центра выпускали, то попросите вам его ещё раз прислать с закрытым ключом (или скачайте из личного кабинета), если со своего центра, то можно просто его перевыпустить.
    7 сентября 2020 г. 7:22