Программирование с использованием powershell

Contents of this directory is archived and no longer updated.

В первой части управления Certification Authority (CA) мы рассмотрели метод GetCAProperty, при помощи которого мы можем получать различные сведения про сервер CA. Сегодня мы посмотрим ещё несколько интересных моментов, которые будут связаны с CRL и опять будет немного треша с CryptoAPI, а именно:

• Получение статуса публикации CRL;
• Получение Base и Delta CRL из CA в виде файлов;
• Отзыв сертификатов;
• Извлечение сертификатов из CRL;
• Публикация новых CRL.

Всем привет, с вами Искандер Рустамов, младший системный администратор Cloud4Y. Сегодня мы будем покорять развертывание центра сертификации (ЦС).

Из-за сложной геополитической обстановки резко усилился процесс импортозамещения, появилась необходимость в выстраивании инфраструктуры на базе государственных требований к решениям в области информационной безопасности. Одним из таких решений является организация доступа клиентов к веб-ресурсам через портал nGate по защищённому TLS соединению с использованием шифрования по ГОСТ криптопровайдера «КриптоПро». Для этого необходим собственный центр сертификации.

В данной статье мы рассмотрим установку Standalone Center Authority на базе Windows Server 2019. Если вам будет интересно, могу описать процесс привязки нашего центра сертификации к порталу nGate (спойлер: на самом деле там нет ничего сложного).

Вводные данные

КриптоПро NGate — это универсальное высокопроизводительное средство криптографической защиты сетевого трафика, объединяющее в себе функционал:

• TLS-сервера доступа к веб-сайтам;
• Сервера портального доступа;

NGate обладает широкими возможностями по управлению доступом удалённых пользователей как с обеспечением строгой многофакторной аутентификации, так и прозрачно, обеспечивая при этом гибкое разграничение прав доступа к ресурсам. КриптоПро NGate реализует российские криптографические алгоритмы, сертифицирован по требованиям к СКЗИ, имеет сертификаты ФСБ России по классам КС1, КС2 и КС3 и может использоваться для криптографической защиты конфиденциальной информации, в том числе персональных данных, в соответствии с требованиями российского законодательства по информационной безопасности.

Кроме того, NGate:

• Снижает нагрузку по обработке TLS-соединений с веб-серверов, позволяя им сосредоточиться на выполнении своих основных задач;
• Исключает необходимость установки на каждом веб-сервере отдельного СКЗИ и проведения исследований по оценке влияния ПО веб-серверов на СКЗИ.

Здравствуйте. Есть стопка сертификатов, как для кучи юзеров, типа бухгалтеров, так и личных, для каждого юзера.

Терминальная ферма. Хочу как-то автоматизировать процесс установки.

Я имею PFX и установку произвожу через средства КриптоПро.

Start-Process -NoNewWindow -FilePath “C:Program FilesCrypto ProCSPcertmgr. exe” -ArgumentList “-inst -store uMy -pfx -file “C:CrtCert. pfx” -pin 123456 -silent”

И это работает. Соответственно я хочу положить допустим в C:Crt все сертификаты. Как-то циклом проходить и устанавливать юзерам.

На самом деле уже реализовал так:

Но каждый logon соответственно оно постоянно дозаписывает.

– Скорей всего, я могу проверять ключ названия сертификата в реестре. Проверять его, если не существует, пушить сертификат.

Почему-то до сюда не доходит ничего:

В общем как продумать логику импорта и написать код? Может кто-то, что-то подобное делал ?

Удостоверяющий центр «Росэлторг» выдает электронные подписи сотрудникам компаний и физическим лицам. За 2021 год это более 350 тысяч подписей.

Мы развиваемся уже 10 лет, в 2021 году получили аккредитацию Минцифры по новым правилам.

Наша команда старается, чтобы люди получали подпись быстро и удобно. Для этого запустили экспресс-выпуск за 1 час, доставку, корпоративный удостоверяющий центр. В 2022 году услуг и сервисов станет еще больше.

Мы ищем коллегу, который готов развивать направление вместе с нами в сильной команде.

Чем у нас предстоит заниматься:

Администрирование ПАК УЦ

• Администрирование ПАК УЦ КриптоПро 2.0;
• Администрирование КриптоПро DSS, КриптоПро HSM;
• Резервирование систем удостоверяющего центра (проектирование систем отказоустойчивости);
• Поддержание работы сетевого оборудования, крипто маршрутизаторов, WAF и пр.;
• Контроль правил эксплуатации ПАК-ов, своевременная замена сервисных сертификатов и пр.

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

• Поддержка, консультирование по алгоритмам взаимодействия систем с системами УЦ, по встраиванию методов API ПАК-ов УЦ в различные продукты, консультирование по работе ПАК внутренних и внешних заказчиков;
• Участие в реализации систем самообслуживания при заказе и получении сертификатов электронной подписи;
• Участие в внутренних проектах разработки и внедрения в них криптографических операций.
• Участие в расследовании инцидентов информационной безопасности и разборе конфликтных ситуаций, связанных с применением ЭП, СКЗИ.

• Высшее образование (желательно по профилю информационной безопасности);
• Знание ОС Windows Server на уровне администрирования;
• Знания СКЗИ Крипто-Про, VipNet;
• Бонусом будет умение автоматизировать работу с помощью PowerShell, VBS;
• Опыт работы с VIPNet (АПКШ «Континент» и др.);
• Опыт использования PKI-решений;
• Аналогичный опыт от одного года;
• Знание 795 Приказа ФСБ, 63-ФЗ.

• Стабильность. Официальное трудоустройство с «белой зарплатой», гибкое обсуждение условий, понятная система мотивации;
• Поддержка команды. Работа с экспертами, конструктивная обратная связь, готовность к новым решениям и интересные задачи;
• Разнообразие в задачах и проектах, возможность по-максимуму задействовать свой потенциал;
• Комфортные условия. Современный офис рядом с м. Павелецкая, работа в офисе, начало рабочего дня с 9:30 – 18:30

String was not recognized as a valid DateTime. System. FormatException: String was not recognized as a valid DateTime. at System. DateTimeParse. Parse

Данная ошибка может возникать в следующих случаях:

• если на различных узлах кластера DSSустановлен различный системный язык или формат языковых параметров;
• если разворачивается дополнительный узел кластера DSS с отличным от других узлов системным языком или форматом языковых параметров;
• если происходит смена языка или формата языковых параметров на сервере с установленным DSS.

Определить, под какой учетной записью работает приложение DSS, в котором была обнаружена ошибка.

Для этого перейдите в Диспетчер служб IIS. На странице «<Имя сервера> – Пулы приложений» найдите приложение, для которого возникла ошибка. В столбце «Удостоверение» напротив данного приложения будет отображено имя учетной записи, под которой оно работает.

Определить, какой формат языковых параметров был установлен при разворачивании DSS.

Для этого в консоли PowerShell, запущенной от учетной записи (см. 1), выполните следующую команду: (Get-DssCryptoProvider). settings

В выводе настроек криптопровайдера содержится срок действия ключа. В зависимости от формата записи данного срока действия определите формат даты и времени, использованный при разворачивании DSS (например):

* MasterKeyLifeTimeEnd 10/20/2024 12:36:37 AM – формат даты и времени США;

* MasterKeyLifeTimeEnd 20. 2024 0:34:35 – международный формат даты и времени (включая Россию).

Внимание! Данный способ позволяет с высокой вероятностью, но не гарантированно определить использованный при разворачивании DSSформат языковых параметров.

Измените формат языковых параметров на тех узлах кластера, где выявлено несоответствие. Пересоздавать экземпляры сервисов не требуется. Выполните следующие действия:

Перейдите в «Панель управления» и найдите (при помощи поиска или в режиме просмотра «Крупные значки») меню «Региональные стандарты». Перейдите в «Региональные стандарты».

На вкладке «Форматы» выберите формат даты и времени, соответствующий формату записи срока действия ключа из п. Примените настройки.

На вкладке «Дополнительно» нажмите кнопку «Копировать параметры».

Установите чекбоксы «Экран приветствия и системные учетные записи» и «Новые учетные записи пользователей» и нажмите «ОК».

В консоли PowerShell выполните следующую команду: iisreset

КриптоПро SSF (Secure Store and Forward) – это программный комплекс, позволяющий использовать средство криптографической защиты информации (СКЗИ) КриптоПро CSP в продуктах компании SAP AG.

КриптоПро SSF обеспечивает криптографическую защиту электронных документов с использованием российских криптоалгоритмов (ГОСТ 28147-89, ГОСТ Р 34. 11-94 / ГОСТ Р 34. 11-2012, ГОСТ Р 34. 10-2001 / ГОСТ Р 34. 10-2012 ).

• предназначен для защиты открытой информации в информационных системах общего пользования (вычисление и проверка электронной подписи) и защиты конфиденциальной информации, не содержащей сведений, составляющих государственную тайну, в корпоративных информационных системах;
• позволяет создавать и проверять как обычную электронную подпись, так и усовершенствованную электронную подпись;
• используется для оборудования автоматизированных рабочих мест пользователей программных продуктов, построенных на платформе SAP Netweaver ABAP (SAP ERP, SAP SRM, SAP CRM, SAP SCM), и выступает как программная “обертка” прикладных данных, применяющихся в различных сценариях для защиты данных и документов с использованием механизмов на основе сертификатов X.509 и электронной подписи:
  идентификация пользователей и процессов систем документооборота;электронная подпись прикладных данных, обрабатываемых в решениях SAP;хранение данных в защищенном формате;защищенная передача данных через публичные сети;гарантирование аутентичности и целостности данных.
• идентификация пользователей и процессов систем документооборота;
• электронная подпись прикладных данных, обрабатываемых в решениях SAP;
• хранение данных в защищенном формате;
• защищенная передача данных через публичные сети;
• гарантирование аутентичности и целостности данных.

Программное средство применения электронной подписи КриптоПро SSF представляет собой модуль динамически подгружаемой библиотеки, реализующей интерфейс (API) “Secure Store & Forward (SSF)” и обеспечивающей в соответствие с этим выполнение следующих задач:

• Формирование и проверку усиленной квалифицированной электронной подписи данных;
• Шифрование и расшифрование данных;
• Вычисление значения хэш-функции;
• Поддержку формата криптографических сообщений согласно RFC 3852 “Cryptographic Message Syntax (CMS)” с учетом RFC 4490 “Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)”;
• Поддержку формата криптографических сообщений усовершенствованной электронной подписи – CAdES X Long (“CMS Advanced Electronic Signatures”) с фиксацией времени подписания электронного документа посредством реализации протокола TSP согласно рекомендациям RFC 3161 (“Internet X.509 Public Key Infrastructure, Time-Stamp Protocol (TSP)”) и сохранением информации о статусе сертификата ключа проверки ЭП подписчика на момент времени подписания электронного документа посредством реализации протокола OCSP согласно рекомендациям RFC 2560 (“Internet X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP”) и хранением всех доказательств подлинности этой электронной подписи.

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

КриптоПро SSF функционирует в среде следующих операционных систем:

• Microsoft Windows 2000 и выше,
• ОС семейства Linux, удовлетворяющих LSB 3.1 и выше,
• FreeBSD 7.x и выше,
• AIX 5.3 и 6.x и выше,
• Solaris 10 и выше,
• Apple MacOS 10.6 и выше.

КриптоПро SSF использует сертифицированные ФСБ России средства криптографической защиты КриптоПро CSP 3. 6, КриптоПро CSP 3. 9 или более поздние версии.

Служба проверки сертификатов и электронной подписи КриптоПро SVS имеет следующие
ключевые особенности:

• Реализует проверку сертификатов и электронной подписи с учётом использования российских криптографических алгоритмов.
• Использует встроенный веб-сервер Microsoft IIS, поддерживающий различные методы аутентификации и протокол TLS (SSL).
• Поддерживает развёртывание нескольких экземпляров службы на одном компьютере.
• Может получать информацию о статусах сертификатов из следующих источников:
• Локально установленные списки отзыва сертификатов (CRL);
• CRL, доступные по сети;
• Сервисы OCSP.
• Процесс проверки статусов сертификатов реализуется средствами ОС Windows и средствами КриптоПро PKI SDK (см. документ ЖТЯИ.00094-01 90 10. «Службы УЦ. КриптоПро PKI SDK. Руководство разработчика»).
• Устанавливается с помощью Windows Installer.

Поддерживаемые форматы электронной подписи

КриптоПро SVS поддерживает следующие форматы электронной подписи:

• Подпись формата CMS (PKCS#7/CAdES-BES)Присоединенная подпись;Отделенная подпись;
• Присоединенная подпись;
• Отделенная подпись;
• Усовершенствованная подпись (CAdES-T, CAdES-X Long Type 1);Присоединенная подпись;Отделенная подпись;
• Подпись XML-документов (XML Digital Signature, XMLDSig);
• Необработанная (чистая) электронная подпись ГОСТ Р 34.10-2012 (и ГОСТ Р 34.10–2001);
• Подпись документов PDF (CAdES-BES, CAdES-T, CAdES-X Long Type 1);
• Подпись документов Microsoft Office (Word и Excel).

ПримечаниеБолее детальная информация о поддерживаемых форматах подписи и ссылки на нормативную
документацию содержатся в разделе 11
документа “ЖТЯИ. 00096-02 96 02 КриптоПро DSS. Общее описание”.

Возможности КриптоПро SVS

На сервере, обеспечивающем работу КриптоПро SVS, устанавливаются следующие компоненты:

• Веб-интерфейс Пользователя,
• REST-сервис проверки подписи.

Настройка конфигурации и администрирование сервиса производится с помощью Windows
PowerShell.

КриптоПро SVS использует встроенный в ОС механизм проверки цепочки сертификатов,
используя собственное хранилище корневых сертификатов УЦ. Это означает, что необходимые
для построения цепочки сертификаты, CRL или OCSP-ответы берутся из системных хранилищ или
скачиваются автоматически.

При проверке документов в веб-интерфейсе КриптоПро SVS в браузере может отображаться
содержимое документов. Поддерживаются следующие форматы документов:
PDF, DOC, DOT, DOCM, DOTM, DOCX, DOTX, XML, FlatOpc, FlatOpcMacroEnabled, FlatOpcTemplate,
FlatOpcTemplateMacroEnabled, ODT, OTT, OOXML, WordML, RTF, HTML, XHTML, MHTML и TXT.

Набор отображаемых документов может быть расширен путём написания плагинов
для нужных форматов.

В качестве криптопровайдера может быть использовано СКЗИ «КриптоПро CSP» версии 5. 0 R2
варианта исполнения 2-Base или 3-Base.

В качестве OCSP-сервера может использоваться КриптоПро OCSP Server или другая совместимая
служба OCSP, соответствующая требованиям RFC 6960. Проект
Рекомендаций по стандартизации, устаналивающий требования к службам OCSP, использующим
российские криптографические алгоритмы, находится в разработке и доступен в виде проекта.

Требования к клиентскому рабочему месту

Операции верификации сертификата ключа проверки электронной подписи и подтверждения
подлинности электронных подписей документов выполняются на стороне сервера, что не требует
установки на компьютер клиента специализированного программного обеспечения (например,
КриптоПро PDF, КриптоПро Office Signature, КриптоАРМ). Вся работа клиента с КриптоПро SVS
производится через веб-браузер.

Для обеспечения доверия к ответам сервиса КриптоПро SVS взаимодействие с ним может
производиться по протоколу TLS.

Ролевая модель

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

ПримечаниеРоли Администратора SVS, Системного администратора, Оператора резервного копирования
и Аудитора могут принадлежать как одному сотруднику, так и быть разделены между несколькими
лицами.

Код курса.

У каждого курса есть свой уникальный международный код. Зная этот код вы можете быстро найти курс в форме поиска.

31 окт. Москва

• Описание
• Программа
• Формы обучения
• Расписание
• FAQ

Курс посвящен изучению основ работы с PowerShell в Windows для развертывания, настройки и управления ПАК “Криптопро УЦ” 2. Применению PowerShell в Windows для настройки ПАК “КриптоПро Службы УЦ”, а также ПАК “КриптоПро DSS”.

Более 50% учебного времени уделяется практическим работам, в рамках которых слушатели решают прикладные задачи.

Программа учебного курса ориентирована на специалистов структурных подразделений, планирующих (расширяющих) использование, внедряющих ПАК “Криптопро УЦ” 2. 0, ПАК “Криптопро Службы УЦ”, а также ПАК “КриптоПро DSS” или приступающих к самостоятельной эксплуатации внедренных на предприятии ПАК “Криптопро УЦ” 2. 0, ПАК “Криптопро Службы УЦ”, а также ПАК “КриптоПро DSS”.

Базовые знания и навыки по работе с Windows.

Для глубокого освоения материала рекомендуется прослушать курсы:

• КП06 ” Использование ЭП и PKI”;
• Т012 “Порядок развертывания и применения PKI на основе ПАК “КриптоПро УЦ” 2.0″;
• Т331 “Порядок развертывания и применения PKI для облачной электронной подписи на основе технологий КриптоПро”.

Вы приобретете знания:

• По основам работы с PowerShell в Windows.
• По применению PowerShell в Windows для развертывания, настройки и управления ПАК “Криптопро УЦ” 2.0.
• Применению PowerShell в Windows для настройки ПАК “КриптоПро Службы УЦ”, а также ПАК “КриптоПро DSS”.

• Проводить настройку взаимодействия Центра Сертификации с Центром Регистрации с применением PowerShell.
• Осуществлять управление Центром Регистрации с помощью PowerShell.
• Проводить настройку Консоли управления ЦР c помощью PowerShell.

• Раздел 1. Windows Powershell. Интегрированная среда сценариев Windows PowerShell Windows PowerShell (ISE). Модули Windows PowerShell. Политики выполнения Windows PowerShell. Основы работы с PowerShell в Windows.
• Раздел 2. Управление ПАК “Криптопро УЦ” 2.0 с помощью PowerShell. Управление Центром Сертификации с помощью PowerShell. Настройка взаимодействия Центра Сертификации с Центром Регистрации с применением PowerShell. Управление Центром Регистрации с помощью PowerShell. Настройка Консоли управления ЦР c помощью PowerShell.
• Раздел 3. Настройка ПАК “КриптоПро УЦ” 2.0 с помощью PowerShell. Управление режимами выпуска сертификатов. Настройка контроля уникальности пользователей c помощью PowerShell. Настройка форм документов c помощью PowerShell. Выпуск квалифицированных сертификатов c помощью PowerShell. Настройка совместимости с ИВП КриптоПро УЦ версии 1.5 c помощью PowerShell. Настройка политики криптопровайдеров c помощью PowerShell.
• Раздел 4. Применение PowerShell в элементах управления инфраструкторой ЭП на основе технологий КриптоПро. Применение PowerShell в ПАК Службы УЦ 2.0. Применение PowerShell в ПАК “КриптоПро DSS”.

Доступные формы обучения

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

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

Смешанный формат позволяет оптимизировать процесс обучения и сократить время на ежедневную логистику «до» и «от» учебного центра в часы пик.

Выберите удобную для вас дату

Если в расписании нет удобных для Вас дат, напишите нам – мы разработаем удобные варианты специально для Вас!

По окончании обучения слушатели получают либо Сертификат Учебного Центра о прохождении курса, либо Удостоверение о повышении квалификации, зарегистрированное в ФРДО
(Федеральный
реестр сведений о документах об образовании и (или) о квалификации, документах об обучении). Для получения Удостоверения необходимо, чтобы длительность обучения превышала 16
академических часов, а также необходимо предоставить оригинал Диплома о профессиональном или высшем образовании государственного образца.

Помимо этого, по факту прохождения авторизованных курсов вендоров Cisco, Postgres, AstraLinux, Microsoft, ICAgile выдается электронный сертификат вендора.

Возьмите паспорт и Диплом об окончании профессионального или высшего образования. Диплом понадобится для получения Удостоверения о повышении квалификации (в случае отсутствия
Диплома, по окончании курса будет выдан Сертификат Учебного Центра, подтверждающий факт пройденного обучения).

За несколько дней до начала обучения (обычно за неделю) все слушатели получают приглашение по указанной электронной почте (если обучение заказывалось централизованно, ваш
персональный мейл могли не передать – обратитесь к специалисту вашей организации, кто заказывал курсы, приглашение есть у него). В приглашении указан адрес и прочая полезная
для
слушателя информация. Если вы не получили приглашение – обратитесь к нам любым удобным для вас способом, и мы сообщим адрес и продублируем приглашение на вашу почту.

В основном корпусе в Москве по адресу Дербеневская набережная д. 7 стр. 5, БЦ «Оазис», парковки, к сожалению, нет. Зато есть муниципальная платная парковка на всех прилегающих
улицах.

По поводу остальных филиалов и корпусов – уточняйте информацию у наших менеджеров. Мы постараемся сделать всё возможное для вашего комфортного обучения.

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

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

Обо всех специальных условиях читайте в разделе Спецпредложения.

Недостаточно информации? Напишите нам, и мы сделаем вам предложение, от которого невозможно отказаться.

Не нашли подходящиего курса?

Оставьте заявку на обучение для вашей организации

Подпишитесь и будьте в курсе

Информация о новинках, скидках и акциях. Уже более 36 000 подписчиков!

Получение Base и Delta CRL из CA в виде файлов

Далее мы должны узнать PropID, который бы отвечал за показ CRL вот по этой ссылке: 3. 2 ICertRequestD2::GetCAProperty (Opnum 7). Нас будет интересовать 2 этих ID: CR_PROP_BASECRL (0x11) и CR_PROP_DELTACRL (0x12). Поскольку тип возвращаемых данных будет Binary, то PropType будет равен 3, а Flags выставим в 0 (Base64CRLHeader). Можно и другой указать, от этого только зависит метод записи в файл.

Примечание: напоминаю, что индекс PropType начинается с 1, а Flags с 0 и их возможные значения описаны здесь: GetCAProperty. А так же то, что в Flags первые 2 значения перепутаны местами на MSDN.

И вот как мы их можем получить:

последние 2 команды просто запускают эти CRL файлы. К сожалению не существует ни одного родного класса, который бы представлял собой объект CRL, поэтому как-то разбирать его на таком уровне пока не представляется возможным. Хотя существуют сторонние библиотеки (например, в Mono есть класс X509CRL).

Извлечение сертификатов из CRL

Примечание: хоть Microsoft и поддерживает извлечение сертификатов из CRL (отмена статуса Revoked), этой возможностью не следует пользоваться в силу определённых причин, как невозможность определеления в какое время сертификат был помещён и извлечён из CRL.

Если сертификат был отозван со статусом Certificate Hold (6), то его можно в любое время вернуть обратно. Для всех остальных типов отзыва такая возможность не поддерживается. Для отмены статуса Revoked нужно использовать этот же метод, только в качестве причины отзыва указать значение MAX_DWORD, которое является 0xffffffff или просто –1:

Установка центра сертификации (Standalone CA Windows Server 2019)

Непосредственно перед самой установкой коротко объясню особенности Standalone CA:

• Не интегрирован с Active Directory (а он нам и не нужен);
• Публикация сертификатов происходит через запрос на WEB-сайте. Путем автоматического или ручного подтверждения администратором ЦС (ЕМНИП, ЦС предприятия было добавлена такая возможность, не проверял её работу);
• Пользователь сам вводит идентификационную информацию во время запроса сертификата;
• Не поддерживает шаблоны сертификатов (из-за этого всплывут некоторые моменты, которые раскрою в процессе развертывания).

Измените имя компьютера до установки роли, после это будет сделать невозможно. «Далее (Next)» (рис. 2):

Рисунок 2. Уведомления при установки роли.

Добавляем роль в «Диспетчере серверов» (Server Manager), «Далее (Next)» (рис. 3):

Рисунок 3. Интерфейс «Диспетчера устройств» (Server Manager)

«Установка ролей и компонентов (Add roles and features wizard)». Нажимаем «Далее (Next)» – «Далее (Next)»;

«Тип установки: Установка ролей и компонентов (Installation type: Role-based or features-based installation». «Далее (Next)»;

«Выбор сервера (Server selection)». В нашем случае среди предложенных будет один сервер и имя компьютера. «Далее (Next)» (рис. 4);

Рисунок 4. «Выбор сервера (Server selection)»

«Роли сервера (Server roles). Здесь необходимо отметить две роли: Служба сертификатов Active Directory (Certificate Services Active Directory), Веб-сервер IIS (Web-server IIS);

Во всплывающем окне перечня нажимаем «Добавить компонент (Add features)» – «Далее (Next)»;

«Компоненты (Features) оставляем как есть — «Далее (Next)» ;

«Служба ролей (Role Services)» ЦС, необходимо выбрать:

• «Центр сертификации (Certification Authority)»,
• «Служба регистрации в центре сертификации через Интернет (Certification Authority Enrollment)»;

Сетевой автоответчик (Online responder) добавим уже после развертывания ЦА, в противном случае могут возникнуть проблемы.

В «Служба ролей (Role Services)» веб-сервера оставляем всё предложенное автоматически — «Далее (Next)»;

«Подтверждение (Confirmation).

На этом этапе запустится процесс установки роли.

После установки роли центра сертификации необходимо его настроить(рис. Выбираем:

«Настроить службы сертификатов Active Directory (Configure Active Directory-Certificate Services)

Рисунок 5. Уведомление о необходимости настройки центра сертификации

Выбираем установленные службы ролей для настройки (Select role services to configure) ЦС: «Центр сертификации (Certification Authority)», «Служба регистрации в центре сертификации через Интернет (Certification Authority Enrollment)»;

При выборе центра сертификации появится окно выбора ключевого носителя – КриптоПРО CSP, в качестве носителя для создания контейнера cngWorkAround используем хранилище ключей реестра Windows – Реестр. (рис

Рисунок 6. Выбор ключевого носителя – КриптоПРО CSP

Указываем вариант установки ЦС (Specify the setup type of the CA): Автономный центр сертификации (Standalone CA). «Далее (Next)»;

Указываем тип ЦС (Specify the type of CA) – Корневой ЦС (Root CA). «Далее (Next)»;

Необходимо создать закрытый ключ ЦС, чтобы он мог создавать и выдавать их клиентам. Для этого выбираем «Создать новый закрытый ключ (Create a new private key)».

В качестве поставщика службы шифрования выбираем один из трёх предложенных (не забывайте, что 2001 год уже устарел) Crypto-Pro GOST R 34. 10-2012 Strong Cryptographic Service Provider с длиной 512 и открытого ключа 1024 бита. (рис

Рисунок 7. Выбор криптопровайдера

Укажите имя центра сертификации и суффиксы различающего имени, данные суффиксы будут отображаться в составе сертификата в графе «Издатель (Issuer)».

СN = Certificate Name, O = Organization, L = Locale, S = Street, C = Country, E = E-mail; (рис

Указываем необходимый «срок годности (validaty period)» корневого сертификата (в нашем случае было выбрано 15 лет). «Далее (Next)»;

Указываем расположение баз данных сертификатов (certificate database location). «Далее (Next)»;

В окне «Подтверждения (Confirmation) сверяем введённую информацию – «Настроить (Configure)»

Появится окно выбора носителя для создания контейнера нашего ЦС.

Где хранятся сами контейнеры ключей:

Реестр: (в качестве хранилища ключей используется реестр Windows), путь хранения контейнеров ключей следующий:Ключи компьютера: HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCryptoProSettingsKeys

Далее откроется окно генерации начальной последовательности с помощью биологического ДСЧ. Для генерации случайной последовательности перемещайте указатель мыши или нажимайте различные клавиши.

После введите пароль на доступ к закрытому ключу.

Далее появится окно результатов об успешной установке компонентов (рис

Рис. Результаты установки

Настройка веб-сервера IIS

Теперь необходимо выполнить некоторые настройки веб-сервера: прицепить сертификат (самоподписанный или выпущенный нашим же ЦА). Кстати, он уже работает. В качестве примера выпустим самоподписанный сертификат.

Откроем Диспетчер служб IIS (Manager IIS) — Сертификат сервера (Server Certificates) (рис. 9);

В открывшемся окне в панели «Действия (Actions)» выберем – «Создать самоподписанный сертификат (Create Self-Signed Certificate);

Выбираем тип «Личный (Personal) и указываем «Имя сертификата (Friendly Name)»

Рисунок 9. Диспетчер служб IIS (IIS Manager)

Также сертификат вы можете выпустить следующим образом:На этой же панели создайте запрос (Create certificate request) для выпуска сертификата через наш ЦА и дальнейшей его загрузки в IIS (Complete Certificate Request). Но это по желанию.

Пример запроса (request) для формирования запроса вручную

В целом с веб-сервером мы закончили, в default web site вы можете увидеть, что были автоматически созданы virtual directory и applications «CertSrv». При желании можно создать отдельную виртуальную директорию под CRL’ки.

Настройка OCSP — сетевого ответчика (Online responder)

Так как у Standalone центра сертификации нет шаблонов, нам необходимо вручную сформировать запрос и выпуск сертификата для конфигурации отзыва (Array configuration) в «Управление сетевым ответчиком (Online responder management). Для это используйте следующую конфигурацию для формирования запроса

Создайте: ocsp. txt cо следующим внутренним содержанием:

Откройте командную строку cmd. Перейдите в директорию с текстовым файлом или в будущем просто укажите полный путь при формировании запроса.

Узнаем, на какой срок сейчас выпускаются сертификаты. Для этого воспользуемся командой – certutil –getreg caalidityperiodunits

Результат — на рис.

Рисунок 15. В текущей конфигурации сертификаты выпускаются на один год

Изменим длительность выпуска сертификата:

#Изменение выпуска сертификатов с текущего состояния на длительность в 5 лет
certutil -setreg caValidityPeriodUnits 5
#Перезапуск сервера
net stop certsvc
net start certsvc

Сформируем запрос и выпустим сертификат для сетевого автоответчика (рис 16

Во время конфигурирования запроса выбираем место хранения контейнера ключа и проходим процедуру ДСЧ.

Рисунок 16. Выпуск сертификата для сетевого автоответчика

Экспортируем сертификат из центра сертификации и устанавливаем его в личные сертификаты локального компьютера.

После запроса сертификата открываем оснастку: Certificates (Run – MMC – Add or remove Snap-ins – Certificate),

Выбираем сертификат, выданный для сетевого ответчика. Нажимаем правой клавишей и открываем «Все задачи (Управление закрытыми ключами (All Tasks – Manage Private keys)».

Это нужно сделать, так как служба OCSP работает от лица Network Service.

Рисунок 16. Настройка сертификата для  работы сетевого ответчика

Далее переходим в настройки самого сетевого ответчика. (рис. 17)

Нам необходимо добавить «Конфигурацию отзыва (Revocation Configuration) – «Добавить»

Предстоит небольшой процесс настройки конфигурации отзыва.

Введите имя конфигурации – «Далее».

Выбираем второй пункт: «Выбрать сертификат в локальном хранилище сертификатов (Select a certificate from the local certificate store)» – «Далее».

В следующем окне нажимаем «Обзор (Browse)» и выбираем корневой сертификат нашего ЦА – «Больше вариантов (More choices)». (рис. 17) – «Далее».

В следующем окне выбираем «Выбрать сертификат подписи вручную (Manually a signing sertificate)

Рисунок 17. Управление сетевым ответчиком. (online responder management)

Рисунок 18. Прикрепляем конфигурации корневой сертификат ЦА

Осталось прицепить к нашей конфигурации выпускаемый ранее сертификат и проверить некоторые моменты.

Переходим в «Конфигурацию массива(array configuration)», выбираем конфигурацию и нажимаем «Назначить сертификат подписи (Assign Signing Certificate)». В появившемся окне нужно просто нажать «ОК».

Теперь необходимо «Обновить конфигурацию массива». Для этого выбираем «Конфигурация массива (Array configuration) – «Обновить (Refresh)»

После всех этих действий главное окно оснастки ocsp должно выглядеть так, как на рисунке 19.

Рисунок 19. Итоговый результат о работе сетевого ответчика

В процессе самостоятельной настройки «сетевого ответчика» может возникнуть много вопросов, особенно если нет опыта работы с Standalone центром сертификации, в котором отсутствуют шаблоны, без которых можно обойтись, но пути становятся длиннее в исполнение. Кстати говоря, если после прикрепления сертификата вы не получили заветное Working, то проверьте следующее (рис. 20, 20. 1):

Рисунок 20. Переходим в редактирование свойств конфигурации отзыва

Рисунок 20. Проверяем что в разделе «Подписи» выбран ГОСТ алгоритм шифрования

Чтобы проверить работу центра сертификации и сетевого автоответчика, выпустите сертификат для конечного пользователя, установите его и экспортируйте в какую-нибудь директорию. А после воспользуйтесь утилитой: Certutil –url /patch/test. crt

Для подробного отчёта вы можете воспользоваться: certutil –verify –urlfetch /patch/test. crt

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

Что ещё интересного есть в блоге Cloud4Y

Публикация новых CRL

Если вы хотите опубликовать новые CRL вручную (т. в промежутке между плановой публикацией CRL), то мы должны воспользоваться методом PublishCRLs(). Его синтаксис достаточно простой:

Эта команда переопубликует как основной, так и инкрементальный CRL (при публикации Base CRL инкрементальный CRL публикуется всегда, потому что Effective Date у него не может быть меньше, чем у Base CRL). Что касается последнего аргумента, то он бывает ещё полезен, если по каким-то причинам потерялся какой-то файл CRL. Тогда вы можете выставить CRLFlags в 4 (0x4) и тогда CA переопубликует текущие CRL без обновления их содержимого и дат.

На сегодня это всё.

Установка сетевого ответчика (Online responder)

А вот мы и вернулись к установке автоответчика.

Добавляем роль в «Диспетчере серверов» (Server Manager) – «Далее (Next)»

Установка ролей и компонентов (Add roles and features wizard)» – «Далее (Next)»;

«Роли сервера (Server roles), раскрываем роль: Служба сертификатов Active Directory (Certificate Services Active Directory); и устанавливаем галочку на «Сетевой ответчик» (Online Responder)

Завершаем работу с мастером ролей и компонентов, путём односмысленных нажатий «Далее (Next)».

В IIS была добавлена Applications: ocsp. Только не пугайтесь, что сама по себе директория пустая. Так и должно быть.

Нам осталось настроить центр сертификации и выпустить сертификат на OCSP.

Получение статуса публикации CRL

Но мы можем кое что узнать о статусе наших CRL. Для этого существует PropID = CR_PROP_CRLSTATE (0x14). Тип возвращаемых данных будет Long, значит PropType будет 1, а Flags будет игнорироваться, поэтому поставим его в 0:

Расшифровку этого значения можно найти здесь:  3. 20 PropID = 0x00000014 (CR_PROP_CRLSTATE) “CA CRL State”. Число 3 означает, что с CRL у нас всё хорошо (CA_DISP_VALID (0x03)). В принципе, на данном этапе нам больше ничего и не нужно. Но мы можем посмотреть более детальные сведения по каждому типу CRL. Для получения более детальной ошибки мы должны использовать следующие PropID:

• CR_PROP_BASECRLPUBLISHSTATUS (0x1E)
• CR_PROP_DELTACRLPUBLISHSTATUS (0x1F)

Для этих PropID тип данных так же указан Long, поэтому PropType выставим в 1, а Flags в 0:

Мы получили число 5 для BaseCRL и 6 для DeltaCRL. Расшифровку этих значений можно посмотреть вот здесь: 3. 30 PropID = 0x0000001E (CR_PROP_BASECRLPUBLISHSTATUS) “Base CRL Publishing Status”. Поскольку вывод — не конкретное число, а результат двоичного оператора И (AND), то мы это число должны разбить на составляющие. И вот как это делается:

“The CRL is a base CRL”
“The CRL is a delta CRL”

“The CRL is a shadow delta CRL”
“The CA MAY publish the CRL to a local store that is not externally accessible. This error is returned when publishing to this intermediate store failed”
“An error occurred during publication of the CRL. The error indicates that the file schema cannot be recognized. The schema must be file: or ldap:”

“A CRL signature error was detected. The CSP was not correct”
“An error occurred during publication of the CRL to an LDAP URL”
“An error occurred during publication of the CRL to a file URL”
“An error occurred during publication of the CRL to an FTP URL. FTP URLs are not supported”

Следовательно число 5 (1+4) говорит нам о том, что это был Base CRL и он был опубликован успешно. А 6 (2+4) — Delta CRL был опубликован успешно.

Процесс настройки

Ранее я не сталкивался с центрами сертификациями. Поскольку ОС Windows Server мне ближе, решил развернуть ЦС с использованием Server Manager. Разворачивать контроллер домена не нужно, так как сертификаты будут выдаваться внешним пользователям. Соответственно, можно обойтись «автономным» центром сертификации, подробнее о нём расскажу позже.

Перед развертыванием центра сертификации необходимо:

• Установить СКЗИ КриптоПро CSP 5.0.12330:
• Установить КриптоПро ЭЦП Browser plug-in;

Инсталляцию производим через «Дополнительные опции»

• Выбираем язык установки, уровень защиты КС1 (другие уровни защиты требуют дополнительных аппаратных средств защиты);
• В разделе «Установка компонентов» проверяем, что добавлен «Криптопровайдер уровня ядра ОС»; (рис. 1)

Рисунок 1. Установка дополнительных компонентов «КриптоПро CSP»

Криптопровайдер уровня ядра ОС необходим для работы криптопровайдера в службах и ядре Windows.

В следующем окне оставляем пункты:

• Зарегистрировать считыватель «Реестр» (позволит сохранять контейнеры ключей в реестр);
• Усиленный контроль использования ключей;
• Не разрешать интерактивные сервисы Windows;

Также «КриптоПро» предложит добавить сертификаты своих центров сертификации;

Устанавливаем, перезагружаемся.

Настройка центра сертификации

В «Диспетчере серверов (Server manager)» – выбираем «Служба сертификации Active Directory (AD CS) – правой клавишей по вашему серверу и открываем: «Центр сертификации (Certification Authority).

Вы попали в оснастку управления центром сертификации: certsrv.

Выбираем ваш центр сертификации и открываем свойства (рис. 10):

Рисунок 10. Настройка центра сертификации. Оснастка управления центром сертификации certsrv.

Следующим важным шагом выступает настройка точек распространения CDP и AIA.

Authority Information Access (AIA) — содержит ссылки на корневой сертификат центра сертификации (Certification Authority)

CRL Distribution Point — содержит ссылки на файлы CRL, которые периодически публикует сервер CA, который издал рассматриваемый сертификат. Этот файл содержит серийные номера и прочую информацию о сертификатах, которые были отозваны. (рис. 11)

Мы используем веб-сервер, который доступен как внутри сети, так и из интернета (так как сертификаты могут использоваться пользователями интернета) по одному и тому же URL.

В разделе свойства переходим в «Расширения (Extensions):

Удаляем ненужные точки распространения и оставляем локальную и внешнюю ссылку для CDP:

Ставим галочки «Включить в CRL. Включить в CDP (Include in CRL. Include in the CDP)».

Ставим галочку: «Включать в AIA- расширение выданных сертификатов (Include in the AIA extension of issued certificates)»

Ставим галочку: «Включать в расширение протокола OCSP (Include in the online certificate status protocol (OCSP) extension)»

Рисунок 11. Настройка точек распространения AIA и CRL

В свойствах центра сертификации можно настроить автоматический выпуск сертификатов при поступившем запросе. Так вы исключаете возможность проверки указанных требуемых полей сертификатов. Для этого перейдите в «Модуль политик (Policy Module)» — «Свойства (Properties)» и выберите соответствующий пункт:

В первом случае сертификату присваивается режим ожидания, а одобрение выпуска сертификата остается за администратором;

Во втором случае из-за отсутствия шаблонов в Standalone CA сертификаты будут выпускаться автоматически. (рис. 12)

Рисунок 12. Дополнительные настройки ЦС для автоматического выпуска сертификатов

Да, центр сертификации уже функционирует и доступен по указанному dns-имени. Не забудьте открыть 80 и 443 порты для функционирования веб-сервера и online-reposnder’a, настройкой которого мы займёмся далее.

При переходе по ссылке извне в IE необходимо добавить наш веб-сервер в «Надежные сайты (Trusted Sites)» в настройках в пункте «Безопасность». Не забудьте, что должен быть установлен КриптоПро CSP, в ином случае при выпуске сертификата вам не будет доступен выбор ГОСТовского криптопровайдера (рис. 13).

Рисунок 13. Веб-интерфейс центра сертификации. Формирование запроса. Правильное отображение

Вернёмся в оснастку certsrv к нашему центру сертификации и настроим выпуск разностных CRL. Для этого необходимо открыть «Свойства (Properties)» раздела «отозванных сертификатов (Revoked Certificates)» (рис. 14).

Задаём «Интервал публикации CRL (CRL Publications interval)».

Включаем публикацию разностных CRL и задаём интервал.

Кажется, что все хорошо. Но есть один момент:

Выполните следующую команду в power shell:

Рисунок 14. Настройка параметров публикации CRL.

Отзыв сертификатов

0123456789 будет обозначать серийный номер сертификата, 4 — причина отзыва будет Superseded и эффективная дата отзыва (когда сертификат будет помещён в Revoked Certificates) будет 24 часа после выполнения команды. Да, именно этим методом можно отзывать корневые сертификаты :-).