Вася Гусев прислал мне одну замечательную ссылку на пост (а в посте ссылка на документ) Дмитрия Буланова по управлению AppLocker'ом с использованием Windows PowerShell: http://dimanb.spaces.live.com/blog/cns!7D6C59DEE1DA79E5!323.entry

В принципе, это хорошо, т.к. мне уже, возможно, не понадобится об этом писать. Однако, я не разделяю такого оптимизма автора документа (кстати говоря, авторство принадлежит не Дмитрию, а только перевод. Причём, бездарный перевод) и считаю, что такая поддержка со стороны PowerShell ещё ниже опускает уровень защиты AppLocker. Но и сам документ выглядит как типичный маркетинговый булшит, поскольку содержит несколько ложных утверждений и достаточно много подтасованных фактов. Давайте посмотрим документ внимательней:

Уже несколько лет администраторам в организациях приходилось устанавливать стороннее программное обеспечение, за что организациям приходилось тратить немалые средства. Теперь с появлением AppLocker у администраторов нет необходимости в поиске стороннего программного обеспечения, т.к. с появлением Windows 7 и Windows Server 2008 R2 AppLocker добавлен в групповые политики.

При этом автор очень сильно недоговаривает, поскольку SRP существует ещё с 2001 года (когда вышел RTM Windows XP). Т.е. раньше тоже были средства контроля используемых приложений.

Часто со временем, после развертывания операционных систем, конфигурация программного обеспечения типичного рабочего места оказывается далека от желаемого результата. Несогласованности приходят чаще, не столько от установки, сколько от работы несоответствующего стандартам программного обеспечения в пределах настольного окружения. Пользователи инсталлируют программное обеспечение из разнообразных источников: компакт-дисков и дисковых накопителей, загрузки файлов из сети Интернет, совместного использования файлов через совместные пиринговые сети, и через электронную почту. Результат – возможность заражения компьютера вредоносным программным кодом

Наверное, единственное утверждение, с которым я согласен.

Software Restriction Policies (SRP), в Windows XP и Windows Vista, было одним из первых решений прикладного контроля. SRP дал IT-администраторам грубый механизм, для определения и написания политик контроля за приложениями. Однако SRP мог ограничить управление в динамической настольной среде, где приложения устанавливались и обновлялись на постоянной основе, т.к. они в основном использовали правила хэширования. С правилами хэширования, каждый раз при обновлении программного обеспечения необходимо было создавать новые правила хэширования.

Враньё! Особенно выделенное. В ряде моментов SRP более гибок, чем AppLocker. Если говорить про правила хешей, то AppLocker вносит только одно удобство – позволяет за раз добавить несколько файлов в правило хеша из одной папки. Но дальше в этом плане ничем не отличается от SRP. А с правилами путей профитов в AppLocker по сравнению с SRP почти и нету, поскольку в правилах путей как правила используются wildcards, вместо полных путей до конечного файла. Про паблишеров я отмечусь чуть ниже.

С появлением AppLocker в операционной системе Windows 7 растет необходимость введения решений прикладного контроля на предприятии: простой и гибкий механизм, который позволяет администраторам конкретизировать разрешения для запуска программного обеспечения в своей программной среде. В результате, AppLocker обеспечивает не только защиту безопасности, но и оперативность и удобство по развертыванию политик

Этим автор ещё раз доказывает своё мнение, что до AppLocker'а у нас был ад и Израиль и у нас не было SRP. И прочитайте выделенное. Мне это говорит, что наоборот, AppLocker – источник всех проблем. Не будь его, не росла эта необходимость. В чём оперативность здесь – мне пока непонятно. Да, и что есть прикладной контроль? Есть мнение, что это от английского Application Control (жертва пиратского промпта? © Artem Pronichkin).

1. Ограничение в запуске нелицензионного программного обеспечения на рабочем месте;
2. Понижение уязвимости, средствами запрещения запуска несанкционированных приложений на вашем рабочем месте, в том числе запуск вредоносного кода;
3. Запрещать пользователям запуск приложений, которые бесполезно потребляют сетевую пропускную способность;
4. Ограничение пользователей от запуска приложений, которые дестабилизируют их рабочую среду;
5. Эффективность конфигурации управления;
6. Позволять пользователям устанавливать и запускать одобренное администратором программное обеспечение основанное на деловых потребностях;
7. Гарантировать, согласованность установки программного обеспечения с корпоративными политиками и правилами, например PCI DSS, Sarbanes-Oxley, HIPAA, Basel II, и другое.

пункт 3 - покажите!!! Как? Я тоже хочу использовать такую функциональность! Т.е. создавать правила на основе критериев: только приложения, которые полезно потребляют пропускную способность сети. В последнем пункте заметил несколько новых слов, значения которых я не знаю. Подозреваю, что основная целевая аудитория документа тоже не сильно владеет такими терминами.

Но вообще все эти пункты укладываются в более короткий список:

• Контроль запуска только разрешённых администратором приложений. Что исключает возможность несанкционированного запуска потенциально опасного, вредного или лишнего ПО.

Размазывать единственное предназначение AppLocker'а (равно как и SRP) на 7 пунктов незачем. Разве что – задавить читателя массой возможностей нового продукта.

разрешения, запрещения и исключения

в русском языке вряд ли есть такое слово, как “запрещения”. Правильнее будет “запрет”. Промпт переводит как умеет…

Администратору предоставляется возможность разрешения на запуск приложений, которые входят в «белый список приложений» и блокировать все остальное.

в этом предложении я ничего не понял, кроме “белый список приложений”.

Пока многие предприятия будут использовать правила разрешенных и запрещенных приложений, развертывание AppLocker позволяет использовать правила исключений.

Хотелось бы мне знать, чем в данном случае явный запрет будет отличаться от отдельного запрета? Технически это одно и то же. Т.е. если мы одним правилом накрываем достаточно большую область, в которой нужно создать исключения, то создание исключения или отдельного запрета будет равноценным, поскольку тут так же работает правило приоритета более точного правила. А SRP этим не обделён ни разу.

AppLocker вводит правила издателя, которые основаны на прикладных цифровых подписях. Правила издателя дают возможность создания правил, которые включают возможность обновления программного обеспечения. Например, организация может создать правило, чтобы “разрешить все версии, большие, чем 9.0 для запуска Acrobat Reader, если у программного обеспечения Adobe есть цифровая подпись”. После чего, когда у Adobe появится новая версия Acrobat, вы можете безопасно запустить обновление программы без необходимости создания нового правила для последующей версии приложения.

Вот здесь снова появляется ложь. Правила издателя были в SRP, только немного в ином виде (Certificate Rule). Опять же, следует учитывать, что вы можете использовать эту возможность только при условии, что у файла есть цифровая подпись. Нету подписи – вот вам пачка хешей, работайте. Плюс, как я уже упоминал, AppLocker не закрывает одну опасную брешь в концепции цифровых подписей – не проверяется доверие конкретной цифровой подписи. Кто угодно может прочитать правило паблишера (да-да, именно средствами родного PowerShell, поскольку других вменяемых средств нету) и подписать свой файл своей же подписью, которую AppLocker скушает и разрешит для запуска. Вобщем, разработчики AppLocker'а допустили 2 фатальные ошибки, из-за которых эти профиты могут просто потерять реальный практический смысл:

1. совершенно испоганили правило издателя (publisher), отменив проверку доверия конкретной цифровой подписи;
2. разрешили пользователям со стандартыми правами (standard user) читать все настройки этой политики.

Поэтому эти 2 пункта следует рассматривать не как бенефиты AppLocker'а, а как его недостатки в контексте безопасности. Это было сделано в пользу удобства и в ущерб безопасности. И это не говоря о том, что не все редакции Windows 7 могут использовать эту политику.

Правила AppLocker могут быть ассоциированы с конкретным пользователем или группой в пределах организации. Это обеспечивает гранулирование контроля, что позволяет вам поддерживать требования компании и предписания благодаря которым пользователи могут управлять специфическими приложениями. Например, вы можете создать правило, чтобы “разрешить сотрудникам Отдела Финансов управлять линией приложений, которые относятся к их деятельности”. Эти приложения блокируются от запуска для всех пользователей, которые не находятся в Отделе Финансов (в том числе администраторы), но все еще обеспечивают доступ для тех, у кого есть надобность управлять данными приложениями.

На самом деле это тоже не прорыв. Подобная реализация на уровне групп пользователей была и в SRP, поскольку SRP можно было конфигурировать в секции User Configuration и фильтровать политику с помощью Security Filtering. Т.е. данный функционал был чуть причёсан и сделан более user-friendly.

Благодаря AppLocker в Windows 7, у администраторов появляется возможность контроля за приложениями пользователей.

Ещё раз отмечаю, что AppLocker в этом отношении не единственный бесплатный инструмент.

Вобщем, мой совет читателям – избегать подобных переводов, как ересь и ЛПП, поскольку промпт никогда (во всяком случае – в обозримом будущем) не сможет переводить тексты со смыслом и именно тем смыслом, который заложен в оригинале. Поэтому предлагаю ссылки на оригинальные статьи, которые были переведены в этом документе:

• Windows 7 AppLocker Executive Overview
• Getting Started with AppLocker management using Powershell

Спасибо за внимание :-)

Disclaimer: данный материал публикуется только для ознакомительных целей и не рекомендуется для использования в реальной производственной среде.

Краткий ввод в курс дела. Что такое EV сертификат – это Extended Validation сертификат, который в браузере отображается зелёной полосой:

Что это означает? Это означает, что издатель сертификата (например, VeriSign) более серьёзно и внимательно изучил предъявителя этого сертификата, что даёт пользователям ещё большую гарантию, что сайт, на который вы попали, является тем самым сайтом, который вы набрали в адресной строке. А так же этим подтверждается, что сайт является зарегистрированной коммерческой организацией с сопутствующими проверками. Т.е. к получателю Extended Validation сертификатов предъявляются достаточно жёсткие требования. Эти сертификаты в Public Certification Authorities стоят значимо дороже, чем обычные SSL сертификаты (я посмотрел по предложениям и получилось в среднем увеличение цены в 2 раза). Плюс, такие сертификаты не имеют возможности использования WildCard доменов в Subject, хотя допускают Subject Alternative Names (когда одному web-сайту сопоставляется несколько имён). Такие сертификаты в интернете могут выпускать только одобренные центры сертификации (Certification Authorities). Список таких CA можно посмотреть вот здесь: http://cabforum.org/forum.html. Требования к работе с такими сертификатами для CA и покупателей: http://cabforum.org/documents.html

Но это всё лирика. Мы хотим внутри корпоративного домена поднять SSL веб-портал и чтобы там была такая же зелёная полоска :-) и мы можем такое сделать. Я покажу процесс на примере CA и домена под управлением Windows Server 2008 R2. Я предполагаю, что у вас уже развёрнут домен Active Directory и установлена роль AD CS (Active Directory Certificate Services).

Когда у нас предварительные подготовления закончены нам нужно произвести необходимые изменения в шаблоне Web Server. Для этого нужно сделать следующее:

1. на сервере с установленным CA запустить оснастку Certificate Templates: certtmpl.msc
2. выбрать шаблон Web Server и правой кнопкой выбрать Duplicate Certificate и выбрать версию шаблона 2 или 3 (Windows Server 2003 Enterprise Edition или Windows Server 2008 Enterprise Edition, соответственно).
3. В поле Template Display Name напишите новое имя шаблону (например, Web Server V2 или V3).
4. Убедитесь, что срок действия сертификатов на основе этого шаблона установлен 1 год (обычно для SSL веб-сайтов не выдают сертификаты на срок больше 1 года).
5. На вкладке Extensions выберите Issuance Policies –> Edit –> Add –> New:
    
   и скопируйте сгенерированный OID в поле Object Identifier, он нам ещё потребуется.
   
6. Напишите название вашей политики и адрес CPS (Certificate Practice Statement).
7. На вкладке Request Handling настройте свои значения (как экспорт закрытого ключа, архивация закрытого ключа) на своё усмотрение.
8. На вкладке Issuance Requirements поставьте ручное одобрение администратора CA (чтобы контролировать расход EV сертификатов :-), либо на вкладке Security отрегулируйте разрешения, кому можно запрашивать сертификат.
9. Сохраните шаблон.

Теперь раскройте оснастку Certificate Authority и перейдите в Certificate Templates –> New –> Template To Issue и выберите наш новый шаблон. После того, как все приготовления закончены, можно приступать к редактированию групповой политики.

Примечание: Для редактирования политики вам потребуется консоль GPMC в Windows Server 2008 R2, Windows 7 с установленным RSAT. При этом версия ОС на контроллере может быть другой, но не ниже Windows Server 2003, а сервер CA не ниже Windows Server 2003 Enterprise Edition.

Запустите оснастку GPMC и создайте новую политику, которая будет прилинкована на уровне домена. Безусловно, вы можете редактировать существующую Default Domain Policy, но я не рекомендую использовать дефолтную политику, а для каждой задачи создавать свою политику и линковать куда нужно. В редакторе политики перейдите по секции:

Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Public Key Policies –> Trusted Root Certification Authorities

здесь выберите All Task –> Import и импортируйте корневой сертификат вашего CA, который является корневым в вашем лесу. Далее, выберите свойства сертификата (не открывать сам сертификат) и перейдите в таб Extended Validation:

И добавьте сюда тот самый OID, который у вас был сгенерирован при создании новой Issuance Policy.

Теперь вам нужно перейти на ваш web-сервер. Если это Windows Server 2003, то вы можете запросить новый SSL сертификат из оснастки IIS. Если у вас web-сервер под управлением Windows Server 2008 или выше, то вы не можете больше запрашивать SSL сертификат из оснастки IIS, а только путём генерирования запроса в формате PKCS#7, либо через MMC оснастку Certificates запущенной от лица Local Computer. Запросите новый сертификат на основе вновь созданного шаблона (желательно при запросе указывать наиболее подробные сведения о вашем Web-сервере). Если у вас в политике шаблона указано ручное одобрение запроса – одобрите его в оснастке Certification Authority –> Pending Requests. После того, как сертификат сгенерирован, настройте ваш веб-сервер на работу с SSL с использованием этого сертификата.

Теперь подождите, пока отредактированная групповая политика применится на компьютерах домена. После чего запустите браузер на любом клиенте (не ниже Windows XP SP2 с установленным Internet Explorer 7 или выше) и наберите HTTPS адрес вашего веб-сервера и получайте профит:

И ещё раз о требованиях к операционным системам:

• Domain Controller – не ниже Windows Server 2003 Standard Edition. Для редактирования политики потребуется Windows 7 с RSAT или рядовой член домена под управлением Windows Server 2008 R2 с установленным компонентом Group Policy Management.
• CA – не ниже Windows Server 2003 Enteprise Edition (Кроме Windows Server 2003/2008 Standard/Web Edition).
• веб-сервер – любой.
• клиентский компьютер – не ниже Windows XP SP2 и с установленным Internet Explorer не ниже 7 версии.

И ещё раз напоминаю, что это будет видно только тем компьютерам, которые получили изменённую политику. Остальные компьютеры будут видеть обычный замочек и всё.

Have a nice day!

Это будет краткая заметка по решению одной проблемы (пока причина проблемы не установлена) при установке OCSP Responder на контроллере домена под управлением Windows Server 2008 R2 RTM. При такой установке у вас в Application Log может появиться сообщение:

Log Name:      Application
Source:        SceCli
Date:          2009.08.13. 12:46:22
Event ID:      1202
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      server.domain.com
Description:
Security policies were propagated with warning. 0x534 : No mapping between account names and security IDs was done.

Advanced help for this problem is available on http://support.microsoft.com. Query for "troubleshooting 1202 events".

Error 0x534 occurs when a user account in one or more Group Policy objects (GPOs) could not be resolved to a SID.  This error is possibly caused by a mistyped or deleted user account referenced in either the User Rights or Restricted Groups branch of a GPO.  To resolve this event, contact an administrator in the domain to perform the following actions:

1.    Identify accounts that could not be resolved to a SID:

From the command prompt, type: FIND /I "Cannot find"  %SYSTEMROOT%\Security\Logs\winlogon.log

The string following "Cannot find" in the FIND output identifies the problem account names.

Example: Cannot find JohnDough.

In this case, the SID for username "JohnDough" could not be determined. This most likely occurs because the account was deleted, renamed, or is spelled differently (e.g. "JohnDoe").

2.    Use RSoP to identify the specific User Rights, Restricted Groups, and Source GPOs that contain the problem accounts:

a.    Start -> Run -> RSoP.msc
b.    Review the results for Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment and Computer Configuration\Windows Settings\Security Settings\Local Policies\Restricted Groups for any errors flagged with a red X.
c.    For any User Right or Restricted Group marked with a red X, the corresponding GPO that contains the problem policy setting is listed under the column entitled "Source GPO". Note the specific User Rights, Restricted Groups and containing Source GPOs that are generating errors.

3.    Remove unresolved accounts from Group Policy

a.    Start -> Run -> MMC.EXE
b.    From the File menu select "Add/Remove Snap-in..."
c.    From the "Add/Remove Snap-in" dialog box select "Add..."
d.    In the "Add Standalone Snap-in" dialog box select "Group Policy" and click "Add"
e.    In the "Select Group Policy Object" dialog box click the "Browse" button.
f.    On the "Browse for a Group Policy Object" dialog box choose the "All" tab
g.    For each source GPO identified in step 2, correct the specific User Rights or Restricted Groups that were flagged with a red X in step 2. These User Rights or Restricted Groups can be corrected by removing or correcting any references to the problem accounts that were identified in step 1.

Advanced help for this problem is available on http://support.microsoft.com. Query for "troubleshooting 1202 events".

При установке компонента OCSP Responder роли Active Directory Certificate Services на контроллере домена создаются следующие локальные учётные записи:

• OCSPISAPIAppPool
• DefaultAppPool
• WdiServiceHost

Этим учётным записям автоматически в Default Domain Controllers Policy в разделе User Rights Assignments выдаются следующие права и привилегии:

Однако, эти учётные записи локальные и контроллер домена неспособен их разрешить в SID, т.к. они не доменные. Для решения этой проблемы нужно задать префикс authority этих учётных записей следующим образом:

Примечание: при добавлении этих записей вы должны вписывать эти имена прямо в поле Add user or group, а не использовать Browse и Check names.

Я пока не в курсе причины этой проблемы, но она отправлена на изучение в Windows Server Team, а пока – пользуйтесь этим решением :-)

На днях потребовалось поднять ещё один сервер CA на Windows Server 2008 R2 и на нём же OCSP респондер. Я уже писал про установку OCSP Responder в Windows Server 2008:

• OCSP (часть 1)
• OCSP (часть 2)

В принципе, настройка достаточно простая. Но мы обязаны периодически проверять работу этой службы и служб проверки статуса сертификата в целом. Для задач проверки работоспособности служб отзыва сертификатов у нас есть несколько решений, которые поставляются вместе с Windows, а так же инструменты сторонних разработчиков. Предлагаю вашему вниманию несколько таких инструментов.

PKIView.msc

Это стандартная MMC оснастка, которая устанавливается в систему с установкой роли Active Directory Certificates Services (для Windows Server 2008/R2) или с установкой Resource Kit (для Windows Server 2003). Что примечательно, ничего делать в этой оснастке не надо, достаточно её просто запустить и вы всё сразу увидите:

Данная оснастка собирает полную PKI иерархию в лесу (в моём случае это двухуровневая иерархия CA), считывает с них CDP и AIA списки и проверяет доступность сертификатов CA и списков CRL. Я специально удалил с сервера Base CRL список. И об этом мы бы узнали, скорее всего, только когда клиент не смог бы подключиться к SSL/TLS/IPSec ресурсу. А так – мы можем в любой момент проверить все CDP и AIA каждого сервера CA. И вот примерный образец, как должны выглядеть CDP и AIA для CA, который обслуживает клиентов из внешней сети:

Если внутри сети особого профита OCSP не получите, то для интернета он будет как нельзя кстати. Ну и для клиентов из интернета ваши LDAP пути для CRL никакого интереса не будут представлять. Т.е. мы имем классические CRL’ы и OCSP респондер. Собственно, статус Ok нам говорит, что с ним всё в порядке. Вы можете прямо из этой консоли выбрать правой кнопкой каждый пункт и посмотреть фактическое содержимое каждого CRL списка или CRT файла (CRT файлы в AIA требуются нам для построения цепочки сертификатов, т.н. certificate chain). Однако в отношении с OCSP мы видим только общую работоспособность респондера. Так же общую работоспособность можно проверить через оснастку Online Responder Mangement на каждом OCSP сервере. Но это всё на стороне сервера. А вот продиагностировать клиента (убедиться, что клиент работает в первую очередь с OCSP, а не с классическими CRL списками) здесь не получится и этому будет посвящена следующая часть этой статьи.

Certutil

Всем известная утилита Certutil.exe, которая поставляется не только с серверными операционными системами, но и с клиентскими тоже. К слову сказать, по сложности синтаксиса и богатством функционала с certutil.exe тягаться может разве что netsh.exe :-). К сожалению я не смог найти этой информации во встроенной справки certutil, поэтому пришлось искать альтернативные источники этой информации.

Итак, если мы хотим проверить работоспособность клиентского компьютера (напомню, что из клиентских ОС работать с OCSP могут только Windows Vista и выше), то нужно сначала экспортировать произвольный сертификат, который выдал проверяемый сервер CA в файл. После этого в командной строке набрать следующую команду:

certutil –url path\certificate.cer

и откроется следующее окно:

Я на сервере CA отозвал один сертификат и решил проверить, что мне на это скажет OCSP. Для этого в правой части выбираем, что хотим проверить статус сертификата с использованием только OCSP и нажимаем кнопку Retrieve. И в верхнем окне мы видим адрес OCSP сервера и статус проверямого сертификата. Как видите, он отозван. Администраторам PKI следует знать о богатейшем функционале certutil не только в теории, но и в практике тоже.

Кстати говоря, я себе сделал контекстное меню для .CER и .DER файлов, по которому вызывается эта утилита и можно будет сразу не отходя от кассы проверить сертификат или CDP/AIA того CA, который издал этот сертификат. Вот как выглядит .reg файл:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CERFile\shell\Check Certificate Revocation Status]

[HKEY_CLASSES_ROOT\CERFile\shell\Check Certificate Revocation Status\command]
@="certutil -url \"%1\""

Ascertia OCSP Client Tool

Когда вы PKI занимаетесь на достаточно серьёзном уровне, тогда приходят более другие инструменты цена у которых отлична от нуля и которые являются уже Enterprise инструментами, либо у вас клиент работает под ОС, которая не поддерживает OCSP (все ОС до Windows Vista). Один из таких инструментов – OCSP Client Tool от Ascertia. Вот как он выглядит:

Как видите, интерфейс достаточно простой, но в нём уже видны некоторые возможности. Это возможность проверки множества сертификатов в пределах одного запроса. Это означает, что каждый сертификат не будет проверяться отдельным запросом, а все Serial ID сертификатов (в пределах одинакового издателя) будут помещены в один OCSP запрос и OCSP так же одним ответом выдаст статус по каждому сертификату. Т.е. запросов будет ровно столько, сколько различных издателей присуствует в этом окне. Также возможно вместо индивидуального добавления сертификата добавлять цепочку сертификатов (certificate chain) в формате PKCS#7. Плюс, так же можно указать какой-то один OCSP респондер явно (ведь он может работать с несколькими CA), либо руководствоваться информацией об адресе OCSP респондера из поля AIA каждого сертификата. И ещё можно подписать сам запрос. Но нас больше будет интересовать, что именно мы можем проверить:

Мы можем проверить работу следующих компонентов:

• Nonce extension – это особый тип запроса, в который включается как ID проверяемого сертификата, так и уникальный номер запроса. OCSP респондер должен ответить клиенту сообщением, которое включает этот уникальный номер запроса. Плюс, это заставляет OCSP респондер игнорировать свой кеш, а выполнять полную сверку с CRL. По умолчанию в Windows-реализации OCSP Responder, такие запросы не поддерживаются, поскольку Windows-клиенты никогда не используют Nonce. Но вы можете включить поддержку таких запросов в консоли OCSP Responder.
• Add Service Locator extension – используется для извлечения AIA расширения и включения его в специальное поле запроса Service Locator.
• Check all certificates in PKCS#7 – при добавлении в основное окно не индвивидуальные сертификаты, а цепочку сертификатов, то эта опция разберёт эту цепочку на уникальные сертификаты.
• Verify signature on OCSP response – будет произведена проверка цифровой подписи OCSP-ответа с построением пути для этого сертификата до корневого CA.
• Сheck OCSP Responder authority to respond to CA – проверяется, что сертификат OCSP, которым подписан OCSP-ответ выдан тем же CA, которым выдан сам проверяемый сертификат. Этим проверяется, что OCSP респондер авторизован для конкретного CA для сообщения сведений о статусе сертификатов. Так же проверяется, что в EKU этого сертификата указано OCSP Signing.

Собственно и все основные настройки. Теперь нажимаем в основном окне Send Request и получаем много профита:

Собственно, тут всё видно, что к чему. В моём случае мой OCSP респондер прошёл все дополнительные проверки и попутно сообщил статус сертификата. В принципе, мне кажется, что данная утилита достаточно годная для проверки работоспособности и корректной настройки OCSP Responder. У меня пока есть только триал, а на счёт полной лицензии сведений не имею, т.к. господа в конторе не отличаются особой шустростью. Мне пришлось ждать 2 дня, чтобы получить только триал :rock: хотя, саппорт у них очень оперативный.

надеюсь, этот пост поможет вам подружиться с безусловно хорошей вещью, как OCSP Responder и научиться проверять его и работу сопутствующих компонентов :-)

Чуть не забыл про обещание выложить ответ тех.поддержки по поводу проблематики, изложенной в Секреты Software Restriction Policies (часть 5). Вот какой я получил ответ от них:

Hello Vadims,

My name is Rahul and I am from the Windows Core Team at GTSC.  I have been looking at this case for the Software Restriction Policy.

After some testing we have been able to recreate the behaviour that you are noticing:

This seems to be by design. On the Explorer.exe side, everything seems to be running ok.  We cannot launch the file types restricted via policy. This is because when ShellExecute comes into play, we enforce SRP policies. This is also true for the Windows Script Host, which does it's own checks apart from the shell.  Specifically regarding mshta.exe, we have the following situation:

- Since the shell is allowed to run lnk files, we do it ok;

- Since there's a specific additional rule that will allow us to run anything located under %windir%\system32, the shell can't enforce any SRP policy, since lnk files can be run.

- The shell starts mshta.exe, which, by its own, doesn't enforce the SRP policy, allowing the file to run.

This behaviour is by design.

итого, мы имеем следующее: как выяснилось, политика SRP не очень плотно накладывается на систему и внешние приложения должны сами проверять открытие своих файлов на соответствие правилам SRP. Если мы запускаем файлы через ярлыки. Что с успехом делают cmd.exe, msiexec.exe и cmd.exe. Но такие приложения, как regedit.exe, mshta.exe, hh.exe, mmc.exe ничего не знают о существовании SRP и неспособны произвести такую проверку. Понятно, что это by design (в чём я и не сомневался), но какой-то не очень удачный design. Вот так.