Создание резервной копии сертификата средствами Windows – Электронный документооборот и обеспечение безопасности стандартными средствами windows

Что такое бюро сертификатов?

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

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

Ниже приведены некоторые коммерческие бюро сертификатов:

Для создания своего собственного сертификата установите имеющееся в
WindowsServer 2003 бюро сертификатов. Об этом мы расскажем чуть позже,
в разделе “Выбор типа бюро сертификатов”.

Основные этапы такой процедуры:

1. Вы настраиваете архивацию закрытых ключей на сервере.
2. В момент выдачи сертификата, его закрытый ключ копируется в базу данных и шифруется с помощью специального сертификата – Key Recovery Agent (KRA).
3. При необходимости восстановленияэкспорта какого-либо закрытого ключа, он расшифровывается с помощью Key Recovery Agent (KRA).

Рассмотрим, как эти шаги выполняются.

Архивация и восстановление сертификата

При архивации сертификата SSL необходимо вместе с сертификатом
заархивировать секретный ключ.

Для архивирования сертификата и секретного ключа выполните следующие
действия.

В каком формате архивировать

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

Один человек на Хабре пишет, что шифруется TrueCrypt’ом. Так дело в том, что TrueCrypt уже не поддерживается, он перестал поддерживаться с окончанием поддержки хрюсофта. То же самое с VeraCrypt, которую советуют там же некоторые товарищи. Где гарантии, что их не закроют через год, два и т.д.? Вот смотрите (предполагаемый вариант развития событий):

1 Всё хорошо, винт работает, вы копируете в облако контейнер, зашифрованный VeraCrypt. Дистрибутив не сохраняете.

2 Проходит несколько лет. Их конторку в результате каких то санкций прикрывают. Вы об этом даже не подозреваете.

3 Проходит несколько лет. Вы всё также копируете в облако контейнер, зашифрованный VeraCrypt. Бац, винт полетел. Вы скачиваете с облака зашифрованный контейнер. Ищете программу VeraCrypt в Интернете. А её либо нигде нет, либо её невозможно установить по причине, например, кончины сертификата, которым подписывается инсталлятор.

Выбор типа бюро сертификатов

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

Первое, что нужно сказать о корпоративном бюро сертификатов – для него
требуется Active Directory. Польза от корпоративного бюро сертификатов
выходит за рамки IIS; например, его можно использовать при входе в
домен, а при работе со смарт-картами его установка является
обязательной.

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

При получении запроса корпоративное бюро сертификатов
принимает решение о выпуске или отклонении сертификата, в зависимости
от параметров безопасности Active Directory. Пользователи выполняют
запрос сертификаты из консоли MMC Certificates (Сертификаты) либо через
Certification Authority Web Enrollment (Регистрация бюро сертификатов в
интернете).

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

Где архивировать

Есть несколько вариантов

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

Я летом этого года покупал флешку на 16 гигов, для DrWeb Live Disk. Пару раз я ей воспользовался, когда установил на неё DrWeb и когда пылесосил комп. При очередной попытке загрузиться с неё я обнаружил, что она не только не открывается, но и не обнаруживается как устройство. Потрогав её я понял, что флешке пришёл красивый пушной зверёк.

Также внешний носитель легко потерять. И чем больше габариты носителя, тем проще. Иногда достаточно оставить без присмотра. Я так потерял флешку, на которой установил MS-DOS.

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

Однако, хранение данных в облачном хранилище означает, что ваши данные больше не подконтрольны вам. Шифрование данных на винчестере сокращает размер информации, которая нуждается в физической защите. А шифрование данных в облаке делает вообще возможным контроль за их движением. Т.е. данные нужно шифровать

Документация

Как всё автоматизировать

Этот вопрос частично я оставляю за вами. Мне интересно ваше мнение. Я пробовал CryptSync с настройками синхронизации в каталог OneDrive. Но этот способ не подходит по причине шифрования всех файлов одним паролем. Можно сделать батник, генерирующий пароли с помощью OpenSSL и упаковывающий файлы по 7z архивам.

Как работают сертификаты клиентов

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

Аутентификация клиента с помощью сертификатов добавляет несколько шагов
в процедуру SSL-рукопожатия. Рассмотрим рукопожатие SSL еще раз, но
теперь уже применительно к сертификатам клиентов.

1. Клиент отправляет серверу номер версии протокола SSL клиента,
   параметры шифра, случайно сгенерированный набор данных и другую
   информацию, необходимую серверу для установки связи посредством SSL.
2. Сервер отправляет клиенту номер своей версии SSL, параметры шифра,
   случайно сгенерированный набор данных и другую информацию, необходимую
   клиенту для установки соединения посредством SSL. Сервер также передает
   свой собственный сертификат.
3. Сервер запрашивает сертификат клиента.
4. Клиент аутентифицирует сервер (см. описание этого процесса описан в
   разделе “Бюро сертификатов и доверие”).
5. Используя полученную информацию, клиент создает предварительный
   секрет для сеанса, шифрует его на открытом ключе сервера и отправляет
   на сервер.
6. При помощи собранной информации клиент подписывает фрагмент данных и
   передает эти данные и свой сертификат вместе с предварительным
   секретом.
7. Сервер выполняет аутентификацию пользователя с помощью тех же шагов,
   которые выполнял пользователь для аутентификации сервера.
8. С помощью предварительного секрета сервер выполняет
   последовательность шагов по созданию основного секрета; это выполняется
   на клиенте.
9. Клиент и сервер используют главный секрет для создания сеансовых
   ключей.
10. Клиент передает серверу уведомление о том, что следующее сообщение
    будет зашифровано на сеансовом ключе.
11. Клиент передает зашифрованное сообщение серверу о том, что процесс
    “рукопожатия” завершен.
12. Сервер уведомляет клиента о том, что следующее сообщение будет
    зашифровано на сеансовом ключе.
13. Сервер передает зашифрованное сообщение клиенту о том, что процесс
    “рукопожатия” завершен.
14. Процедура окончена. Клиент и сервер используют сеансовые ключи для
    шифрования данных на симметричном ключе.

Как хранить ключи

Хранить ключи лучше в единой БД, пусть это будет даже текстовый файл. И желательно отдельно от данных. Также помним, что ключевая БД много меньше по размеру самих данных. Это значит, что её проще контролировать.

Варианты хранения также несколько Например, хранить на флешке с небольшим объёмом памяти. И сделать хоть тысячу копий на случай отказа одной из них. Но тогда каждый ключ нужно снабжать хэш-значением. У меня не так давно полетела флешка, отформатированная NTFS, с хранящимися на ней паролями.

Но тогда какой смысл, хранить ключи на флешке или сами файлы на флешке. Риски всё те же. Как вариант, хранить ключевой файл в облачном менеджере паролей, защищённом доступом по СМС. Например: Keeper, Kaspersky Password Manager, т.е. уже с физической защитой. Без необходимости хранить ключевой файл на флешке с риском потери.

Как шифровать

Как шифровать Простейший способ – симметричное шифрование. Однако здесь есть свои тонкости. Шифрование каждого файла одним ключом увеличивает вероятность атаки открытого текста. Поэтому такой способ не подходит. Точнее, способ удачный, но он – всего лишь основа. Нужно как то его дополнить.

Например, для каждого файла генерировать уникальный ключ симметричного шифрования. И уже каждый уникальный ключ шифровать общим. Как это делается в технологии Bitlocker. Такой подход делает невозможными атаки открытого текста, однако лишает каждый файл автономности, поскольку рандомные ключи нужно хранить в отдельном файле. Здесь уже сохранность данных зависит от сохранности ключей. Как хранить ключи – об этом следующий вопрос.

Корневые и подчиненные бюро сертификатов

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

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

Настройка архивации закрытых ключей на сервере.

Вам понадобится сертификат Key Recovery Agent (KRA), выданный для вашей учетной записи.

• В оснастке Certificate Authority, откройте Certificate Templates, и сделайте шаблон Key Recovery Agent доступным для выдаи сертификатов (правой кнопкой по Certificate Templates, выбрать New и выбрать Certificate Template to Issue).

• Теперь под учетной записью администратора на сервере Certificate Authority, вы должны запросить сертификат KRA через оснастку своиъ личных сертификатов (certmgr.msc). Этот выданный для вас сертификат должен появиться в вашем хранилище Personal Certificates.

• В оснастке Certificate Authority, щелкаем правой кнопкой на CA и выбираем Properties. На вкладке Recovery Agents, выбираем Archive the key и жмем Add для добавления сертификатов KRA. Выбираем свой сертификат и жмем Apply.

• В настройках шаблона сертификатов пользователей должна быть настроена возможность архивации закрытых ключей. Для этого выбираем Certificate Templates и жмем Manage. Выбираем нужный сертификат и жмем Properties. Открываем вкладку Request Handling и выбираем Archive subject’s encryption private key.

• Теперь закрытые ключи для вновь выданных сертификатов будут заархивированы в базе данных сервера центра сертификации. Когда ключ сертификата заархивирован, ставится пометка в колонке Archived Key (ее надо добавить через View, Add/Remove Columns).

Работа сертификатов сервера с ssl

“Рукопожатием” SSL называется совокупность процессов аутентификации,
шифрования и проверки. При рукопожатии SSL выполняются следующие
действия.

1. Клиент отправляет серверу номер версии протокола SSL клиента,
   параметры шифра, случайно сгенерированный набор данных и другую
   информацию, необходимую для установки связи посредством SSL.
2. Сервер отправляет клиенту номер своей версии SSL, параметры шифра,
   случайно сгенерированный набор данных и другую информацию, необходимую
   клиенту для установки соединения с посредством SSL. Сервер также
   передает свой собственный сертификат.
3. Клиент аутентифицирует сервер (см. описание этого процесса описан в
   разделе “Бюро сертификатов и доверие”).
4. Используя полученную информацию, клиент создает предварительный
   секрет для сеанса, шифрует его на открытом ключе сервера и отправляет
   на сервер.
5. С помощью предварительного секрета сервер выполняет
   последовательность шагов по созданию основного секрета; это выполняется
   на клиенте.
6. Клиент и сервер используют главный секрет для создания сеансовых
   ключей.
7. Клиент передает серверу уведомление о том, что следующее сообщение
   будет зашифровано на сеансовом ключе.
8. Клиент передает зашифрованное сообщение серверу о том, что процесс
   “рукопожатия” завершен.
9. Сервер передает сообщение клиенту о том, что следующее сообщение
   будет зашифровано на сеансовом ключе.
10. Сервер передает зашифрованное сообщение клиенту о том, что процесс
    “рукопожатия” завершен.
11. Процедура окончена. Клиент и сервер используют сеансовые ключи для
    шифрования данных на симметричном ключе.

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

Связь “один ко многим”

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

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

В этом случае не
нужно извлекать сертификаты, как при работе со связями “один к одному”.
Правила “много к одному” обрабатываются по порядку; первое правило,
соответствие которому обнаруживается, аутентифицирует пользователя.
Следовательно, последнее правило откажет в доступе всем пользователям.

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

1. В Windows Explorer дважды щелкните на файле сертификата ( .cer ).
2. Нажмите на кнопку Details (Детали).
3. На вкладке Details (Детали) окна Certificate (Сертификат) (см. рис.
   10.8) в записях Issuer и Subject расположена полезная информация.

С учетом этой информации создайте правило отказа в доступе по
умолчанию.

1. Откройте консоль IIS MMC.
2. Откройте окно Properties (Свойства) веб-сайта, для которого
   настраивается связь сертификата клиента, после чего откройте вкладку
   Directory Security (Безопасность каталога).
3. Убедитесь, что в области Secure Communications (Безопасные
   соединения) отмечена опция Enable Client Certificate Mapping (Включить
   связывание сертификатов клиентов), после чего нажмите на кнопку Edit
   (Изменить).
4. Откройте вкладку Many-to-1 (Много к одному) в окне Account Mapping
   (Связи с учетными записями).
5. Нажмите на кнопку Add (Добавить).
6. В окне General (Общие) присвойте правилу Wilcard Matching Rule
   (Правило соответствия по групповому символу) информативное имя,
   например, “Отказ всем”. Опция Enable This Wildcard Rule (Включить это
   правило группового символа) должна быть отмечена по умолчанию.
7. Нажмите на кнопку Next (Далее), затем – на кнопку New (Создать).
8. В окне Rules (Правила) выберите критерий, которому будет
   удовлетворять каждый сертификат, например:
9. Оставьте отмеченной опцию Match Capitalization (Сопоставлять
   регистр).
10. Нажмите на кнопку OK, после чего нажмите на кнопку Next (Далее).
11. В окне Mapping (Связывание) выберите переключатель Refuse Access
    (Отклонить доступ).
12. Нажмите на кнопку Finish (Готово).

Теперь всем посетителям будет отказано в доступе, независимо от их
сертификатов. Следующим шагом, разумеется, будет определение правил,
разрешающих доступ.

1. В окне Account Mappings (Связи с учетными записями) (см. шаги 3 и 4
   предыдущей процедуры) нажмите на кнопку Add (Добавить).
2. В окне General (Общие) присвойте правилу некоторое информативное имя,
   например, “Инженерный отдел”.
3. Оставьте отмеченной опцию Enable This Wildcard Rule (Включить это
   правило группового символа).
4. Нажмите на кнопку Next (Далее), затем – на кнопку New (Создать).
5. В окне Rules (Правила) выберите соответствующий параметр, например:
6. Не забудьте включить или отключить опцию Match Capitalization
   (Сопоставлять регистр) (при необходимости). Данная опция включена по
   умолчанию.
7. Если этой информации достаточно для определения аутентифицируемой
   группы, то нажмите на кнопку Next (Далее). В противном случае нажмите
   на кнопку New (Создать) еще раз для добавления нужного количества
   правил.
8. В окне Mapping (Связывание) выберите имя и укажите пароль учетной
   записи, с которой следует установить связь.
9. Нажмите на кнопку Finish (Готово).
10. Введите пароль еще раз в появившемся окне Confirm Password
    (Подтвердите пароль).
11. Нажмите на кнопку OK.
12. Убедитесь, что правила расположены в нужном порядке (см. рис. 10.9).
    Все, что расположено ниже правила отклонения, будет игнорироваться. С
    помощью кнопок Move Up (Вверх) и Move Down (Вниз) выполните
    упорядочивание списка.
13. Нажмите на кнопку OK для закрытия окна Account Mappings (Связи с
    учетными записями).

Создание собственного бюро сертификатов

Теперь рассмотрим процесс создания собственного бюро сертификатов.

Установка корпоративного корневого бюро сертификатов

Помните, что корпоративное бюро сертификатов устанавливается при
наличии Active Directory.

1. В Панели управления дважды щелкните на значке Add or Remove Programs
   (Установка и удаление программ).
2. Нажмите на кнопку Add/Remove Windows Components (Установка и удаление
   компонентов Windows).
3. В мастере компонентов Windows (Windows Components Wizard) (см. рис.
   10.2) отметьте опцию Certificate Services (Службы сертификатов).
4. Появится предупреждение о том, что при продолжении работы в
   дальнейшем нельзя будет изменить имя компьютера и домена. В окне
   сообщения нажмите на кнопку Yes (Да).
5. Нажмите на кнопку Next (Далее).
6. Отметьте Enterprise Root CA (Корпоративное корневое бюро
   сертификатов), затем нажмите на кнопку Next (Далее).
7. Введите информативный текст в качестве имени.
8. Нажмите на кнопку Next (Далее).
9. Мастер сгенерирует ключ и после этого отобразит информацию о папке.
   Здесь следует оставить все как есть, если нет определенных причин для
   изменения данной информации.
10. При наличии на компьютере функционирующей службы IIS ее необходимо
    остановить. При появлении сообщения с подобной информацией нажмите на
    кнопку Yes (Да).
11. Мастер выполнит все необходимые действия по установке. Нажмите на
    кнопку Finish (Готово).

Установка корпоративного подчиненного бюро сертификатов

После установки корневого бюро сертификатов в домене можно установить
подчиненное корпоративное бюро сертификатов.

1. В Панели управления дважды щелкните на значке Add or Remove Programs
   (Установка и удаление программ).
2. Нажмите на кнопку Add/Remove Windows Components (Установка и удаление
   компонентов Windows).
3. В мастере компонентов Windows (Windows Components Wizard) (см. рис.
   10.2) отметьте опцию Certificate Services (Службы сертификатов).
4. Появится предупреждение о том, что при продолжении работы в
   дальнейшем нельзя будет изменить имя компьютера и домена. В окне
   сообщения нажмите на кнопку Yes (Да).
5. Нажмите на кнопку Next (Далее).
6. Включите Enterprise Subordinate CA (Корпоративное подчиненное бюро
   сертификатов).
7. Нажмите на кнопку Next (Далее).
8. Присвойте бюро сертификатов информативное имя, после чего нажмите на
   кнопку Next (Далее).
9. Мастер сгенерирует ключ и после этого отобразит информацию о папке.
   Здесь следует оставить все как есть, если нет причин для изменения
   папки.
10. Выберите Send The Request To An Online CA (Отправить запрос в
    онлайн-бюро сертификатов).
11. Нажмите на кнопку Browse (Обзор), после чего нажмите на кнопку OK.
12. Нажмите на кнопку Next (Далее).
13. Мастер выполнит все необходимые действия по установке. Нажмите на
    кнопку Finish (Готово).

Установка отдельного корневого бюро сертификатов

При выборе отдельного бюро сертификатов сначала нужно установить
отдельное корневое бюро сертификатов. Для установки службы сертификатов
в качестве отдельного корневого бюро сертификатов (Standalone Root CA)
выполните следующие действия.

1. Выполните шаги 1-5 предыдущей процедуры.
2. Отметьте Stand-alone Root CA. (Обратите внимание на то, что опция
   Enterprise [Корпоративное] недоступна, если не установлена Active
   Directory).
3. Здесь вы также увидите опцию Use Custom Setting To Generate The Key
   Pair And CA Certificate (Использовать особые параметры для генерации
   пары ключей и сертификата). Если это не требуется, то оставьте данную
   опцию отключенной. Особые параметры позволяют выбрать CSP, алгоритм
   хэширования и длину ключа. В настройках по умолчанию используются
   параметры Microsoft Strong Cryptographic Provider, SHA-1 и 2048,
   соответственно.
4. Нажмите на кнопку Next (Далее).
5. Введите в поле Common Name (Общее имя) некоторый информативный текст
   (например, имя домена или компьютера).
6. Нажмите на кнопку Next (Далее).
7. Ключ будет сгенерирован, и отобразится информация о папке. В этом
   окне следует оставить все как есть, если нет причин для изменения
   папки.
8. Нажмите на кнопку Next (Далее).
9. Появится сообщение о том, что службу IIS необходимо остановить.
   Нажмите на кнопку Yes (Да).
10. Мастер выполнит необходимые действия по установке; это займет
    несколько минут. Нажмите на кнопку Finish (Готово).

Установка отдельного подчиненного бюро сертификатов

После установки отдельного корневого бюро сертификатов можно установить
отдельное подчиненное бюро сертификатов:

Установка служб сертификатов на сервер

Для установки службы сертификатов на сервер используется мастер Add or
Remove Programs (Установка и удаление программ) в Панели управления.
Данная процедура индивидуальна для каждого типа бюро сертификатов.

Централизованное резервное копирование сертификатов и закрытых ключей средствами службы сертификатов microsoft

Централизованное резервное копирование цифровых сертификатов устраняет ряд сложностей, которые возникают при ручном архивировании сертификатов:

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

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

Как же заставить локальные компьютеры передавать центру сертификатов свой закрытый ключ?

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

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

Восстановление сертификата вместе с закрытым ключом выполняется с помощью сертификата и закрытого ключа KRA в стандартный файл .pfx, который затем импортируется на клиентском компьютере.

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

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

Пошаговое руководство по централизованному архивированию ключей есть в учебном курсе 6426 “Конфигурирование и устранение неисправностей решений идентификации и управления доступом на основе Windows Server 2008 Active Directory”.

Экспорт архивных ключей

Когда закрытый ключ сертификата попал в архив, этот ключ может быть восстановлен под учетной записью администратора, у которого есть сертификат Key Recovery Agent (и этот сертификат использовался для шифрации закрытого ключа). Чтобы запустить команду на экспорт, необходимо знать серийный номер сертификата, ключ которого будем восстанавливать. Серийный номер можно посмотреть на вкладке Details в свойствах сертификата.

Используя серийный номер восстанавливаемого сертификата мы получаем некую структуру BLOB (предположительно, просто бинарный код из базы, точнее не знаю). Затем преобразовываем BLOB-сертификат в pfx-файл, который содержит в себе открытый и закрытый ключи. Этот файл должен быть защищен паролем. Ниже представлены команды, как это делается.