Листая тематические форумы, рефералов бложика и переписку в почте, уже набралось немного вопросов, на которые нет смысла делать отдельный пост, но есть смысл вынести в очередной FAQ.
Q: Как узнать тип установленного на сервере Certification Authority?
A: тип Certification Authority можно узнать несколькими методами, которые обычно основываются на реестре:
HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CA Sanitized Name>
и запись типа REG_DWORD — CAType. И вот что означает каждое значение:
0 — Enterprise Root CA
1 — Enterprise Subordinate CA
3 — Standalone Root CA
4 — Standalone Subordinate CA
5 — Unknown
По большому счёту, если вы задаёте этот вопрос, значит, для вас этот тип — Unknown (5) :-)
Q: Может ли в домене/лесу Active Directory существовать 2 и более иерархий PKI с разными корневыми центрами сертификации?
A: да, вы можете в существующем домене/лесу развернуть несколько независимых иерархий PKI. Сервер CA не использует домен для захвата власти, а только лишь для обеспечения удобства распространения и выдачи сертификатов конечным потребителям.
Q: Можно ли мигрировать сервер CA с платформы x86 на x64? Судя по этой статье: http://support.microsoft.com/kb/298138, это невозможно. Как быть?
A: Сведения представленные в указанной статье не совсем достоверны. Технически бэкап БД выполненный на платформе x86 может быть успешно восстановлен на платформе x64 и каких-то проблем с этим возникнуть не должно. Поэтому вы можете смело планировать миграцию ваших серверов CA с x86 на x64, особенно если существующий CA работает на системе под управлением Windows 2000. В качестве руководства по миграции вы можете руководствоваться следующим вайтпепером: http://technet.microsoft.com/en-us/library/ee126170(WS.10).aspx
Q: Я зашифровал папку с файлами при помощи EFS, но пользователи всё равно могут просматривать содержимое папки? Что это, баг или данные просто не шифруются?
A: Это не баг, а нормальное поведение системы (при условии, что другие пользователи имеют права на просмотр содержимого каталога). Если посмотреть на файловую сисему изнутри, становится понятно, что папка — всего лишь логический контейнер и он хранится в MFT. Папка сама по себе не содержит в себе данных и не имеет размера. А сами данные, которые нужно шифровать находятся в другой части файловой системы. Поэтому если вы зашифровали папку средствами EFS, шифруются сами данные, но обзор списка файлов в шифрованной папке по прежнему разрешён.
Q: мне нужно издать сертификат с некоторыми данными в расширении Subject Alternative Name (SAN). Я создаю запрос с этим расширением, но CA игнорирует это расширение. Как быть?
A: по умолчанию Windows CA игнорирует это расширение в целях безопасности. Для включения этого расширения воспользуйтесь сведениями из этой статьи: http://support.microsoft.com/kb/931351
Q: для чего служат различные контейнеры в AD внутри контейнера Public Key Services?
A: эти контейнеры служат для обеспечения автоматизации работы центра сертификации, подачи запросов и проверки сертификатов.
- NTAuthCertificates — служит для хранения сертификатов центров сертификации, которым разрешено издавать логонные сертификаты (для смарт-карт, для аутентификации по сертификатам в VPN или IIS) для текущего леса. Например, вы используете сторонний центр сертификации, выдающий сертификаты для смарт-карт. Для того, чтобы контроллеры домена распознавали и доверяли этим сертификатам, сертификат стороннего CA должен быть добавлен в NTAuthCertificates. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Intermediate CAs.
- AIA — служит для хранения сертификатов центров сертификации. Сертификаты из этого контейнера используются для ускорения построения цепочек сертификатов при проверке. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Intermediate CAs.
- CDP — служит для хранения списков отзыва (Certificate Revocation List или CRL). Списки отзыва используются для определения статуса конкретного сертификата (отозван или не отозван). CRL'ы из этого контейнера не копируются клиентами. Поэтому CRL опубликованный в данном контейнере может быть использован только если расширение CDP какого-то сертификата явно ссылается на него.
- Certifiation Authorities — служит для хранения собственных или сторонних доверенных корневых центров сертификации. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Trusted Root CAs.
- KRA — служит для хранения выпущенных сертификатов агентов восстановления. Каждый выпущенный сертификат агент восстановления публикуется в этот контейнер в запись соответствующего CA. Важно понимать, что при назначении нового агента восстановления на сервере CA, содержимое данного контейнера не изменяется.
- Enrollment Services — служит для хранения записей и сертификатов всех Enterprise CA в текущем лесу. Клиенты используют этот контейнер для обнаружения Enterprise CA.
- OID — содержит все OID'ы зарегистрированные в вашей компании. В том числе Issuance, Application Policies, Certificate Templates OID's.
- Certificate Templates — служит для хранения сведений о всех шаблонах сертификатов текущего леса.
Q: я создал шаблон версии 3 (Windows Server 2008 Enterprise Edition) для смарт-карт, но при энроллменте я получаю ошибку. В чём дело?
A: исторически CSP (Cryptography Service Provider) смарт-карт не поддерживают алгоритмы CNG (Cryptography New Generation), которые реализованы в шаблонах версии 3. Следовательно, вы не можете использовать шаблоны версии 3 для смарт-карт. Вместо этого вы должны использовать шаблоны версии 2 (Windows Server 2003 Enterprise Edition).
Q: я установил MS OCSP Responder, но папка веб-приложения пуста. Что должно быть в папке OCSP?
A: Имплементация OCSP в Windows основывается на ISAPI фиьтрах, реализованных в библиотеке ocspisapi.dll. Поэтому при создании веб-приложения OCSP путь к нему указывается как %systemroot%\SystemData\ocsp. В этой папке есть только папка aspnet_client, но файлов никаких нет. Их быть и не должно.
Что означает фраза "CRL'ы из этого контейнера не копируются клиентами"? В моем сертификате отображаются два CDP (HTTP). Списки доступны по указанным путям и регулярно обновляются. Мой сертификат давно отозван, но пишет что он действителен, несмотря на то что срок действительности CRL давно истек. CRL должен регулярно копировать пользователь вручную? Даже если так, то не понятно зачем тогда нужен срок действительности CRL. Может это из-за того что у меня Win7 и в сертификат добавлена пока не рабочая ссылка на OCSP (добавил на будущее).
я думаю, что ответ вы найдёте здесь: http://www.sysadmins.lv/PermaLink,guid,1d4b05e1-833f-4479-b110-c3ed63be1706.aspx Q: Я отозвал сертификат, опубликовал новый CRL, однако при запуске файла сертификата я не вижу ошибок, что сертификат отозван. Почему? A: Когда вы запускаете файл сертификата (просматриваете его содержимое), проверка на отзыв не происходит. Система только строит цепочку, но ни один сертификат на отзыв не проверяется. Это by design.
Вы писали что в папке %systemroot%\SystemData\ocsp, есть папка aspnet_client, но у меня нет даже ее. Установил сетвеого ответчика OCSP на контроллер домена W2008R2 Enterprise, на нем же установлен RootCA. Устанавливал все по Вашим статьям(OCSP часть 1 и 2) и оригинальному руководству майкрософт. В итоге в остнастке OCSP пишет что все работает. Выдал сертификат, отозвал, опубликовал новые CRL, выполняю команду certutil - url имя сертификата.cer, проверяю по OCSP(AIA) - dslftncz ответ Проверено, то же самое выдается и при проверке по CRL(CDP), а команда certutil - verify -urlfetch имясертификата.cer пишет Revoked, но в логах этой команды под строкой OCSP стоит Проверено. В чем может быть проблема???
проблема в том, что OCSP обращается к CRL только периодически. По умолчанию обращается один раз и потом только после обновления CRL. Поэтому нужно уменьшить интервал обновления кеша самого OCSP. Это можно сделать при создании конфигурации. Вот в том окне, где прописываете линки к CRL'ам, там же и указываете время обновления кеша.
Поставил минимальное значение, как указано у майкрософт - 5 минут. Все равно сertutil - verify -urlfetch имясертификата.cer выдает Revoked, но при этом пишется что Certificate OCSP Verified "OCSP" Time: 2 [0.0] http://"OCSP server"/ocsp Проверял с помощью пакетного анализатора запрос и ответ респондера. Все проходит: то есть запрос уходит от клиента, принимается респондером, обрабатывается и возвращается ответ. Пробовал серийный номер сертификата заносить в Local CRL, при этом сertutil - verify -urlfetch имясертификата.cer выдает Проверено, а Certificate OCSP Revoked "OCSP" Time: 2 [0.0] http://"OCSP server"/ocsp Есть предположение, что OCSP сервер не видит списки отзывов. Каким образом это можно проверить. в конфигурации OCSP Revocation Configuration указаны Base CRL: ldap\\....
В итоге OCSP начинает показывать что сертификат отозван либо после перезагрузки машины с ЦС, либо же через какой-то промежуток времени больший чем 20 минут(дальше я не следил, проверил только на след день), при условии что списки CRL были обновлены и опубликованы сразу же после отзыва сертификата. Непонятны таки большие задержки в работе OCSP. Ведь списки отзывов обновлены, OCSP всю информацию черпает из них. Команда urlfletch примерно через 2 минуты, после опубликования списков отзывов выдает то что сертификат отозван, а OCSP, повторюсь, показывает только через 20 минут..не раньше.
В итоге получилось следующее: время обновления кэша, которое я выставляю ни к чему не привело! Помогает только перезапуск службы WWW, я как понимаю именно там хранится кэш, откуда черпает все данные сетевой ответчик. После его обновления сертификат получает статус Revoked. Но опять же проблема!!! При попытке пользователя войти по отозванной смарт-карте, вход свободно осуществляется, хотя и сертификат имеет статус Revoked, при проверке certutil -url certificat.cer. В чем здесь может возникнуть проблема??? Нужно ли из списков AIA исключить все кроме сетвого ответчика???
> При попытке пользователя войти по отозванной смарт-карте, вход свободно осуществляется, хотя и сертификат имеет статус Revoked, при проверке certutil -url certificat.cer. В чем здесь может возникнуть проблема??? я так подозреваю, что это уже работает клиентский кеш. Потому что клиент обновляет кеш только тогда, когда истекает предыдущий CRL. Я бы посоветовал начать с этого: http://technet.microsoft.com/en-us/library/ee619730(WS.10).aspx
Кэши все обновляю...и на локальной машине, и на сервере, где установлен CA. Certutil - url ведь показывает что сертификат отозван. А когда захожу на клиентскую машину по смарт-карте, то при помощи пакетного нализатора вижу, что обращений по протоколу OCSP нет. ТОлько kerberos. В группповых политиках стоит приоритет на OCSP, кэш по билетам Kerberos тоже выставлен на минимум. Не пойму почему у меня не хочет подхватываться OCSP. Может он действует не всегда?? В моем случае я прост по смарт-карте пытаюсь войти в домен.
Больше нет никаких мыслей по моему вопросу???
нет, пока мыслей никаких, кроме как начинать разбираться с OCSP. Как вариант, можно попробовать его переустановить. И при проверке убедиться, что OCSP имеет наиболее свежий CRL (это можно проследить в самой оснастке OCSP в секции revocation providers).
Я уже переустанавливал. Но не помогло. Все равно certutil - url говорит что сертификат отозван....а когда захожу по смарткарте на комп ..то все окей!!! До тех пор пока не обновится список CRL. То есть работа OCSP зависит напрямую от частоты публикования CRL. А не как было заявлено мелгомягкими....что отзыв сертификата срабатывает почти в онлайн режиме. А когда CRL обновляется то запрос на валидность сертификата все рано идет через kerberos, который уже проверяет в базе данных AD(вернее где-то там в хранилище), а OCSP как бы опять отдыхает.
Comments: