| ||||
| ||||
| ЦС перестал выдавать сертификаты: запрос от клиента уходит нормально, а при проверке ожидающего выполнения запроса на сертификат пишет, что "Нет ожидающих запросов на сертификат". Хотя сервером сертификат выдан явно. Спасибо. | ||||
| Ответы: | ||||
| ||||
| А как настроен модуль политии? http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/windows2000serv/deploy/2000cert.asp | ||||
| ||||
| Модуль политики чего? ЦС или Windows? Все стоит по умолчанию. Самое интересное, что ЦС ПЕРЕСТАЛ нормально выдавать сертификаты. Раньше все было ОК. Хотя бывало, что после некоторого времени такой глюк был, но при восстановлении ЦС (периодически он архивируется), все приходило в норму. На этот раз глюк случился после установки SP2 м патча Q323172. | ||||
| ||||
| Модуль политики ЦС, который настраивается либо на автоматический выпуск сертификатов, либо на обработку запросов админом. Патч Q323172 это новый модуль xeroll, который имеет другой clsid. При установке патча должны модифицироваться страницы веб сервера ЦС. Пользователю при соединениии с сервером (если не установлен патч) будет грузиться новый xenroll в виде ActiveX. | ||||
| ||||
| Модуль политики ЦС изначально был настроен на выдачу сертификатом админом (и неплохо их выдавал!). С этим все понятно. А вот про патч хотелось бы попдробнее. На сайте Microsoft ничего толком не вычитал. На что и как влияет CLSID? Страницы web-сервера IIS в Win2k мождифицировались. Надо что-нибудь доправить руками, кроме как прописать загрузку ЦС по умолчанию? Нужно ли патчить клиентов? В SP1 WinXP (написано на сайте M$), что этот патч уже есть). Одним словом, что делать-то??? | ||||
| ||||
| Когда пользователь загружает страницу ЦС от стандартного микрософтового ЦС, до патча ему грузится объект с идентификатором var sControl="<Object \n" + " ClassID=\"clsid:43F8F289-7A20-11D0-8F06-00C04FC295E1\"\n" + " Codebase=\"/CertControl/xenrlinf.cab#Version=<%=sXEnrollVersion%>\"\n" + " ID=XEnroll\n" + "></Object>"; Когда установили патч, идентификатор другой. var sControl="<Object \n" + " ClassID=\"clsid:127698e4-e730-4e5c-a2b1-21490a70c8a1\"\n" + " Codebase=\"/CertControl/xenrlinf.cab#Version=5,131,3659,0\"\n" + " ID=XEnroll\n" + "></Object>"; Если у пользователя нет патча, он будет грузиться. Посмотрите файл certsgcl.inc изменен ли там идентификатор после установки патча. | ||||
| ||||
| Файл certsgcl.inc корректно изменился. Но проблема осталась. У пользователей запросы сертификатов лежат в кэше, на сервере сертификаты выданы, а пользователи не могут их получить! | ||||
| ||||
| Когда пользователь делает запрос, сервер формирует cookies. При обращении за сертификатом используется сохраненные cookies. Проблема скорее всего в этом. cookies не сохраняются. | ||||
| ||||
| Использование cookie в IE включено. В настройках клиента (Win2kPro) установлен элемент ActiveX: Свойства InternetExplorer’а->Общие->Настройка (Временные файла Интернета)->Просмотр объектов: Файл программы: CEnroll Class Код: {127698E4-E730-4E5C-A2B1-21490A70C8A1} Состояние: установлено Полный размер: 172 кб Версия: 5,131,3659,0 .... На станции ЦС ничего этого нет. А должно быть? Кроме того отличаются версии xenroll.dll в %SystemDir%\system32\CertSrv\CertControl\alpha (5.131.2090.1) и %SystemDir%\system32\CertSrv\CertControl\x86 (5.131.3659.0). Это правильно? И еще: На станции клиента xenroll.dll в папке %SystemDir%\system32 и %SystemDir%\system32\dllcache лежит старая версия (5.131.2146.1), и только в %SystemDir%\Downloaded Program Files лежит новая версия (5.131.3659.0). Так и должно быть? Кстати, локально на станции ЦС тоже не выдаются пользовательские сертификаты. | ||||
| ||||
| IIS переставляли? | ||||
| ||||
| После установки патчей нет. Но до установки патчей один раз переставлял (другая проблема была). | ||||
| ||||
| Поэтому и перестали работаь coockies. Как с этим побороться прямо сейчас не скажу. | ||||
| ||||
| Так IIS надо переставлять или нет? Или до этого не надо было его трогать? | ||||
| ||||
| А после переустановки IIS создавали виртуальный каталог для ЦС? | ||||
| ||||
| Так в том и дело, что web-страницы ЦС нормально загружаются и пользователи могут заказать у ЦС сертификат. Но вот ответ сервера один - "Нет ожидающих запросов на сертификат". | ||||
| ||||
| Что можно сделать. 1. Создать по новой виртуальный каталог (так как это делает ЦС при установке) и сконфигурить. 2. Переустановить центр (сделав backup). | ||||
| ||||
| При переустановке ЦС генерируется новый закрытый ключ. При восстановлении ЦС из архива, он не стартует - пишет "Службы сертификации не запущены: не удалось построить цепочку сертификатов ЦС для SDV Certificate Centre. Неправильная подпись. 0x80090006 (-2146893818)". Как восстановить старый закрытый ключ? Ведь с новым ключом все выданные сертификаты становяться недействительными! | ||||
| ||||
| Отправил по почте описание. | ||||
| ||||
| Спасибо за идею! Восстановил все без правки реестра. | ||||
SDV