Contents of this directory is archived and no longer updated.

Я предлагаю снова поговорить о certificate chaining engine, о котором мы уже говорили в посте Certificate Chaining Engine — как это работает но в рамках его реализации в .NET и PowerShell. В Windows есть несколько реализаций этого chaining engine. Самые популярные:

CAPICOM — вещь несколько стрёмная и её лучше избегать. Тем более мне не удалось завести его в Vista/Windows 7. Реализация в .NET в виде X509Chain ничуть не хуже, но, в то же время, проще. Итак, предлагаю начать с создания этого объекта с помощью New-Object:

[↓] [vPodans] $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
[↓] [vPodans] $chain

                 ChainContext ChainPolicy                   ChainStatus                   ChainElements
                 ------------ -----------                   -----------                   -------------
                            0 System.Security.Cryptograp... {}                            {}


[↓] [vPodans] $chain | gm -membertype methods


   TypeName: System.Security.Cryptography.X509Certificates.X509Chain

Name        MemberType Definition
----        ---------- ----------
Build       Method     bool Build(System.Security.Cryptography.X509Certificates.X509Certificate2 certificate)
Equals      Method     bool Equals(System.Object obj)
GetHashCode Method     int GetHashCode()
GetType     Method     type GetType()
Reset       Method     System.Void Reset()
ToString    Method     string ToString()


[↓] [vPodans]

Здесь видно, что метод, который будет строить и проверять цепочку будет называться Build() и в качестве аргумента этот метод принимает только объекты x509Certificate2, а возвращать объект типа Boolean — True/False. Объекты такого типа можно найти в провайдере Certififcates (просто выполнить dir cert:\store\container) или импортировать из файла — Импорт сертификатов в PowerShell. Но сначала мы посмотрим, что здесь можнол настроить. А настроить можно ChainPolicy, представляющий собой объект X509ChainPolicy. Эта политика позволяет задавать порядок проверки отзыва сертификатов, соответствие сертификата каким-то certificate policy, наличие определённых application policy (в прошлом известен нам как EKUExtended Key Usage) и некритичность каких-то ошибок. Мы всё разбирать не будем, а только основное:

[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : ExcludeRoot
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans]

Первое, что может быть интересным — Revocation Mode, который задаёт режим проверки отзыва и может иметь 3 вполне понятных значения, которые перечислены в X509RevocationMode:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509revocationmode])
NoCheck
Online
Offline

Тут очень просто:

  • NoCheck — проверяет цепочку сертификатов без проверки на отзыв любых сертификатов в цепочке;
  • Online — проверяет сертификаты в цепочке скачивая новые списки CRL из свойства CDP сертификата, игнорируя локальный кеш CRL (используется по умолчанию, как это видно в просмотре свойств ChainPolicy)
  • Offline — проверяет сертификаты на отзыв с использованием кешированного CRL (если есть).

Если проверяем сертификаты на отзыв, то мы можем выбрать что именно будем проверять и этот выбор перечислен в X509RevocationFlag:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509revocationflag])
EndCertificateOnly
EntireChain
ExcludeRoot

и здесь тоже всё достаточно понятно:

  • EndCertificateOnly — проверяет на отзыв только сам проверяемый сертификат. Остальные сертификаты в цепочке не проверяются;
  • EntireChain — проверяет на отзыв абсолютно все сертификаты в цепочке включая корневой сертификат. Правила хорошего тона диктуют нам не включать в корневой сертификат CA поля CDP и AIA, поскольку это лишено смысла и в большинстве случаев с этим флагом вы будете получать невалидную цепочку;
  • ExcludeRoot — проверяет на отзыв все сертификаты в цепочке, кроме корневого сертификата, что есть религионзно правильно и этот флаг установлен по умолчанию.

Следующий момент определяет флаги проверки, т.е. по каким именно критериям будет проверяться цепочка сертификатов:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509verificationflags])
NoFlag
IgnoreNotTimeValid
IgnoreCtlNotTimeValid
IgnoreNotTimeNested
IgnoreInvalidBasicConstraints
AllowUnknownCertificateAuthority
IgnoreWrongUsage
IgnoreInvalidName
IgnoreInvalidPolicy
IgnoreEndRevocationUnknown
IgnoreCtlSignerRevocationUnknown
IgnoreCertificateAuthorityRevocationUnknown
IgnoreRootRevocationUnknown
AllFlags

Эти флаги так же достаточно понятны и подробно разжёваны в перечислении X509VerificationFlags.

Примечание: эти флаги показывают что будет исключено из проверки, а не наоборот. По умолчанию проверяется всё (установлен NoFlag).

Как можно задавать эти флаги и режимы, если есть такая потребность? Можно пойти двумя способами — правильным и неправильным, хотя оба рабочие:

[↓] [vPodans] # правильный метод:
[↓] [vPodans] $revflag = [System.Security.Cryptography.X509Certificates.X509RevocationFlag]::EndCertificateOnly
[↓] [vPodans] $chain.ChainPolicy.RevocationFlag = $revflag
[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : EndCertificateOnly
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans] # неправильный метод, но мне он нравится
[↓] [vPodans] $chain.ChainPolicy.RevocationFlag = "excluderoot"
[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : ExcludeRoot
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans]

В принципе, все эти enumeration можно просто указывать в виде строки, а PowerShell уже сам подобъёт его под нужный тип.

Примечание: флаги проверки на отзыв можно указывать только по одному, а флаги исключений можно перечислять через запятую. Это видно по названию класса: если класс указан в единственном числе (X509RevocationFlag), то и значение можно указать только одно, а если во множественном числе (X509VerificationFlags), то их можно указать несколько через запятую.

В принципе, можно делать проверку:

[↓] [vPodans] $valid = (dir cert:\currentuser\my)[1]
[↓] [vPodans] $invalid = (dir cert:\currentuser\my)[0]
[↓] [vPodans] $chain.Build($valid)
True
[↓] [vPodans] $chain.ChainElements | select -expand certificate

Thumbprint                                Subject
----------                                -------
986D375362652FE9E39BA4D042A6B8BA75745998  CN=Administrator, CN=Users, DC=sysadmins, DC=lv
E82ACC45841280DDEAB9F7847418FA26354457A7  CN=sysadmins-LV-CA, DC=sysadmins, DC=lv


[↓] [vPodans]

Я из локального хранилища взял заведомо хороший сертификат и плохой (разумеется, это сертификат с сайта БиЛайн :-)). Метод Build() вернул True, что означает успешную проверку всей цепочки моего сертификата до доверенного корня. А вот что случилось с сертификатом билайна:

[↓] [vPodans] $chain.reset()
[↓] [vPodans] $chain.Build($invalid)
False
[↓] [vPodans] $chain.ChainElements | select -expand certificate

Thumbprint                                Subject
----------                                -------
EB74DA32E865C78FCB853DDA5FE45962098E1B3B  CN=trust.beeline.ru, OU=DIT, O=Vimpelcom, L=Moscow, S=Moscow, C=RU


[↓] [vPodans] $chain.ChainStatus

                                                     Status StatusInformation
                                                     ------ -----------------
                                               PartialChain Sertificesanas kedi nevareja veidot pie uzticamas saknes...
                                    RevocationStatusUnknown Atsauksanas funkcija nevareja parbaudit sertifikata atsa...
                                          OfflineRevocation Atsauksanas funkcija nevareja parbaudit atsauksanu, jo a...


[↓] [vPodans] $chain.ChainStatus | %{$_.statusinformation.trim()}
Sertificesanas kedi nevareja veidot pie uzticamas saknes iestades.
Atsauksanas funkcija nevareja parbaudit sertifikata atsauksanu.
Atsauksanas funkcija nevareja parbaudit atsauksanu, jo atsauksanas serveris bija bezsaiste.
[↓] [vPodans]

Поскольку при каждой проверке сертификаты в ChainElements накапливаются, то после каждой проверки следует очищать объект методом Reset(). Как и следовало ожидать, сертификат билайна вернул False, показывая, что цепочка у этого сертификата имеет проблемы. В случае неуспешной проверки, будет заполняться свойство ChainStatus. Данное свойство содержит все ошибки, которые были костатированы при проверке цепочки. Для меня пока непонятным стал факт, что ошибки он написал на латышском языке, хотя я его об этом не просил. Откуда он это взял — непонятно, но он сказал, что не смог построить цепочку до доверенного корня и функция проверки отзыва провалилась по всем статьям, поскольку пути в CDP сертификата нерабочие.

Примечание: обязательно следует учитывать тот факт, что при построении цепочки сертификатов и проверке доверия класс X509Chain в Windows 7 и Windows Server 2008 R2 работает в контексте LocalSystem и всегда игнорирует пользовательские контейнеры Trusted Root Certification Authorities. Поэтому если корень цепочки не заканчивается на одном из сертификатов Trusted Root CAs хранилища LocalMachine, то цепочка будет считаться недоверенной. Для предыдущих ОС цепочка может заканчиваться на пользовательском хранилище Current User.

В принципе это всё, что вам следует знать про реализацию certificate chaining engine в .NET и его использование в PowerShell. В качестве бонуса прилагаю скрипт для проверки цепочки сертификатов:

#####################################################################
# Test-Certificate.ps1
# Version 1.0
#
# Passes certificate through certificate chaining engine
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################
#requires –Version 2.0

function Test-Certificate {
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 0)]
        $Certificate,
        [System.Security.SecureString]$Password,
        [ValidateSet("NoCheck", "Online", "Offline")]
        [string]$CRLMode = "Online",
        [ValidateSet("EndCertificateOnly", "EntireChain", "ExcludeRoot")]
        [string]$CRLFlag = "ExcludeRoot",
        [ValidateSet("AllFlags", "AllowUnknownCertificateAuthority", "NoFlag", "IgnoreNotTimeValid",
            "IgnoreCtlNotTimeValid", "IgnoreNotTimeNested", "IgnoreInvalidBasicConstraints",
            "IgnoreWrongUsage", "IgnoreInvalidName", "IgnoreInvalidPolicy", "IgnoreEndRevocationUnknown",
            "IgnoreCtlSignerRevocationUnknown", "IgnoreCertificateAuthorityRevocationUnknown",
            "IgnoreRootRevocationUnknown")]
        [string[]]$VerificationFlags = "NoFlag"
    )
    
    begin {
        # создаём объекты X509Certificate2 и X509chain ещё до поступлениея первого объекта сертификата
        $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
        $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
        # в X509Chain записываем параметры проверки сертификатов. Как критерии
        # отзыва, так и исключения из проверки
        $chain.ChainPolicy.RevocationFlag = $CRLFlag
        $chain.ChainPolicy.RevocationMode = $CRLMode
        $chain.ChainPolicy.VerificationFlags = $VerificationFlags
        # мини-функция для предоставления понятного вывода на экран о статусе проверки
        # и ошибках в цепочке, если они есть.
        function _getstatus_ ($status, $chain, $cert) {
            if ($status) {
                Write-Host Current certificate $cert.SerialNumber chain and revocation status is valid -ForegroundColor Green
            } else {
                Write-Warning "Current certificate $($cert.SerialNumber) chain is invalid due of the following errors:"
                $chain.ChainStatus | %{Write-Host $_.StatusInformation.trim() -ForegroundColor Red}
            }
        }
    }
    
    process {
        # если аргумент сертификата уже является объектом X509Certificate2, то
        # сразу строим цепочку и получаем статус цепочки вызывая мини-функцию
        if ($_ -is [System.Security.Cryptography.X509Certificates.X509Certificate2]) {
            $status = $chain.Build($_)
            _getstatus_ $status $chain $_
        } else {
        # если аргумент не является объектом X509Certificate2, то это будет путь к файлу
        # если указанный путь не существует, то ругаемся и выходим
            if (!(Test-Path $Certificate)) {Write-Warning "Specified path is invalid"; return}
            else {
            # если путь существует, то проверяем, что это путь файловой системы.
            # если это не так, то ругаемся и выходим
                if ((Resolve-Path $Certificate).Provider.Name -ne "FileSystem") {
                    Write-Warning "Spicifed path is not recognized as filesystem path. Try again"; return
                } else {
                # если предварительные проверки прошли успешно, то выбираем объект файла
                    $Certificate = gi $(Resolve-Path $Certificate)
                # и на основании расширения файла через Switch преобразуем файл в
                # X509Certificate2 объект или объекты
                    switch -regex ($Certificate.Extension) {
                    "\.CER|\.DER|\.CRT" {$cert.Import($Certificate.FullName)}
                    "\.PFX" {
                        if (!$Password) {$Password = Read-Host "Enter password for PFX file $certificate" -AsSecureString}
                        # тут пришлось указать контекст хранилища, куда предполагается сохранить сертификат.
                        # на самом деле мы никуда не будем сохранять объект сертификата, это было сделано
                        # по причине отсутствия подходящего конструктора метода Import(), чтобы
                        # можно было указать только путь к файлу и пароль от PFX
                            $cert.Import($Certificate.FullName, $password, "UserKeySet")
                        }
                    "\.P7B|\.SST" {
                        $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
                        $cert.Import([system.IO.File]::ReadAllBytes($file.FullName))
                        }
                    default {Write-Warning "Looks like your specified file is not a certificate file"; return}
                    }
                    # полученный объект или объекты сертификатов пропускаем через метод Build() и вызываем
                    # мини-функцию расшифровки статуса проверки
                    $cert | %{
                        $status = $chain.Build($_)
                        _getstatus_ $status $chain $_
                    }
                    # после каждой итерации очищаем объекты сертификата и цепочки
                    $cert.Reset()
                    $chain.Reset()
                }
            }
        }
    }
}

Данный скрипт может принимать аргументы в виде уже готовых объектов X509Certificate2 или с указанием пути к файлу сертификата, например:

dir cert:\currentuser\my | Test-Certificate
Test-Certificate .\mycert.cer

Ну и при желании можно поуказывать там разные параметры и флаги проверки.


Share this article:

Comments:

niichavo

Здравствуйте! Столкнулся вот с какой проблемой. В кратце: Через корпоративный веб-сайт подписывается некоторый документ (используется ActiveX CAPICOM). подпись посылается на сервер. Сервер (asp.net 3.5 + iss6 или iss7), расшифровывает документ и, используя SignedCms.CheckSignature(false) проверяет подпись и сертификаты . Видимо на этапе проверки сертификатов, того, что они не отозваны, возникает исключение "The revocation function was unable to check revocation because the revocation server was offline" Если использовать для проверки сертификатов X509Chain, то можно увидеть, что проверку не проходят все промежуточные сертификаты. Корневой сертификат проверку проходит. У корневого сертификата отсутствует CDP и AIA. "Игра" с X509RevocationMode, X509RevocationFlag, X509VerificationFlags ничего в положительную сторону не изменила. Буду очень признателен за ответ/помощь! ЗЫ. вот немного подробнее о проблеме: http://social.msdn.microsoft.com/Forums/ru-RU/securityru/thread/8dcb2a3b-2197-453f-bc98-fb5739135e3b

niichavo

Один важный момент! Если тестить код в Visual Studio 2008 prof на админском компе с XP SP3, то всё нормуль. И SignedCms.CheckSignature(false) корректно отрабатывает, не вызывая исключения и у X509Chain везде true. Но если поместить код на сервер (2003 + iis6 или 2008 + iss7), то возникает проблема проверки. ПОЧЕМУ? Ведь доступ к спискам отзыва есть с любого сервера/компутера домена? На сервере, если кликнуть на сертификат сервера, например, то вся цепочка проходит проверку. Нигде никаких ошибок и предупреждений. "всё ОК" написано.

Vadims Podāns

когда вы просто открываете сертификат и смотрите путь сертификации, то вы видите только цепочку сертификатов. В данном случае проверка на отзыв НЕ производится. Если все сертификаты показывают Ok, то это значит только то, что цепочка строится до доверенного корня. Это важный момент, поскольку проверка на отзыв вообще не производится на недоверенном участке цепочки и она в Revocation Status пишет failed. Поэтому для выяснения конкретной причины нужно сделать: 1) скачать в виде файлов каждый сертификат цепочки (кроме корневого сертификата CA); 2) проверьте поле CDP каждого сертификата и убедитесь что как минимум по первой сслыке CRL скачивается. 3) каждый файл проверить на отзыв с командой строки: certutil -url path\file.cer Причём имейте ввиду, что скорее всего ваше приложение работает с системной учётной записью и она должна иметь возможность скачивать CRL файлы. Поэтому если вы используете прокси или фаерволы, то должны разрешить этой учётной записи ходить по указанным в CDP ссылкам. Это довольно распространённая ошибка, что пользователь может скачивать файлы, а LocalSystem, к примеру, не может и тогда получаются такие казусы, что тут работает, а тут уже нет.

niichavo

в том то и дело, что 1, 2, 3 проходят нормально. CRL скачивается. Утилита ошибок не выдаёт. [Только на одном сервере с win 2008 почему-то доступны только ссылки с ldap: (стоят первыми) а для file: - fail. Если кликнуть на эту ссылку, то появляется ошибка "request is not supported. 0x80070032 (WIN32:50)". Хотя физически зайти можно. Доступ на чтение есть у "Everyone". На 2003 сервере и XP всё проходит без ошибок. все ссылки доступны] Что касается приложение. То это ASP.NET. Аутентификация Windows, т.е. код на сервере запускается от имени открывающего сайт. Всё происходит внутри сети (все комы в домене), где отключены фаерволы. Как уже писал на папки, где лежат crl и crt доступ на чтение стоит для "Все" в том числе.

niichavo

Если запустить на серверах "certutil -verify -urlfetch \\ca-server\cdp\user.cer" (или вместо user.cer проверить сертификат какого-нить CA) то проверка заканчивается успешно "Leaf certificate revocation check passed". По цепочке идёт "verified" (только у сервера 2008 - failed, где проверяется file:)

Vadims Podāns

> Только на одном сервере с win 2008 почему-то доступны только ссылки с ldap: (стоят первыми) а для file: - fail. да, всё правильно, поскольку ссылки вида file:// более не поддержиаваются в Windows Vista SP1 и Windows Server 2008 RTM для скачивания файлов сертификатов и CRL. > То это ASP.NET. Аутентификация Windows, т.е. код на сервере запускается от имени открывающего сайт нет, приложение работает от имени той учётной записи, которая настроена в IIS. и на всякий случай проверьте, что корневой сертификат CA уставновлен на сервере IIS в Local Machine store.

niichavo

> нет, приложение работает от имени той учётной записи, которая настроена в IIS. Странно. У меня в IIS - аутентификация Windows. В web.config: trust level="Full" originUrl="" authentication mode="Windows" identity impersonate="true" [ошибка если постишь с < />] Да и довольно много кода работает (или не работает), в зависимости от того, есть на то права у авторизовавшегося или их нет. Например изменение ACL у папок/файлов/принтеров, изменение/перемещение/создание учёток в AD и т.д. и т.п. Или я всё-таки ошибаюсь? И всё дело именно в этом? Вот тут http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98275&wa=wsignin1.0 описывали похожую ситуацию. Правда давно это было > и на всякий случай проверьте, что корневой сертификат CA уставновлен на сервере IIS в Local Machine store. Корневой сертификат распространяется через групповые политики. Смотрел, есть.

Vadims Podāns

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

niichavo

> Но подпись проверяется не от той учётной записи, которая работает с вашим приложением Хм, я думал (не безосновательно, как мне кажется), что от чьего имени выполняется/запускается код, от этого же имени код и работает. И раз есть в коде проверка подписи и/или сертификата, то она выполняется от имени запустившего приложение. Если у пользователя недостаточно прав для выполнения какого-то участка кода, то вызывается исключение как правило. > Не могли бы вы мне отправить на почту какой-нибудь проблемный сертификат? Проблемных как-бы нет :) . Все они рабочие. Можно подписывать, шифровать... Расшифровка того что подписано проходит успешно. Проверка сертификатов тоже работает, _НО_ не в моём коде, если его выполнять на IIS на серере :) . Вам нужен пользовательский сертификат, например? Или сертификат CA, который выдаёт сертификаты пользователям?

niichavo

Что интересно, консольное приложение (взято с msdn), запускается на сервере также без ошибок. Правда, проверяет сертификат текущего пользователя. Практически идентичный код, который и выдаёт ошибки проверки сертификатов, я использовал в ASP.NET. Выслал на мыло.

Vadims Podāns

> что от чьего имени выполняется/запускается код, от этого же имени код и работает на веб-приложения это не распространяется. Само по себе приложение запущено от учётной записи, которая прописана в IIS. Т.е. попробуйте запустить ваше ASP приложение от другой учётной записи. > Вам нужен пользовательский сертификат, например? да. Но можете прислать оба. Пока что я склоняюсь к мнению, что у вас просто проблема где-то на уровне прав. Но сначала нужно убедиться, что сертификаты сконфигурированы.

niichavo

> Само по себе приложение запущено от учётной записи, которая прописана в IIS Где прописана? Не пойму. У меня в IIS стоит Windows, в ASP.NET тоже Windows. > Т.е. попробуйте запустить ваше ASP приложение от другой учётной записи. :) Хорошо, Как это сделать? ... Запускал IE от имени админа домена и от обычного пользователя. Различий в поведении нет. При проверке CRL ошибка. Если её игнорировать - то всё ок, подписываем, расшифровываем. Ещё я могу программно заменить пользователя на время выполнения куска какого-нибудь кода. Только для данной ситуации не вижу для этого смысла. Прав хватает не только у админа, но и у рядового. ЗЫ. выслал пользовательский сертификат

niichavo

Сейчас вот попробовал на "проблемном" сервере зайти на сайт, проверить код. Т.е. на http://localhost/test.aspx . Причём открыл сайт от имени текущего пользователя (administrator), а скормил ему подпись другого доменного пользователя. Всё прошло удачно, всё проверилось, везде true. Лишний раз убеждаюсь, что работает только локально, удалённо не хочет.

Vadims Podāns

Ага! Значит, когда вы заходите на веб-страничку с самого сервера, то всё работает? А если пользователь заходит удалённо, то уже не работает, так?

niichavo

> Ага! Значит, когда вы заходите на веб-страничку с самого сервера, то всё работает? А если пользователь заходит удалённо, то уже не работает, так? Я даже больше скажу! Теперь, после того как зашёл на веб-страничку с самого сервера, уже и удалённо работает! Проверил на втором "проблемном" сервере (зашёл локально, а потом удалённо). Тоже сработало. Мистика! Может что-то закэшировалось? Пользователь другой, на страничке высвечивается его имя, не тот под которым я открывал страничку с самого веб-сервера. Надолго-ли хватит? :)

Vadims Podāns

Это зависит от того, какой RevocationMode используется в методе CheckSignature() у класса SignedCms. Если Offline, то вы запустив приложение локально, позволили ему скачать и закешировать CRL'ы. И когда срок действия CRL истечёт, то вы снова получите проблему. В таком случае я подозреваю, что учётной записи веб-сервера придётся включать галочку Enable this computer trusted for delegation в свойствах учётной записи компьютера в AD и проверять снова. Если signedcms использует RevocationMode = Online, то это мог быть и просто глюк какой-то. Хотя, думается мне, проблема к вам вернётся и придётся включать делегирования для этого компьютера. Вобщем, посмотрите сколько живут ваши CRL, подождите это время и посмотрите, как веб-приложение себя поведёт после истечения срока действия CRL.

niichavo

базовый CRL обновляется через 7 дней, живёт 7,5 дней дельта обновляется через 1 день, живёт 1,5 дня. Однако утром уже не работало, хотя время жизни ещё не подошло к концу. Буду разбираться с делегированием.

niichavo

Вообще-то эти серверы контроллеры домена. И у них и так стоит "trust this computer for delegation to any services (Kerberos only)"

Comments are closed.