none
SignedCms.CheckSignature(false) ошибка revocation function was unable to check revocation because the revocation server was offline RRS feed

  • Вопрос

  • Доброго времечка!

    Есть
    : Домен, корпоративный сервер сертификатов. Инфраструктура управления сертификатами такая: Корневой отдельный сервер (выключен) - промежуточный подчинённый сервер (выключен) - корп. сервер сертификатов (включен). Пути к спискам отзыва сертификатов доступны с любого компа. Доступ на чтение путей стоит у "Все". Пути включают ldap:, file:, http: . Ошибок на серверах нет!

    Делается : Через корпоративный веб-сайт подписывается некоторый документ. подпись посылается на сервер. Сервер (asp.net 3.5 + iss6 или iss7), расшифровывает документ и, используя SignedCms.CheckSignature(false ) проверяет подпись и сертификаты . Видимо на этапе проверки сертификатов, того, что они не отозваны, возникает исключение "The revocation function was unable to check revocation because the revocation server was offline ".

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

    ЗЫ . Если использовать SignedCms.CheckSignature(true ), то всё работает нормально, естественно. Но ведь при этом не проверяются сертификаты. Почему такое разное поведение? Может IIS, например чего-нить не хватает для доступа к спискам отзыва сертификатов?

    ЗЗЫ . В инэте кроме рекомендаций по отключению проверки списка (в коде или в ISS) отзыва ничего не нашёл.
    30 ноября 2009 г. 14:24

Все ответы

  • Дальнейшие исследования выявили следующее. Если использовать для проверки сертификатов X509Chain , то можно увидеть, что проверку не проходят все промежуточные сертификаты. Корневой сертификат проверку проходит!

    Аналогичное упоминание нашёл тут и вот тут . Но не объяснений почему так, ни (что хотелось бы) решений никаких не встретил, увы.

    Если на "проблемных" серверах просто щёлкнуть на сертификате, то вся цепочка проходит проверку. Нигде никаких ошибок и предупреждений, всё ОК.
    2 декабря 2009 г. 19:24
  • Поставьте прокси/сниффер и посмотрите все запросы на боевом сервере, где происходит ошибка и на рабочей машине XP. Наверняка в каком-нибудь сертификате или настройках сервера закрался линк куда-нибудь в интернет для, например, проверки timestamp'а - я этот пример привёл, потому что на это однажды нарвался. Подписывал код сертификатом от Verisign и 1 раз из 100 подписать не получалось из-за какой-то непонятной ошибки, гуглил - ничего не нашёл. Дезассемблировал тулу, которой подписывал .net-код, посмотрел где может возникать ошибка - тоже ничего не понял, т.к. код, где стоит вызов исключения вызывается из сотни разных мест - в общем толку от исходников никакого, дебажить нереально, т.к. ошибка возникает очень редко. Закончилось тем, что проксёй заметил, что тула лезет на какой-то сервер в интернете для верификации времени, чтобы проверить не истёк ли срок действия сертификата, наверное. И иногда этот сервер отвечал ошибкой 500 Internal error. Редко, очень редко, но вот так вот отвечал. Оказалось, что этот линк можно поправить на другой - настроил на другой timestamp-сервер и на этом успокоился. Причём позже, когда сертификат стал просроченным, достаточно было поменять дату на компьютере, чтобы им снова можно было пользоваться :) Такая вот весёлая история.

    22 января 2010 г. 9:16
  • Кроме списков CRL проверяются и списки AIA. Проверьте их доступность.

    Пользователь, под которым проверяются сертификаты имеет право выхода в сеть для проверки сертификатов? Если это пользователь Local System - то скорее всего нет. Проблема (видимо) именно в этом.

    ЗЫ: совет: измените список таким образом, чтобы первой шла проверка по http.

    • Предложено в качестве ответа Илья Воробьев 21 марта 2010 г. 16:39
    • Помечено в качестве ответа I.Vorontsov 21 марта 2010 г. 16:41
    • Снята пометка об ответе niichavo 23 марта 2010 г. 13:03
    16 февраля 2010 г. 7:36
  • Спасибо всем за советы и помощь!

    Clevelus

    Кроме списков CRL проверяются и списки AIA. Проверьте их доступность.

    Пользователь, под которым проверяются сертификаты имеет право выхода в сеть для проверки сертификатов? Если это пользователь Local System - то скорее всего нет. Проблема (видимо) именно в этом.

    ЗЫ: совет: измените список таким образом, чтобы первой шла проверка по http.

    Всё доступно. У пользователя есть все необходимые права. Проверялось и под админом домена.

    Ещё информация и наблюдения (раньше не писал, т.к. думал, что тема умерла).

    1. Код ASP.NET запускается от имени того, кто зашёл на страничку. В IIS - аутентификация Windows. В web.config:
      trust level="Full" originUrl=""
      authentication mode="Windows"
      identity impersonate="true"
    2. Попробовал на "проблемном" сервере зайти на сайт, проверить код. Т.е. на http://localhost/test.aspx (локально) . Причём открыл сайт от имени текущего пользователя (administrator), а скормил ему подпись другого доменного пользователя. Всё прошло удачно, всё проверилось, везде true. Лишний раз убеждаюсь, что работает только локально, удалённо не хочет .
    3. После этого стало удалённо работать некоторое время ! Проверил на втором "проблемном" сервере (зашёл локально, а потом удалённо). Тоже сработало. Может что-то закэшировалось?
    4. базовый CRL обновляется через 7 дней, живёт 7,5 дней, дельта обновляется через 1 день, живёт 1,5 дня. На утро уже не работало удалённо , хотя время жизни CRL ещё не подошло к концу.
    5. консольное приложение запускается на сервере также без ошибок (проверял сертификат текущего пользователя для простоты). Т.е. подтверждается то, что работает проверка сертификата только локально.

     

    23 марта 2010 г. 13:46