Contents of this directory is archived and no longer updated.

Тут от одного пользователя поступила небольшая кучка вопросов. Вопросов достаточно и я решил их опубликовать и ответить в бложеке (оригинальная орфография сохранена). Вопросы в италике, ответы не в италике.

1. У вас практически во всех примерах не более трёх путей публикации (в некоторых обсуждениях - четыре) - два файловых локальных пути и
внешний web в самой статье. Когда вы пишите про LDAP, то пути также три - один файловый, внешний web  и LDAP. Это опять же связано с
таймаутом 20 секунд на обработку расширений? Т.е. больше - плохо?

Точек распространения файлов может быть сколько угодно. А вот точек публикаций не должно превышать 2-х, т.к. чисто технически 3-я (и последующие) работать уже не будут ни при каком раскладе. Об этом ниже.

2. Не могли ьы подсказать как поточнее считать таймауты? Первое правило - 10 сек, второе - 5 сек, 3 - 2.5-3 сек или  именно LDAP - 10 сек,
http - 5 сек?

Правило подсчёта простое: таймаут на первую ссылку (вне зависимости от протокола) в составляет 15 секунд. Вторая ссылка составляет 5 секунд. Однако, здесь действует ещё одно ограничение — общее время таймаута для обработки одного сертификата — 20 секунд. Если вы сложите эти таймауты, скорее всего (но не факт) получите число 20, что вываливается в факт, что если в сертификате указано 3 и более ссылок, CryptoAPI максимум осилит только 2, всё остальное отвалится по общему таймауту.

3. Есть ли таймаут на выкладывание (публикацию) сертификатов по указанным в конфигурации путям? Или сервер CA будет пытаться это сделать до
потери пульса?

таймауты есть, но про конкретные значения я не знаю. Вполне возможно, что это будут таймауты самих протоколов (SMB/LDAP).

4. Что-то поменялось в вашем отношении к публикации сертификатов и списков CRL в LDAP? Или вы по прежнему считаете, что это совершенно не
нужно? (я читал один из ваших постов, где вы пишите, что как раз занимались проектом, где чуть ли не только LDAP был). Если издаём на одном
сервере сертификаты и для внутренних и для внешних клиентов (а то и так три сервера - offline, IPCA, OSCP, при этом два - Enterprise), то
LDAP первым, а HTTP вторым или наоборот? А может быть всё-таки, как предложил Oleg - временно убирать из путей LDAP при выдаче сертификата
для внешнего ресурса (если таких немного и не часто это надо)? Тем более никто не мешает сделать wildcard-сертификат типа "*.contoso.com".

Я не думаю, что у меня это отношение поменялось, потому что я всегда был против публикации CRL'ов в LDAP кроме случаев исключительно внутреннего использования сертификатов. В этом случае использование LDAP вполне оправдано и целесообразно. В остальных случаях ссылки на LDAP в сертификатах фигурировать не должны.

5. Если у нас в AIA web-путь на OCSP задан третьей по счёту строчкой ("32:http://www.{adatum.com}/ocsp"), как будет отрабатывать клиент,
если это Виста и выше - сразу пойдёт проверять по OCSP или опять же по очереди?

Если клиент Vista+, его поведение при проверке отзыва сертификата будет следующим: сначала клиент заглянет в расширение AIA и поищет там ссылки на OCSP (если вы посмотрите на это расширение, вы увидите, что ссылки на OCSP и файлы CRT разделены разными методами доступа). При поиске ссылок OCSP ссылки на сертификат самого CA будут отброшены. Если статус отзыва при помощи OCSP не установлен, клиент переключается на расширение CDP и по очереди перебирает ссылки, пока статус сертификата не будет установлен.

6. Если у меня будут внесены CRT и CRL в LDAP (для RootCA и SubCA) и произойдёт, например обрыв связи между двумя AD-сайтами. В этом случае
смогут ли клиенты в отличном от SubCA-сервера сайте, у которых закрыт web (т.е. они не могут проверить сертификат по http),  проверять
валидность выданных сертификатов просто через свой контроллер Active Directory?

если случился обрыв связи, значит (скорее всего), репликация Active Directory происходить не будет. Следовательно, пока на локальном (в сайте) контроллере CRL'ы свежие — клиенты в сайте смогут проверять сертификаты. Как только CRL'ы протухнут, проверка сертификатов на отзыв будет фейлиться до восстановления репликации Active Directory.

http://www.sysadmins.lv/CommentView,guid,7cddb78e-fece-4d8a-8c85-813055311492.aspx
1. Зачем нам настраивать в принципе OCSP для Offline RootCA (что-то не нагуглил)? Чтобы можно было по этому механизму проверить всю цепочку
до сертификата RootCA, а не только отдельные CRL'и? Для этого разве недостаточно, что у нас будет поднят OCSP на издающем SubCA?

На самом деле бесполезно настраивать OCSP для корневых CA. И вот почему: среднестатистический запрос OCSP занимает 90 байт, ответ на него ~1,5kb. Учитывая специфику этих всяких offline CA (корневой и выделенный policy), их CRL будет почти всегда пуст. Или несколько отозванных сертификатов подчинённых CA. Среднестатистический CRL такого CA будет весить примерно 500 байт. Даже по трафику понятно, что для малодеятельных CA нет смысла настраивать OCSP. В упомянутой серии статей я просто хотел продемонстрировать, что вы можете настроить конфигурацию OCSP и для таких типов CA. Ни больше, ни меньше.

2. Для настройки OSCP для Offline Root CA система на нём должна быть Enterprise-редакции или достаточно Standard?

Если говорить о CA, достаточно и Standard. Для OCSP это совершенно безразлично на чём работает CA, хоть на линупсе. А вот Windows OCSP может быть установлен только на Enterprise и Datacenter редакции.

3. Тут есть вопрос и ваш ответ - посты от 25 апреля 2011 года про добавление шары "65:\\{servername}\...". Хочу уточнить - это, навреное,
касается всё-таки SubCA, а не RootCA (который Offline, не в сети и в сейфе :))?

разумеется. Поскольку offline CA не имеет никаких сетевых подключений, пути UNC лишены смысла (и вы это видите в указанном скрипте).

http://www.sysadmins.lv/CommentView,guid,bb8a9447-9b14-4540-add9-6df308129edd.aspx 
1. Можно ли безболезненно размещать на одном сервере SubCA (сервер Win 2008 R2 SP1 - просто член домена, не контроллер, сервис IIS) роли
Enterprise CA, OCSP, NDES? Или есть какие-то ньансы?

Технически вы можете всё. Например, установить CA/OCSP/NDES/CEP/CES/WebEnrollment на одной машине. Более того, вы туда можете доставить ещё контроллер домена, сервер Exchange, SharePoint Portal, Project Server, TMG, весь System Center и сделать хостом гипервизора. И особых нюансов здесь нету, кроме того, что это будет Адъ и Израель. На сервер CA я бы кроме роли самого CA других ролей и приложений не устанавливал.


Share this article:

Comments:

FMihalych
FMihalych 01.06.2012 01:26 (GMT+2) Вопросы-ответы по PKI

Приветствую. Извиняюсь перед всеми за "не всегда" орфографию и "не совсем" стиль вопросов :). Вадимс, огромное спасибо за ответы и терпение! Всем удачи! P.S. Хуже всех приходится программистам Микрософт - им не на кого пожаловаться :)

Михаил
Михаил 04.06.2012 13:35 (GMT+2) Вопросы-ответы по PKI

Как раз в описанную выше тематику вопросик! Добрый день! Имеется следующий вопрос: Имею инфраструктуру из AD + CA на одной машине. Плюс один клиент на Windows XP. Для клиента выдаю сертификат smartcardlogon. Вхожу в систему! Все хорошо! После чего откатываю CA + AD до того состояния пока сертификат пользователя еще не был выдан! Вхожу в систему клиентом по сертификату - и ОПЯТЬ ВСЕ ОК!!!! В итоге получается что котроллер домена проверяет лишь наличие соответсвия UPN в сертификате с учетной записью пользователя + подпись сертификата + отсутсвие сертификта пользваотеля в CRL. И в связи с этим спокойно пускает??? Нет проверки наличия серийного номера сертификата в БД сертификатов????

Vadims Podāns
Vadims Podāns 04.06.2012 14:28 (GMT+2) Вопросы-ответы по PKI

Естественно не будет проверять. Потому что если сертификат выписан и есть целостная и доверенная цифровая подпись (которая означает non-repudiation, т.е. отказ от отрицания), значит владельца можно опознать по предоставленному сертификату. И подумайте о другом, как контроллер домена будет обращаться к БД сервера CA? Это нонсенс. А если CA не в сети?

Михаил
Михаил 05.06.2012 12:25 (GMT+2) Вопросы-ответы по PKI

Большое спасибо за ответы!!!! И как быть и что делать в такой ситауции??? Просто в данном случе можно спокойно взломать администрторские учетные данные, выдать себе сертификат...(например для плохих целей) и откатить все назад, и легальный админ даже ничего не заметит. И ситуация когда ни один из CA не в сети - это мне кажется не слишком распространненый вариант, по крайней мере не слышал об этом... Инфраструктура когда коренвой CA не в сети имеет место на существование..., но при этом тогда подчиненный CA работает! А корневой обычно выдает только сертификат подчиненному... Или я не в ту сторону мыслю??? И еще один вопрос: При утсновке AD+CA на одной машине, каким образом осуществляется проверка сертификата на отзыв(smartcardlogon)??? Откуда берутся данные по отозванным сертификатам? По пути который укащан в LDAP(при условии что он точно есть и указан в CDP)??? И данные значения я как понимаю не кэшируются??? Поскольку опытным путем установлено, что при нахождении контроллера домена и CA на одной машине...и при отзывае сертификата (например smartcardlogon)пользователь не может аутентифицировать в домене моментально (разумеется при опубликовании свежего CRL)... В отличии например при аутентификации на веб-сервере по сертификатам (когда веб-сервер находится на отдельной машине)..., поскольку в этом случае веб-сервер будет пускать до тех пор, пока не истечек кэш CRL.

Vadims Podāns
Vadims Podāns 05.06.2012 14:20 (GMT+2) Вопросы-ответы по PKI

> Просто в данном случе можно спокойно взломать администрторские учетные данные остальное можно не читать даже, потому что оно теряет всяческий смысл. Я надеюсь, вы умеете читать по-английски: http://technet.microsoft.com/en-us/library/cc722487.aspx первые 3 пункта.

Михаил
Михаил 05.06.2012 14:41 (GMT+2) Вопросы-ответы по PKI

Спасибо за статью! Но я ее в свое время изучил вдоль и поперек! И это было в качестве предположения... Как пример: увольнение сотрудника(системного администратора)из компании со скандалом...! Если не сложно, все же посмотрите мой крайний вопрос про кэширование CRL.... Буду благодарен!

Vadims Podāns
Vadims Podāns 05.06.2012 14:55 (GMT+2) Вопросы-ответы по PKI

А это уже уголовное дело, если что. На счёт кэширования не скажу. Не имею привычки устанавливать CA на контроллеры домена.

Михаил
Михаил 05.06.2012 15:08 (GMT+2) Вопросы-ответы по PKI

Понятно! Спасибо за ответ!!! А если CA и Контроллер Домена (далее КД) на разных машинах, то CRL на КД кэшируется??? Т.е. описанная мною ситуация не возникает???

Vadims Podāns
Vadims Podāns 05.06.2012 15:42 (GMT+2) Вопросы-ответы по PKI

Да, кэшируется.

FMihalych
FMihalych 18.06.2012 13:37 (GMT+2) Вопросы-ответы по PKI

Приветствую. Хочу ещё раз уточнить, сколько всё-таки обрабатывается CryptoAPI-клиентом первая ссылка публикации сертификатов - 15 сек. (п. 2 данного поста) или 10 секунд (http://www.sysadmins.lv/PermaLink,guid,9beb4f0a-38a8-42b2-9a49-141c04fbdcd8.aspx). И если первая ссылка - 10 сек, вторая - 5, то сколько времени будет обрабатываться 3-я ссылка? Спасибо.

Vadims Podāns
Vadims Podāns 18.06.2012 14:23 (GMT+2) Вопросы-ответы по PKI

Сейчас на всех системах сделали 15 на первую и 5 секунд на вторую. На 3-ю ссылку по дефолту времени не остаётся. 10 и 5 было в windows xp/2003, но потом апдейтами привели к общему знаменателю.

gexeg.blogspot.com
gexeg.blogspot.com 02.07.2012 13:20 (GMT+2) Вопросы-ответы по PKI

У меня в CDP пять http URL и все пять обрабатываются с таймаутом в 15 секунд (использую класс X509Chain). IE обрабатывает также пять URL, но с таймаутами 10,5,2.5 и т.д. Вопрос: что я делаю не правильно? :)

gexeg.blogspot.com
gexeg.blogspot.com 02.07.2012 13:21 (GMT+2) Вопросы-ответы по PKI

Update к последнему комментарию: клиент и сервер - Windows Server 2008 R2

Vadims Podāns
Vadims Podāns 02.07.2012 14:07 (GMT+2) Вопросы-ответы по PKI

> У меня в CDP пять http URL и все пять обрабатываются с таймаутом в 15 секунд (использую класс X509Chain). вполне возможно, X509Chain использует свои таймауты (внутри он вызывает стандартные функции, где можно задавать почти любые параметры). > IE обрабатывает также пять URL, но с таймаутами 10,5,2.5 и т.д. надо посмотреть.

Вячеслав
Вячеслав 13.08.2012 12:34 (GMT+2) Вопросы-ответы по PKI

Вадимс, хочу задать Вам вопрос. В PKI планируем использовать OCSP. OCSP будет поднят на сервере с именем, например, server.domain.com. На это имя в DNS будет сделан alias - ocsp. В AIA будет прописано http://ocsp.domain.com/ocsp. Учитывая, что сертификат по шаблону OCSP Response Signing будет выдаваться на Subject server.domain.com возникнут ли проблемы в работе OCSP? Спасибо.

Vadims Podāns
Vadims Podāns 13.08.2012 13:23 (GMT+2) Вопросы-ответы по PKI

никаких проблем не будет. Имя сертификата не проверяется и служит для идентификации респондера.

Comments are closed.