none
Ошибка Unable to Download в Enterprise PKI при проверке DeltaCRL RRS feed

  • Вопрос

  • На установленном Выпускающем Центре Сертификации при загрузке точки CRL возникает ошибка при проверке DeltaCRL "Unable to Download".

    Строка с этой ошибкой:

    DeltaCRL Location -- Unable to Download -- ... -- http://exapmle.domain.com/certenroll/ICA.crl

    Проблем с остальными CDP и AIA-точками нет: все они ссылаются либо на AD, либо на http://exapmle.domain.com/certenroll/*.сrl (*.crt)

    Веб-сервер example.domain.com - веб-сервер Apache на Debian. Файлы .crl имеются (есть и ICA.crl, и ICA+.crl), права на чтение даны всем, из браузера все файлы скачиваются.

    В чем может быть проблема? Можете дать ссылку на описание процесса проверки этих точек в Enterprise PKI?

    27 января 2015 г. 13:10

Все ответы

  • Проблема в отображении значка "+" в пути DeltaCRL, и решение дано в этом обсуждении:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/4af09248-9d52-4c99-8e0c-de1a06cba8e9/delta-crl-unable-to-download

    27 января 2015 г. 14:01
    Модератор
  • Да, но это веб-сервер Apache на Debian.
    Опишу точнее схему:
    1. Выпускающий ЦС в домене domain1 и имеет полное имя issca.domain1
    2. Веб-сервер Apache - независимый от выпускающего ЦС в домене domain2 - capoint.domain2

    Или данную настройку нужно проводить на IIS сервера Выпускающего ЦС независимо от того, что точки CDP указывают на файлы crl на Apache?
    (Т.е. то, что Вы написали: "Проблема в отображении значка + в пути DeltaCRL" - это проблема IIS на сервере выпускающего ЦС, а не проблема Apache)
    27 января 2015 г. 20:15
  • Согласен, что решение в данном случае неприменимо, но причина, все равно, на мой взгляд, в употреблении символа "+". Если знак "+" непосредственно, а не в виде %2B присутствует в HTTP-запросе, то он может интерпретироваться как пробел. Подробнее см. обсуждение

    http://stackoverflow.com/questions/15384828/can-apache-handle-plus-sign-for-space-in-url

    27 января 2015 г. 22:20
    Модератор
  • Согласен, что решение в данном случае неприменимо, но причина, все равно, на мой взгляд, в употреблении символа "+". Если знак "+" непосредственно, а не в виде %2B присутствует в HTTP-запросе, то он может интерпретироваться как пробел. Подробнее см. обсуждение

    http://stackoverflow.com/questions/15384828/can-apache-handle-plus-sign-for-space-in-url

    В первом вашем ответе речь шла о настройке не собственно веб-сервера, а его защиты (некогда она называлась URLScan и ставилась отдельно), конкретно - защиты от маскировки вредоносного кода двойной подстановкой. Если аналогичная защита в данном конкретном экземпляре Apache - это надо выяснять отдельно.

    И вообще, по моему мнению, полезно проанализировать журнал веб-сервера на предмет того, в каком виде он воспринимает URL, да и на сам передаваемый "по проводам" URL в заголовке запроса HTTP неплохо было бы посмотреть сниффером. После этого можно уже искать, что и как донастраивать в Apache.


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

    28 января 2015 г. 9:31
  • вот снял лог c  apache:

    При запросе из браузера (IE8) в малом регистре (ica+.crl) в логе регистрируется две записи:
    ...15:15:54 +0300] "GET /certenroll/ica+.crl HTTP/1.0" 301 588 "-" "Mozilla/4.0 (compatible; MSIE 8.0...)
    ...15:15:54 +0300] "GET /certenroll/ICA+.crl HTTP/1.0" 200 1030 "-" "Mozilla/4.0 (compatible; MSIE 8.0...)
    А при запросе из IE8 в верхнем регистре (ICA+.crl) одна запись:
    ...15:21:10 +0300] "GET /certenroll/ICA+.crl HTTP/1.0" 200 1031 "-" "Mozilla/4.0 (compatible; MSIE 8.0...)

    При запросе из Firefox:
    Запрос в регистре ica+.crl:
    ...15:22:26 +0300] "GET /certenroll/ICA+.crl HTTP/1.0" 200 1031 "-" "Mozilla/5.0 (Windows NT 6.1; rv:35.0) ...
    Запрос в регистре ICA+.crl:
    ...15:23:24 +0300] "GET /certenroll/ICA+.crl HTTP/1.0" 200 1031 "-" "Mozilla/5.0 (Windows NT 6.1; rv:35.0) ...

    ТЕПЕРЬ запрос DeltaCRL из Enterprise PKI к Apache:
    ...время...] "GET /certenroll/ICA.crl HTTP/1.1" 200 1262 "-" "Microsoft-CryptoAPI/6.0". Т.е. Апач отвечает успешным HTTP-кодом 200, но, похоже, что EnterprisePKI, пытаясь запросить DeltaCRL, запрашивает почему-то ICA.crl (т.е. основной CRL)

    В запросах EnterprisePKI есть запрос DeltaCRL от EnterprisePKI к самому себе (http://isscomp....) и запрос к Apache (http://caext...). Почему в URL-запросе к isscomp имеется знак плюс "+", а к caext - отсутствует?

    28 января 2015 г. 12:44
  • Думаю, что это Apache так интерпретирует URL, переданный ему в заголовке HTTP. Как именно выглядит URL при передачи по сети, надо смотреть сниффером (Network Monitor, Wireshark и т.д.)

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

    28 января 2015 г. 13:45
  • А у Вас в основном CRL ссылки на дельту имеются (графа Freshest CRL)?

    28 января 2015 г. 14:52
  • завтра все отпишу, ибо на работе всё :)
    28 января 2015 г. 15:41
  • Антон, как успехи?

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий. Не забывайте помечать сообщения как ответы и полезные, если они Вам помогли.

    2 февраля 2015 г. 12:07
    Модератор
  • Добрый день!
    Успехи посредственные - похоже, проблема была в конфигурации самого центра сертификации.
    В Enterprise PKI отображались две ссылки, по которым проверялась доступность DeltaCRL - одна указывала на сам ЦС (допустим, ca.dom1.example.com), другая - на отдельный веб-сервер (допустим, ws.dom2.example.com). Как известно, файл DeltaCRL отличается от CRL наличием "+" в конце имени файла.

    При этом, служба Enterprise PKI, проверяя доступность DeltaCRL на "самом себе" (ca.dom1.<...>/certenroll/ICA+.crl) действительно получает его и сообщает об успешности.

    Однако, проверяя доступность DeltaCRL на веб-сервере, она почему-то проверяет путь "ws.dom2.<...>/certenroll/ICA.crl" - без плюса (+), что является вообще ссылкой на базовый CRL. Получается парадокс: "проверяю одно, получаю другое", что неверно и возвращается ошибка "Unable to Download" (при этом логи веб-сервера сообщают об успешности обращения - код 200, а "входящий" запрос к нему содержит указание именно на файл "ICA.crl"). Т.е. неверно запрашивает сам ЦС.
    Ввиду критичности настроек ЦС в своей организации решил не использовать DeltaCRL и установил новый ЦС.

    Если я неправильно рассуждаю, буду рад, если укажете мне на мои ошибки. :)

    2 февраля 2015 г. 14:19