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

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 других ролей и приложений не устанавливал.