1.3 Работа с сертификатами КриптоПро — РЕД ОС

Основные команды csptest.exe¶

3 Работа с сертификатами КриптоПро — РЕД ОС

ln -s /opt/cprocsp/bin/amd64/certmgr /usr/bin/certmgr
ln -s /opt/cprocsp/bin/amd64/csptest /usr/bin/csptest
ln -s /opt/cprocsp/sbin/amd64/cpconfig /usr/bin/cpconfig

csptest -enum -info

cat /etc/opt/cprocsp/release

cpconfig -license -view

# cpconfig -license -set <серийный_номер>

systemctl status pcscd

systemctl start pcscd
systemctl enable pcscd

pcscd -dffff

csptest -card -enum -v -v
pcsc_scan

csptest -keyset -enum_cont -fqcn -verifyc | iconv -f cp1251

CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9963 OS:Linux CPU:AMD64 FastCode:READY:AVX.AcquireContext: OK. HCRYPTPROV: 16778675\.Aladdin R.D. JaCarta 00 008df47e71-18ae-49c1-8738-9b4b0944dcd4\.FLASHbob\.HDIMAGEbobOK.Total: SYS: 0,010 sec USR: 0,110 sec UTC: 6,240 sec[ErrorCode: 0x00000000]

csptest -keyset -enum_cont -fqcn -verifyc | iconv -f cp1251

csptest -keyset -enum_cont -fqcn -verifyc -uniq

CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9963 OS:Linux CPU:AMD64 FastCode:READY:AVX.AcquireContext: OK. HCRYPTPROV: 23397811\.Aladdin R.D. JaCarta 00 008df47e71-18ae-49c1-8738-9b4b0944dcd4 | \.Aladdin R.D. JaCarta 00 00SCARDJACARTA_6082028344937676CC00E412OK.Total: SYS: 0,000 sec USR: 0,110 sec UTC: 6,230 sec[ErrorCode: 0x00000000]

csptest -keyset -container '\.HDIMAGEbob' -info

csptest -keyset -enum_cont -verifycontext -fqcn

csptest -keyset -enum_cont -verifycontext -fqcn -machinekeys

csptest -keyset -check -cont '\.имя считывателяимя контейнера'

csptest -keyset -check -cont '\.имя считывателяимя контейнера' -machinekeyset

certmgr -inst -file cert_bob.cer

certmgr -inst -file cert_bob.cer -store uMy -cont '\.FLASHbob'

/opt/cprocsp/bin/amd64/certmgr -inst -store uMy -cont '\.Aladdin R.D. JaCarta 00 008df47e71-18ae-49c1-8738-9b4b0944dcd4'

/opt/cprocsp/bin/amd64/certmgr -inst -store uMy -cont '\.Aladdin R.D. JaCarta 00 008df47e71-18ae-49c1-8738-9b4b0944dcd4' -file /home/bob/cert_bob.cer

certmgr -inst -store uRoot -file <название-файла>.cer

certmgr -inst -store mRoot -file <название-файла>cer

certmgr -inst -crl -file <название-файла>.crl

certmgr -list

certmgr -list -store uMy

$ certmgr -list -store uRoot

certmgr -list -container '\.Aladdin R.D. JaCarta 00 008df47e71-18ae-49c1-8738-9b4b0944dcd4'

certmgr -list -store uca

certmgr -list

certmgr -delete -store uMy

certmgr -delete -store uRoot

certmgr -delete -all -store uRoot

certmgr -delete -store mRoot

cpconfig -hardware reader -add HDIMAGE store
Adding new reader:
Nick name: HDIMAGE
Succeeded, code:0x0

csptest -keyset -enum_cont -fqcn -verifyc

CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9963 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 32114099
\.FLASHbob
OK.
Total: SYS: 0,020 sec USR: 0,080 sec UTC: 0,190 sec
[ErrorCode: 0x00000000]

csptest -keyset -enum_cont -fqcn -verifyc

CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9963 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 36951475
\.FLASHbob
\.HDIMAGEbob
OK.
Total: SYS: 0,000 sec USR: 0,070 sec UTC: 0,160 sec
[ErrorCode: 0x00000000]

certmgr -inst -file cert-bob.cer -cont '\.HDIMAGEbob'

Certificate transparency

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

с более подробным описанием CT, но суть в том, что CA заносит все выданные сертификаты в журнал CT.

Ocsp expect-staple

Хотя Must-Staple кажется отличным решением проверки отзыва сертификатом, это не совсем так. На мой взгляд, одной из самых больших проблем является то, что я как оператор сайта не могу точно знать, насколько надёжны метки OCSP Staple и как их принимает клиент.

Без включенного OCSP Must-Staple это не является проблемой, но если включить OCSP Must-Staple и мы не уверены в надёжности или правильности OCSP Staple, это проблема для сайта. Чтобы попытаться и получить некую обратную связь о качестве меток OCSP Staple, мы можем активировать функцию под названием OCSP Expect-Staple. Я писал о ней раньше, и вы можете узнать все подробности в блоге

, но здесь тоже объясню вкратце. Вдобавок к

вы запрашиваете браузер прислать отчёт, удовлетворён ли он меткой OCSP Staple. Вы можете собирать отчёты сами или использовать мой сервис

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

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

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

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

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

scotthelme.co.uk. IN CAA 0 issue “letsencrypt.org”

Хотя авторизация CA — не особенно сильный механизм, и он не способен помочь во всех ситуациях некорректной выдачи сертификатов, но в некоторых случаях он полезен, так что следует заявить о своих предпочтениях, создав запись CAA.

Исправление проблемы

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

Копирование контейнера¶

Копирование контейнера осуществляется с помощью параметра -keycopy:

• -src — имя контейнера. Имена контейнеров уникальны, поэтому можно не указывать путь к носителю, КриптоПро сама найдет путь к контейнеру.
• -dest — имя скопированного контейнера, оно должно отличаться от исходного имени. Так же можно указать путь к контейнеру, например, если указать -dest"\.FAT12_H2021ZAO_3", то контейнер будет скопирован на флэшку. Если не указать путь к носителю, а просто задать название контейнеру, то крипто про выведет графический диалог выбора носителя для копирования.
• -pinsrc — пароль от исходного контейнера, если пинкода нет, то данный параметр можно не указывать.
• -pindest — пароль на скопированный контейнер. Чтобы подавить графический диалог установки пароля при автоматическом копировании контейнеров, можно указать пустой пароль, выполнив -pindest=""

Например, рассмотрим копирование контейнера с рутокена в реестр:

Поддельные сертификаты

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

Полный сбой

Выше я говорил о CRL и OCSP, двух механизмах проверки сертификатов браузером, и они выглядят таким образом.

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

Здесь у браузера только два варианта. Он может отказаться принимать сертификат, поскольку не способен проверить его статус. Или взять на себя риск и принять сертификат, не зная его статус, отозван он или нет. У обоих вариантов есть свои преимущества и недостатки.

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

Проприетарные механизмы

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

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

В Chrome он называется CRLsets, а в Firefox — OneCRL. Эти механизмы проверяют списки отозванных сертификатов, объединяя доступные CRL и выбирая оттуда сертификаты. Так проверяются особо ценные сертификаты вроде промежуточных, но что насчёт обычных, наших с вами?

Протокол проверки статуса сертификата

OCSP предлагает намного более красивое решение проблемы и имеет значительное преимущество перед CRL. Здесь мы спрашиваем у CA статус единственного, конкретного сертификата. Это значит, что CA должен вернуть только простой ответ: сертификат либо хороший, либо отозван, и такой ответ гораздо меньше по размеру, чем список CRL. Отлично!

Ресурсы удостоверяющего центра | фнс россии | 77 город москва

Теория. для чего нужен crl

Список отзывов сертификатов (Certificate revocation list) – представляет собой файл указывающий на список сертификатов с указанием серийного номера сертификата, даты отзыва, причина отзыва. В целом списки отзыва сертификатов (CRL)
используются для передачи сведений об отзыве сертификатов пользователям, компьютерам и приложениям, пытающимся проверить подлинность сертификата.

При каких ситуациях ваш сертификат может попасть в указанный список:

1. При выдаче сертификата УЦ ошибся в части реквизитов, поэтому был выдан новый сертификат.

2. Сертификатом завладело третье лицо, кто мог бы подписывать за вас (т.н. компрометация ключа).

3. Сертификат был отозван по заявлению владельца сертификата.

4. Сменилось уполномоченное лицо, владеющее сертификатом;

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

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

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

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

Петя уволился (сам или нет..)1. На место Пети посадили Колю, который получил полный доступ к всей информации Пети. При этом ещё не все знают, что Пети нет.2. Маша (которая ещё не знает, что случилось) шлёт Пете файл (что-то личное?!), зашифровав его Петиним открытым ключом.3.

Если бы Маша проверила Петин сертификат по CRL, то она бы узнала, что сертификатом Пети шифровать уже нельзя. Да и другие люди должны знать, что Петя ничего больше подписывать не должен. Т.е. все должны регулярно обновлять CRL
(если это не делается автоматически или ПО само не производит on-line проверку сертификата).

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

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

Ситуация: ЦС был выдан сертификат. В DIRECTUM указанным сертификатом даже было подписано задание, задачи, документы. Выданным сертификатом завладело третье лицо, нам необходимо обеспечить, чтобы в рамках системы DIRECTUM, указанный
сертификат уже не мог использоваться.

В дальнейшем будем иметь дело со следующим сертификатом:

А вот и подписанное задание данным сертификатом.

Установка crl

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

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

Формирование crl

CRL формируется также на самом ЦС довольно нехитрыми действиями.

1. Зайдите в консоль ЦС. Выбираем раздел “Отозванные сертификаты. Вызовем контекстное меню и выберем пункт “Все задачи” -> “Публикация”.

Выберите тип публикуемого CRL: полный или разностный. Основное отличие это формирование полного списка или за выбранный при настройке период публикации. Если в вашей организации выдачей сертификатов не занимаются каждый день, и
список формируемых сертификатов не велик, то лучше выбрать тип “Полный”. После выполнения указанных действий, получаем список отозванных сертификатов.

Также сформировать список CRL можно и при помощи командной строки вызвав команду certutil -crl.

2. После публикации указанного списка, необходимо его сформировать в файл. Для этого зайдите в веб-форму ЦС. Выберите действие “Загрузка сертификата ЦС, цепочки сертификатов или CRL” -> “Загрузка сертификата ЦС, цепочки сертификатов
или CRL”. Сохраните указанный файл на компьютере.

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

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

Частичный сбой

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

не пытается

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

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

Если вы осуществляете атаку MiTM, то вам нужно всего лишь блокировать запрос на проверку сертификата и создать впечатление, что CA не работает. Браузер тогда столкнётся с частичным сбоем проверки и продолжит радостно использовать отозванный сертификат.

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

Адам Лэнгли из Google лучше всех описал, что такое отзыв сертификата: это ремень безопасности, который рвётся в момент аварии, и он прав. Вы каждый день садитесь в машину и пристёгиваете ремень безопасности — и он даёт вам приятное и комфортное ощущение безопасности.

Отзыв

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

Как только мы узнаём о факте взлома, мы связываемся с CA и просим отозвать наш сертификат. Нужно доказать факт владения сертификатом, и как только мы сделали это, то CA помечает сертификат как отозванный. Теперь нужен способ сообщить об этом факте каждому клиенту, которому может потребоваться данная информация.

Прямо в этот момент браузер, конечно, ничего не знает, и это проблема. Есть два механизма, которые используются для распространения информации: это список отозванных сертификатов (Certificate Revocation List, CRL) и протокол проверки статуса сертификата (Online Certificate Status Protocol, OCSP).

Заключение

В настоящий момент существует реальная проблема, что мы не можем отозвать сертификат, если кто-то получил наш секретный ключ. Только представьте, во что это выльется при раскрытии следующей глобальной уязвимости масштаба Heartbleed! Одна вещь, которую вы можете попытаться сделать — это ограничить размер ущерба от утечки, сократив срок действия своего сертификата.

Вместо трёх лет указывайте один год или даже меньше. Let’s Encrypt выдаёт только сертификаты, которые действительны всего лишь 90 дней! С сокращением времени жизни вашего сертификата у злоумышленника будет меньше времени для злоупотреблений. Кроме этого мы мало что можем сделать.

Для демонстрации проблемы и того, насколько она реальна, попробуйте зайти на новый поддомен, который я открыл на своём сайте, revoked.scotthelme.co.uk. Как вы вероятно догадываетесь, к этому поддомену прикреплён отозванный сертификат, и вполне вероятно, что он нормально загрузится в вашем браузере.

Если нет, если ваш браузер выдаст предупреждение об истёкшем сроке действия, то это значит, что ваш браузер по-прежнему отправляет запросы OCSP и вы только что сообщили в CA о том, что посетили мой сайт. Для доказательства, что такая проверка с мягким сбоем бесполезна, можете добавить в hosts домен ocsp.int-x3.letsencrypt.

org с IP-адресом 127.0.0.1 или блокировать его каким-нибудь другим способом — и повторить попытку подключения. На этот раз страница нормально загрузится, потому что проверка отозванного сертификата не сработает, а браузер продолжит загружать страницу. Толку от такой проверки…

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

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

Итак опишу действия необходимые для отзыва сертификата.

1. Заходим в консоль ЦС. Открываем раздел “Выданные сертификаты”.

2. Вызываем контекстное меню на необходимом нам сертификате, выбираем пункт “Все задачи” -> “Отзыв сертификата”.

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

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