Ошибка Workflow Manager "The provided signing certificate is invalid according to its expiration claims" в SharePoint 2013. Обновляем Self-Signed сертификат для служб Service Bus и Workflow Manager

В рассматриваемой ранее процедуре развёртывания Workflow Manager 1.0 для его последующей интеграции в SharePoint Server 2013 нами была использована схема с генерацией само-подписанного сертификата, который используется для веб-сервисов Workflow Manager (WFM) и Service Bus (SB). С тех пор прошло много времени, и наш экземпляр WFM всё это время выполнял свои задачи вполне себе штатно, пока не наступил момент, когда все новые рабочие процессы дружно перестали выполняться.

Забегая вперёд, можно сказать, что это ещё одна история о том, как отсутствие проактивного мониторинга срока действия важного цифрового сертификата может в перспективе создать трудности, которые потом придётся героически преодолевать.

Началось всё с того, что на веб-узле SharePoint Server, использующем вызовы выделенного сервера WFM, мы обнаружили информацию о возникающем исключении при вызове рабочих процессов "The provided signing certificate is invalid according to its expiration claims"

Все новые рабочие процессы были не в состоянии запуститься, выдавая нам эту однотипную ошибку.

После того, как мы заглянули в свойства веб-сайта WFM, стало очевидно, что истёк 5-летний срок действия само-подписанных сертификатов, которые были установлены на этапе развёртывания WFM. И мы этот момент благополучно проморгали.

Соответственно, для решения проблемы с падающими рабочими процессами WFM в SharePoint нам потребовалось выполнить обновление сертификатов, используемых для веб-сервисов Workflow Manager и Service Bus.

В целом процедура замены сертификатов не сильно сложная и её описание можно найти в (пока ещё доступной) статье Хосе Пендана Changing my Workflow Manager Farm Certificates. Однако, в нашем случае ситуацию усугубило то обстоятельство, что установленные сертификаты уже просрочены, поэтому описанная последовательность команд просто так не заработала. В частности, при попытке выполнения командлета установки нового сертификата для службы Service Bus (Set-SBCertificate) мы получили ошибку, говорящую о том, что старый установленный сертификат не найден (хотя на самом деле он есть в личном хранилище системы, но просрочен)

Помимо этой проблемы последующие эксперименты выявили то, что новый выпущенный в доменной службе сертификации "модный" сертификат c CNG key не подойдёт, так как требуется сертификат с Legacy key, чтобы в запросе KeySpec был определён как KeyExchange (AT_KEYEXCHANGE). В общем здесь можно было озадачиться созданием кастомизированного запроса к центру сертификации, а можно пойти иным путём – с помощью PowerShell сгенерировать новый само-подписанный сертификат, скопировав все нужные характеристики из старого сертификата. Далее мы рассмотрим процедуру создания такого сертификата и установки его в службы WFM/SB с учётом того обстоятельства, что текущий сертификат уже просрочен.

Итак, первым делом нам нужно сгенерировать новый сертификат в формате, приемлемом для WFM/SB. Но для этого нам потребуется знать отпечаток (Thumbprint) текущего установленного сертификата. Узнать отпечаток можно, запустив с правами администратора на сервере WFM консоль Workflow Manager PowerShell

…и выполнив команду:

Get-SBFarm

В нашем примере старый сертификат имеет отпечаток  628B16254CB5D0259567786051CE7F0F8814DB29. От него в дальнейшем мы и будем отталкиваться.

Откат времени на сервере SB/WFM

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

Например, в нашем случае сертификат истёк 02.04.2019, поэтому мы выставляем системное время на сервере WFM на 01.04.2019.

Чтобы время автоматически заново не устанавливалось на актуальное, пока мы не закончим процедуру замены сертификатов, остановим системные службы, отвечающие за синхронизацию времени. Это, как минимум, служба Windows Time (W32Time) и, в случае, если наш сервер WFM виртуальный, служба Hyper-V Time Synchronization Service (vmictimesync).

Генерация нового Self-Signed сертификата

Изменив время, откроем с правами администратора стандартную консоль Windows PowerShell и сгенерируем новый само-подписанный сертификат, скопировав при этом все параметры старого само-подписанного сертификата:

Set-Location -Path "cert:\LocalMachine\My"
$OldCert = (Get-ChildItem -Path 628B16254CB5D0259567786051CE7F0F8814DB29)
New-SelfSignedCertificate -CloneCert $OldCert

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

После генерации сертификат попал в хранилище личных сертификатов системы, но так как он является само-подписанным, нам потребуется добавить этот же сертификат и в хранилище корневых сертификатов доверенных ЦС - Trusted Root Certification Authorities. Сделать это можно либо через графическую консоль управления сертификатами, либо здесь же с помощью PowerShell:

$NewCert = (Get-ChildItem -Path cert:\LocalMachine\My\29ADE3C88F51D1D8043D272A8DEAB3B582A682FC)
$NewCertFile = $env:temp + "\NewSelfSignedCert.cer"
Export-Certificate -Cert $NewCert -FilePath $NewCertFile
Import-Certificate -CertStoreLocation cert:\LocalMachine\Root -FilePath $NewCertFile
Remove-Item -Path $NewCertFile

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

Напоминаю, что на сервере WFM всё ещё установлена дата из прошлого, поэтому старый само-подписанный сертификат, установленный в службах WFM/SB считается ещё действующим.

Установка сертификата в службы Service Bus

Возвращаемся в консоль Workflow Manager PowerShell и пробуем установить новый само-подписанный сертификат в службы Service Bus.

Set-SBCertificate -FarmCertificateThumbprint 29ADE3C88F51D1D8043D272A8DEAB3B582A682FC -EncryptionCertificateThumbprint 29ADE3C88F51D1D8043D272A8DEAB3B582A682FC

Как видим, на этот раз установка нового сертификата прошла успешно. Теперь нужно последовательно выполнить команды остановки фермы SB, обновления хоста и повторного запуска фермы.

Stop-SBFarm
Update-SBHost
Start-SBFarm

Все команды должны отработать без ошибок и службы SB должны успешно запуститься.

Установка сертификата в службы Workflow Manager

Здесь же, в консоли Workflow Manager PowerShell  выполняем последовательно команды установки нового само-подписанного сертификата в службы Workflow Manager и их перезапуск.

Set-WFCertificate -SslCertificateThumbprint 29ADE3C88F51D1D8043D272A8DEAB3B582A682FC -EncryptionCertificateThumbprint 29ADE3C88F51D1D8043D272A8DEAB3B582A682FC
Stop-WFHost
Update-WFHost
Start-WFHost

Как видим, указанный нами сертификат успешно установлен, однако в конфигурации WFM остаётся ссылка на ещё один просроченный сертификат - Outbound Certificate. Заменить этот сертификат на новый можно последовательностью команд следующего вида:

Set-WFNextOutboundCertificateReference -ServiceURI https://KOM-WEB04.holding.com:12290/ -Thumbprint 29ADE3C88F51D1D8043D272A8DEAB3B582A682FC
Set-WFNextOutboundCertificateAsCurrent -ServiceURI https://KOM-WEB04.holding.com:12290/

Результат можно проверить командой:

Get-WFOutboundCertificate -ServiceURI https://KOM-WEB04.holding.com:12290/

На этом манипуляции на сервере SB/WFM можно считать законченными.

Теперь дату в системе можно вернуть в актуальное состояние, а также нужно не забыть о запуске ранее остановленных служб синхронизации времени, таких как Windows Time (W32Time) и Hyper-V Time Synchronization Service (vmictimesync).

Настройка на стороне SharePoint Server

На стороне сервера SharePoint Server копируем выпущенный нами новый  само-подписанный сертификат в хранилище Trusted Root Certification Authorities, чтобы система доверяла этому сертификату. Сделать это можно, как с помощью PowerShell (пример выше), так и с помощью графической консоли управления сертификатами, подключившись к хранилищу сертификатов Local Computer.

Далее открываем консоль SharePoint Management Shell и устанавливаем новый сертификат из локального хранилища Trusted Root Certification Authorities в специальное хранилище SharePoint.

$NewCert = (Get-ChildItem -Path cert:\LocalMachine\Root\29ADE3C88F51D1D8043D272A8DEAB3B582A682FC)
New-SPTrustedRootAuthority -Name "WFM-SelfSigned-2019" -Certificate $NewCert

Получить полный список хранилища доверенных корневых сертификатов в SharePoint можно командой:

Get-SPTrustedRootAuthority

После того, как сертификат установлен, командой iisreset перезагружаем IIS на всех серверах SharePoint Web Front End.

Далее, переходим на веб-узел администрирования SharePoint 2013 Central Administration и в разделе Monitoring \ Check job status находим задачу "Refresh Trusted Security Token Services Metadata feed" и запускаем его выполнение.

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

А чтобы в дальнейшем избежать ситуаций с остановкой WFM из-за просроченного сертификата, конечно-же следует озадачиться вопросом проактивного мониторинга срока действия установленных сертификатов. Но это, как говорится, уже совсем другая история.

Всего комментариев: 3 Комментировать

  1. Станислав /

    Гениально! Спасибо, всё починилось. Это какая-то чёрная магия шарепоинта!

  2. Александр /

    Огромное Вам спасибо!!!

  3. Дмитрий Михайлович Носенко /

    Спасибо!!!

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