ping ca криптопро

Введение

• https://help.ubuntu.com/community/Kerberos
• Про аутентификацию с использованием сертификатов здесь: http://k5wiki.kerberos.org/wiki/Pkinit_configuration

Основные понятия

• Key Distribution Center (KDC) – хранилище информации о паролях пользователей.
• Admin server – основной сервер kerberos. У нас KDC и admin server находятся на одной машине.
• Realm – “среда”, в которой производится аутентификация.
• Principal – пользователь или сервис, участвующий в механизме аутентификации. Мы пока рассматриваем только пользователей.

Важное вступление

В гайде описывается формирование отсоединенной подписи в формате PKCS7 (рядом с файлом появится файл в формате .sig). Такую подпись может запросить нотариус, ЦБ и любой кому нужно долгосрочное хранения подписанного документа. Удобство такой подписи в том, что при улучшении ее до УКЭП CAdES-X Long Type 1 (CMS Advanced Electronic Signatures [1]) в нее добавляется штамп времени, который генерирует TSA (Time-Stamp Protocol [2]) и статус сертификата на момент подписания (OCSP [3]) – подлинность такой подписи можно подтвердить по прошествии длительного периода (Усовершенствованная квалифицированная подпись [4]).

Код основан на репозиториях corefx и DotnetCoreSampleProject – в последнем проще протестировать свои изменения перед переносом в основной проект и он будет отправной точкой по сборке corefx. Судя по записям с форума компании [5], решение для .NET Core в стадии бета-тестирования. Далее по тексту я также буду ссылаться на этот форум. Разработка велась в Visual Studio Community 2019.

Для получения штампа времени использован TSP-сервис http://qs.cryptopro.ru/tsp/tsp.srf

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

Программный комплекс ViPNet StateWatcher состоит из следующих компонентов:

• сервер мониторинга — программный сервер, который выполняет следующие функции:
• собирает и хранит информацию о текущем состоянии узлов сети ViPNet и других инфраструктурных элементов сети
• выполняет анализ значений параметров состояния и формирует сообщения о выявленных событиях.
• оповещает операторов и администраторов системы об изменениях состояния объектов мониторинга и выявленных событиях, а также экспортирует сведения во внешние информационные системы
• АРМ мониторинга — рабочее место оператора или администратора сервера мониторинга, позволяющее управлять одним или несколькими серверами мониторинга через защищенный канал. Доступ к данным и оповещениям о событиях сервера мониторинга осуществляется удалено через веб-интерфейс
• узлы мониторинга — элементы сети, состояние которых отслеживается сервером мониторинга
• агент мониторинга — компонент клиентского ПО защищенной сети ViPNet или стандартные службы SNMP (SNMP-агент), которые находятся на узле мониторинга и обеспечивают сбор и передачу данных о состоянии узла на сервер мониторинга

Назначение

• мониторинг узлов распределенных сетей ViPNet и узлов удаленных пользователей сети ViPNet вне зависимости от способа их подключения к коммуникационной сети (определение сбоев, событий безопасности и других событий)
• мониторинг узлов, оборудования и других компонентов информационных систем (определение сбоев, событий безопасности и других событий)
• мониторинг объектов сетевой инфраструктуры (маршрутизаторов, коммутаторов и т.д.), периферийного и сопутствующего оборудования (принтеры, ИБП, МФУ), поддерживающего протокол SNMP

Возможности

Визуализация и обработка данных

• визуализация объектов мониторинга и их состояния в геоинформационных системах и структурных схемах информационных сетей.
• динамическое построение графиков параметров мониторинга с отображением ретроспективных значений за период от 5-ти минут до 24 часов.
• настраиваемые инфопанели для представления информации об узлах мониторинга и событиях с возможностью фильтрации.

Детальная информация об узле мониторинга («карточка узла»):

• расположение на карте
• доступность
• значения параметров мониторинга
• список текущих событий
• история событий

Настройка и администрирование

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

Преимущества

Взаимодействие с внешними системами

• экспорт информации о событиях и состоянии объектов мониторинга во внешние системы в формате syslog/CEF
• Возможность получения информации о состоянии сенсоров системы обнаружения вторжений ViPNet IDS
• Фильтрация и экспорт данных мониторинга и выявленных событий в XML-файлы

Логика анализа данных

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

Данные и события

• определение доступности узлов, в том числе и не поддерживающих протокол SNMP (по команде ping)
• широкие возможности оповещения: визуальные (карты, таблицы, popup-окна), SMS, email, ViPNet, аудио- и визуальная сигнализация о событиях
• история срабатывания правил анализа

Безопасность

• невозможность для ViPNet StateWatcher вмешательства в работу наблюдаемых узлов, управления ими
• широкая интеграция с СЗИ ViPNet для защиты узлов мониторинга, компонентов системы мониторинга, собираемых данных
• журналирование действий пользователей и администраторов, изменений правил анализа
• опосредованное наблюдение за узлами мониторинга в каскадной иерархии серверов мониторинга
• централизованное управление «доменами мониторинга».

Отзыв TLS-сертификатов у российских подсанкционных банков – это конец «системы доверия» в Интернете в том виде, как мы ее знаем. Ящик Пандоры открыт.

Disclaimer:

Речь в статье пойдет исключительно о TLS-сертификатах и построенной на них «системе доверия». Поэтому, если вам так проще, представьте, что фоном событий является конфликт Океании и Евразии, сути дела это не меняет.

1 марта 2022 года американский УЦ Thawte отозвал TLS-сертификаты у сайтов попавших под санкции Банка России, «ВТБ» и «ПСБ». Признаться, я сперва не поверил, что отзыв произошел именно из-за санкций – мало ли, какие могут быть причины, включая желание самих банков, но ответ Thawte на мой запрос не оставил сомнений:

We are required to comply with applicable laws and industry standards, including international sanctions and export controls. Your certificate was flagged as not being compliant with current trade sanctions. As such, we have revoked your certificate.

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

Примечание

В Thawte почему-то решили, что я интересуюсь от имени Банка России, но так даже лучше – ответ можно считать официальным ответом поставщика клиенту.

В настоящий момент сайты всех пострадавших банков доступны по HTTPS, защищенные новыми сертификатами от

американского же

бельгийского (спасибо alizar за указание на мою ошибку) УЦ GlobalSign. Ни одна из сторон, насколько известно, не выступила с заявлением по этому поводу, что меня и смутило: где хештег #MeToo на сайте Thawte? Где гневный релиз про происки заокеанской военщины от пострадавших банков? Почему новые сертификаты выпущены снова УЦ из «критически» настроенной страны? Вас это не удивило?

О терминах и системе координат

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

TLS-сертификат сайта: «бумажка», в которой декларируется всего один (и то лишь предполагаемый) факт, а именно: лицо, обладающее этим сертификатом, и лицо, администрирующее соответствующее доменное имя – одно и то же лицо, поэтому защищенное соединение с его сайтом может шифроваться и/или подписываться с помощью сертификата. Доверие к сертификату обусловлено репутацией выдавшего его УЦ, а доверие к УЦ – доверием к корневому УЦ. Это и есть «система доверия», на которой строятся «цепочки доверия» и защищенные коммуникации в современном Интернете.

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

Интересное случается на стыке санкций и сертификатов. Отношения между УЦ и его клиентами начинаются в момент получения заявки на выдачу сертификата и заканчиваются его выдачей. Срок действия сертификата может быть и 2 года, но УЦ к нему уже не имеет отношения: УЦ удостоверил определенный факт на определенную дату, получил плату за свою услугу, на этом все. Если какие-то отношения у УЦ в связи с выданным им сертификатом и продолжаются, то они уже с посетителями соответствующего сайта, которым УЦ сообщает через CRL/OCSP: да, мы выдавали такой сертификат, нет, он не отозван.

Все как у нотариуса: 28 февраля 2022 года гражданин Петров был женат на гражданке Петровой, о чем и выдано нотариальное свидетельство. 1 марта выяснилось, что гражданин Петров бабник, скотина и жулик, место ему на нарах – нотариуса это не касается, поскольку удостоверенный им факт остается фактом, во всяком случае, на дату удостоверения. И общественное порицание тоже не касается нотариуса – он удостоверял матримониальный статус гражданина Петрова, а не его человеческие добродетели. С одной оговоркой: если не будет установлено, что гражданин Петров обманул нотариуса и представил ему подложные документы о браке.

Теперь давайте вспомним, почему может быть отозван сертификат. Для этого обратимся к такому документу, как Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates, имеющему силу лишь для УЦ – членов CA/Browser Forum, но в целом отражающим общий подход к проблеме.

Итак, параграф 4.9.1.1 Reasons for Revoking a Subscriber Certificate говорит нам, что УЦ обязан (именно обязан, см. IETF RFC 2119) отозвать выданный им сертификат при наступлении любого из следующих событий:

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

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

Что ж, давайте поговорим о требованиях законодательства, а именно – о торговом эмбарго… Кубы, введенном США в 1960 году и действующим по сию пору. Эмбарго не Кастро, не Компартии Кубы и не кубинского центробанка, а всей страны оптом. Спешу успокоить дорогих читателей: хотя на первом месте по количеству выданных кубинцам сертификатов предсказуемо оказался LetsEncrypt, Thawte тоже не видит никаких препятствий с точки зрения применимого законодательства для выдачи сертификатов кубинским сайтам.

Из всех вышеупомянутых причин для отзыва сертификата более-менее подходит последняя – нарушение политики УЦ. Впрочем, речь идет не о политике вообще, а о политике выдачи сертификатов (Certificate Policy and/or Certification Practice Statement), которая про технические требования и административные процедуры, а не минимальный процент лиц определенного пола/ориентации/расы (нужное – подчеркнуть) в Правлении клиентов и прочий «этичный бизнес». См. апдейт в конце статьи.

Мы можем допустить, что в виду политической необходимости и желания внести свои

пять копеек

два цента в хайп, УЦ дополнят эту политику пунктом об отказе сотрудничества с режимами, бомбящими другие страны. Но тогда встанет неудобный вопрос: следует ли отозвать сертификаты у сайтов стран Коалиции Добра и Справедливости за бомбардировку Ливии или это другое? Не менее достойным кандидатом на отзыв станет Израиль с его добрососедскими налетами на половину стран региона. Далее – со всеми остановками.

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

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

Что делать?

Минцифры знает – создать свой УЦ с

«Кузнечиком» и «Магмой»

суверенитетом и скрепами для выдачи сертификатов госсайтам. И ведь создадут, чтобы потом плакаться: браузеростроители наш корневой сертификат в свою продукцию не включают, а пользователи устанавливать его не хотят, опасаясь (небезосновательно) MitM (Major-in-the-Middle). Про иностранных посетителей госсайтов можно будет вообще забыть.

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

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

Напоминаю, ящик Пандоры уже открыт и «системы доверия» в Интернете в прежнем виде больше не существует ни для кого. Мы можем лишь гадать, что случится дальше: отзыв сертификата у неподсанкционной российской организации или «случайная» выдача поддельного сертификата для российского сайта, скажем, ЦРУ. Из чувства солидарности, политической целесообразности или по иным «высоким» соображениям. Мы это обсудим уже в другом, новом Интернете, в котором стало меньше доверия и надежности.

UPD: в комментариях привели ссылку на пункт политики УЦ, благодаря которому Thawte может легко отбиться от моих нападок.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Должны ли УЦ отзывать уже выданные TLS-сертификаты у подсанкционных лиц?

10.97%
Да, санкции без границ и правил!
264

72.75%
Нет, уже выданные сертификаты под санкции не попадают.
1751

5.19%
У России – должны отозвать, а у других – depends on…
125

11.09%
Я не знаю, как в данном случае должен поступить УЦ.
267

Проголосовали 2407 пользователей.

Воздержались 385 пользователей.

Перед настройкой

Центральной частью схемы аутентификации Kerberos является третья доверенная сторона – Key Distribution Center (KDC), которая является централизованным хранилищем информации о пользователях. Перед разворачиванием Kerberos, должен быть выбран сервер, который будет выполнять роль KDC. Физическая и сетевая безопасность критичны для этого сервера, так как его компрометация ведет к компрометации всего realm.

Выбор хорошего имени для realm так же важен. По правилам, имя realm это доменное имя сайта в верхнем регистре. Например, для сайта или доменной зоны example.com рекомендуется выбрать EXAMPLE.COM в качестве имени realm.

Все серверы и клиенты, которые входят в realm Kerberos должны иметь возможность взаимодействовать между собой. Время между устройствами в realm должно быть синхронизовано. Далее описано как этого добиться.

Host Names

Каждый сервер внутри Kerberos realm должен иметь Fully Qualified Domain Name (FQDN).

Kerberos так же ожидает, что FQDN сервера является reverse-resolvable. Если выяснение доменного имени по IP недоступно, то установите значение переменной rdns в значение false на клиентах в файле krb5.conf.

Active Directory сильно зависит от DNS, поэтому весьма вероятно что ваш Active Directory Domain Controller уже имеет роль DNS. В этом случае убедитесь в том, что каждый сервер имеет свое FQDN перед выполнением тестов, описанных ниже в этом разделе.

Если сервер уже имеет назначенное FQDN, проверьте корректность обнаружения forward и reverse выполнив на клиенте следующие команды:

$ nslookup server.example.com
$ nslookup <server ip address>

Если вы используете Astra Linux (или другой дистрибутив), то для установки программы nslookup, вам необходимо установить пакет dnsutils.

Вы можете воспользоваться Synaptic Package Manager или выполнить из командной строки  $ apt-get install dnsutils

Вывод первой команды должен содержать IP адрес сервера. Вывод второй команды должен содержать FQDN сервера.

Если у сервера нет назначенного FQDN и сервис DNS не доступен, то вы можете отредактировать локальные файлы hosts (обычно они находятся в /etc) на сервере добавив туда следующую строку:

 127.0.0.1 server.aktiv-test.ru localhost server

А на каждом клиенте добавить строку

 <IP-address> server.aktiv-test.ru <IP-address> server

Где IP-address – это IP адрес сервера. В нашем примере это будет 10.0.0.1.

После этого проверьте работу локальных DNS имен используя команду nslookup как показано выше.

Наличие соединения

Для проверки соединения между хостами, выполните ping для каждого хоста по его FQDN:

$ ping server.aktiv-test.ru
PING server.aktiv-test.ru (10.0.0.1) 56(84) bytes of data.
64 bytes from server.aktiv-test.ru (10.0.0.1): icmp_seq=1 ttl=128 time=0.176ms 

Вывод команды ping показывает успешное определение IP адреса по FQDN, и простой ответ от сервера. Ответ от сервера является подтверждением того, что между хостом и сервером есть соединение.

Проблемы при работе ping указывают на проблемы настройки сервера или клиента.

Синхронизация времени

Протокол Kerberos требует синхронизации времени сервера и клиента: если системные часы клиентов и сервера расходятся, то аутентификация не будет выполнена. Простейший способ синхронизировать системные часы – использование Network Time Protocol (NTP) сервера. Некоторый линуксы, например, Astra Linux по-умолчанию синхронизирует время с российскими NTP-серверами. Для настройки собственного NTP-сервера смотрите документацию на ваш дистрибутив (например, UbuntuTime для Ubuntu).

Active Directory Domain Controllers обычно так же являются NTP серверами.

Брандмауэры

Так же как и все остальные сетевые службы, Kerberos должен иметь возможность проходить через любые брандмауэры между хостами. Инструкция Kerberos System Administration Manual имеет детальное описание портов, которые необходимо открыть при настройке брандмауэров.

Что имеем на входе?

1. КриптоПро CSP версии 5.0 – для поддержки Российских криптографических алгоритмов (подписи, которые выпустили в аккредитованном УЦ в РФ)

2. КриптоПро TSP Client 2.0 – нужен для штампа времени

3. КриптоПро OCSP Client 2.0 – проверит не отозван ли сертификат на момент подписания

4. КриптоПро .NET Client – таков путь

5. Любой сервис по проверке ЭП – я использовал Контур.Крипто как основной сервис для проверки ЭП и КриптоАРМ как локальный. А еще можно проверить ЭП на сайте Госуслуг

6. КЭП по ГОСТ Р 34.11-2012/34.10-2012 256 bit, которую выпустил любой удостоверяющий центр

Подписание документа ЭЦП

cryptcp  КПС   pincode src.txt dest.txt.sig

• nochain – отменяет проверку цепочки сертификатов

• pin – пин-код

• КПС1 – критерий поиска сертификата

Пример создания ЭЦП (по SHA1 Hash):

cryptcp   255c249150efe3e48f1abb3bc1928fc8f99980c4    test.txt test.txt.sig

Done.

Гайд написан с исследовательской целью – проверить возможность подписания документов УКЭП с помощью самописного сервиса на .NET Core 3.1 с формированием штампов подлинности и времени подписания документов.

Безусловно это решение не стоит брать в работу “как есть” и нужны некоторые доработки, но в целом оно работает и подписывает документы подписью УКЭП.

Соберем проект с поддержкой ГОСТ Р 34. 11-2012 256 bit

Гайд разделен на несколько этапов. Основная инструкция по сборке опубликована вместе с репозиторием DotnetCoreSampleProject – периодически я буду на нее ссылаться.

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

… и положим туда все необходимое.

Инструкция делится на 2 этапа – мне пришлось выполнить оба, чтобы решение заработало. В папку добавьте подпапки .\runtime и .\packages

I – Сборка проекта без сборки corefx для Windows

1. Установите КриптоПро 5.0 и убедитесь, что у вас есть действующая лицензия. – для меня подошла втроенная в ЭП;

2. Установите core 3.1 sdk и runtime и распространяемый пакет Visual C++ для Visual Studio 2015 обычно ставится вместе со студией; прим.: на II этапе мне пришлось через установщик студии поставить дополнительное ПО для разработки на C++ – сборщик требует предустановленный DIA SDK.

3. Задайте переменной среды DOTNET_MULTILEVEL_LOOKUP значение 0 – не могу сказать для чего это нужно, но в оригинальной инструкции это есть;

4. 1. package_windows_debug.zip распакуйте в .\packages

   2. runtime-debug-windows.zip распакуйте в .\runtime

5. Добавьте источник пакетов NuGet в файле %appdata%\NuGet\NuGet.Config – источник должен ссылаться на путь .\packages в созданной вами папке. Пример по добавлению источника есть в основной инструкеии. Для меня это не сработало, поэтому я добавил источник через VS Community;

6. git clone https://github.com/CryptoProLLC/NetStandard.Library
   New-Item -ItemType Directory -Force -Path "$env:userprofile\.nuget\packages\netstandard.library"
   Copy-Item -Force -Recurse ".\NetStandard.Library\nugetReady\netstandard.library" -Destination "$env:userprofile\.nuget\packages\"

7. Склонируйте репизиторий DotnetCoreSampleProject в .\

8. Измените файл .\DotnetSampleProject\DotnetSampleProject.csproj – для сборок System.Security.Cryptography.Pkcs.dll и System.Security.Cryptography.Xml.dll укажите полные пути к .\runtime;

9. Перейдите в папку проекта и попробуйте собрать решение. Я собирал через Visual Studio после открытия проекта.

II – Сборка проекта со сборкой corefx для Windows

1. Выполните 1-3 и 6-й шаги из I этапа;

2. Склонируйте репозиторий corefx в .\

3. Выполните сборку запустив .\corefx\build.cmd – на этом этапе потребуется предустановленный DIA SDK

4. Выполните шаги 5, 7-9 из I этапа. Вместо условного пути .\packages укажите .\corefx\artifacts\packages\Debug\NonShipping, а вместо .\runtime укажите .\corefx\artifacts\bin\runtime\netcoreapp-Windows_NT-Debug-x64

На этом месте у вас должно получиться решение, которое поддерживает ГОСТ Р 34.11-2012 256 bit.

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

Просмотр корневых сертификатов

certmgr   uroot

В более старых версиях вместо uroot следует использовать root:

certmgr   root

Добавление корневых сертификатов (под root) из файла cacer.p7b

 certmgr    uroot  cacer.p7b

Необходимо последовательно добавить все сертификаты

Для использования сертификата необходимо установить КриптоПро CSP

Описание

При открытии Панели управления Рутокен на вкладке Сертификаты после выбора сертификата отображается  сообщение: “Для использования сертификата необходимо установить КриптоПро CSP”

Причина

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

Решение

Нужно установить программный комплекс КриптоПро CSP на компьютер.

Загрузить программу можно на сайте разработчика – компании “КриптоПро”. Требуется предварительная регистрация на сайте.

Программный комплекс “КриптоПро CSP” является платной программой. Выбор версии программного продукта нужно производить в соответствии с приобретенной лицензией и версией операционной системы. При первичной установке можно активировать демоверсию на 3 месяца.

Установка этой программы с компакт-диска или других интернет-ресурсов не может гарантировать актуальность версии и совместимость с операционной системой.

Первичная настройка

Сервер

Установить пакеты и создать новый realm

$ sudo apt-get install krb5-kdc krb5-admin-server krb5-pkinit
# В диалогах указать:
# realm = AKTIV-TEST
# домен = aktiv-test.ru
$ sudo krb5_newrealm
# ввести пароль

В файле конфигурации сервера /etc/krb5. conf указать

[domain_realm]
	.aktiv-test.ru = AKTIV-TEST
	aktiv-test.ru = AKTIV-TEST

Создать на сервере нового пользователя

$ sudo kadmin.local
# username = testuser
# password = test
kadmin.local:$ addprinc <username>
# ...
kadmin.local:$ quit

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

$ kinit <username>
...
$ klist
...
$ kdestroy

Клиент

Установим pkcs11 модуль rtpkcs11ecp.so

Установим необходимые пакеты и сконфигурируем kerberos

$ sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config krb5-pkinit opensc libengine-pkcs11-openssl
# В диалогах указать:
# realm = AKTIV-TEST
# домен = aktiv-test.ru
$ sudo dpkg-reconfigure krb5-config

В файле конфигурации клиента /etc/krb5. conf указать

[domain_realm]
	...
	.aktiv-test.ru = AKTIV-TEST
	aktiv-test.ru = AKTIV-TEST

Проверим, что пользователь может аутентифицироваться по паролю

$ kinit <username>
...
$ klist
...
$ kdestroy

Стенд

• две виртуальные машины с Ubuntu

Важно: время на клиенте и сервере должно быть синхронизировано. Невыполнение этого требования может привести к возникновению проблем.

• <username> = testuser
• <realm> = AKTIV-TEST
• <server> = aktiv-test.ru

Сервер

• Установлены krb5-kdc, krb5-admin-server, krb5-pkinit 
  
• Kerberos realm: AKTIV-TEST, доменное имя aktiv-test.ru (прописано в /etc/hosts на клиенте)
  Примечание: доменное имя стоит делать минимум второго уровня для избежания ошибок 
• Пользователи: testuser@AKTIV-TEST

Клиент

• Установлены krb5-user, libpam-krb5, libpam-ccreds, auth-client-config, krb5-pkinit, opensc, libengine-pkcs11-openssl
• default realm: AKTIV-TEST
• серверы (kdc, admin) указаны по IP-адресу (лучше указать их в /etc/hosts)

Проверка подписи ЭЦП

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

Корневой сертификат УЦ, список отзыва сертификата является одним из реквизитов самого сертификата.

Контрагенты когда открывают подписи в КриптоАРМ используют revocation provider, он делает проверки отзыва сертификата онлайн.
Как реализована проверка в Шарепоинте не знаю. Знаю только что используется библиотека Крипто.Net

cryptcp  

Проверка конкретной подписи из локального хранилища по его хешу:

cryptcp   255c249150efe3e48f1abb3bc1928fc8f99980c4  test.txt.sig

Проверить, взяв сертификат из file1.sig, подпись файла file2.sig. Практически, надо использовать один и тот же файл:

cryptcp    file1.sig file2.sig

Ответ:

Certificates found: 2
Certificate chains are checked.
Folder './':
file.xls.sig... Signature verifying...
Signer: Старший инженер, Иванов Иван Иванович, Отдел закупок, ООО «Верес», Москва, RU, [email protected]
 Signature's verified.
Signer: Генеральный директор, Сидоров Иван Петрович, Руководство, ООО «Кемоптика», Москва, RU, [email protected]
 Signature's verified.
[ReturnCode: 0]

Результат:

Проверка модели устройства

1. Подключите USB-токен к компьютеру.
2. Для определения названия модели USB-токена откройте Терминал и введите команду:

$ lsusb 

В результате в окне Терминала отобразится название модели USB-токена:

Убедитесь, что используете: Aktiv Rutoken ECP

Немного покодим

Потребуется 2 COM библиотеки: “CAPICOM v2.1 Type Library” и “Crypto-Pro CAdES 1.0 Type Library”. Они содержат необходимые объекты для создания УКЭП.

В этом примере будет подписываться BASE64 строка, содержащая в себе PDF-файл. Немного доработав код можно будет подписать hash-значение этого фала.

Основной код для подписания был взят со страниц Подпись PDF с помощью УЭЦП- Page 2 (cryptopro.ru) и Подпись НЕОПРЕДЕЛЕНА при создании УЭЦП для PDF на c# (cryptopro.ru), но он использовался для штампа подписи на PDF документ. Код из этого гайда переделан под сохранение файла подписи в отдельный файл.

Условно процесс можно поделить на 4 этапа:

1. Поиск сертификата в хранилище – я использовал поиск по отпечатку в хранилище пользователя;

2. Чтение байтов подписанного файла;

3. Сохранение файла подписи рядом с файлом.

using CAdESCOM;
using CAPICOM;
using System;
using System.Globalization;
using System.IO;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;
using System.Security.Cryptography.Xml;
using System.Text;
using System.Threading.Tasks;
using System.Xml;

public static void Main()
{
  //Сертификат для подписи
	X509Certificate2 gostCert = GetX509Certificate2("отпечаток");
  //Файл, который предстоит подписать
  byte[] fileBytes = File.ReadAllBytes("C:\\Тестовое заявление.pdf");
  //Файл открепленной подписи
  byte[] signatureBytes = SignWithAdvancedEDS(fileBytes, gostCert);
  //Сохранение файла подписи
  File.WriteAllBytes("C:\\Users\\mikel\\Desktop\\Тестовое заявление.pdf.sig", signatureBytes);
}

//Поиск сертификата в хранилище
public static X509Certificate2 GetX509Certificate2(string thumbprint)
{
  X509Store store = CreateStoreObject("My", StoreLocation.CurrentUser);
  store.Open(OpenFlags.ReadOnly);

  X509Certificate2Collection certCollection =
    store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, false);

  X509Certificate2Enumerator enumerator = certCollection.GetEnumerator();
  X509Certificate2 gostCert = null;
  while (enumerator.MoveNext())
    gostCert = enumerator.Current;
  if (gostCert == null)
    throw new Exception("Certificiate was not found!");

  return gostCert;
}

//Создание УКЭП
public static byte[] SignWithAdvancedEDS(byte[] fileBytes, X509Certificate2 certificate)
{
  string signature = "";
  
  try
  {
    string tspServerAddress = @"http://qs.cryptopro.ru/tsp/tsp.srf";

    CPSigner cps = new CPSigner();
    cps.Certificate = GetCAPICOMCertificate(certificate.Thumbprint);
    cps.Options = CAPICOM_CERTIFICATE_INCLUDE_OPTION.CAPICOM_CERTIFICATE_INCLUDE_WHOLE_CHAIN;
    cps.TSAAddress = tspServerAddress;

    CadesSignedData csd = new CadesSignedData();
    csd.ContentEncoding = CADESCOM_CONTENT_ENCODING_TYPE.CADESCOM_BASE64_TO_BINARY;
    csd.Content = Convert.ToBase64String(fileBytes);

    //Создание и проверка подписи CAdES BES
    signature = csd.SignCades(cps, CADESCOM_CADES_TYPE.CADESCOM_CADES_BES, true, CAdESCOM.CAPICOM_ENCODING_TYPE.CAPICOM_ENCODE_BASE64);
    csd.VerifyCades(signature, CADESCOM_CADES_TYPE.CADESCOM_CADES_BES, true);
    
    //Дополнение и проверка подписи CAdES BES до подписи CAdES X Long Type 1 
    //(вторая подпись остается без изменения, так как она уже CAdES X Long Type 1)
    signature = csd.EnhanceCades(CADESCOM_CADES_TYPE.CADESCOM_CADES_X_LONG_TYPE_1, tspServerAddress, CAdESCOM.CAPICOM_ENCODING_TYPE.CAPICOM_ENCODE_BASE64);
    csd.VerifyCades(signature, CADESCOM_CADES_TYPE.CADESCOM_CADES_X_LONG_TYPE_1, true);
  }
  catch (Exception ex)
  {
    throw ex;
  }
  return Convert.FromBase64String(signature);
}

Пробный запуск

Для подписания возьмем PDF-документ, который содержит надпись “Тестовое заявление.”:

Далее запустим программу и дождемся подписания файла:

Готово. Теперь можно приступать к проверкам.

Проверка в КриптоАРМ

Время создания ЭП заполнено:

Штамп времени на подпись есть:

Доказательства подлинности также заполнены:

В протоколе проверки есть блоки “Доказательства подлинности”, “Штамп времени на подпись” и “Время подписания”:

Важно отметить, что серийный номер параметров сертификата принадлежит TSP-сервису http://qs.cryptopro.ru/tsp/tsp.srf

Проверка на Госуслугах

Проверка в Контур. Крипто

Ссылки на публичные источники

[1] CMS Advanced Electronic Signatures (CAdES) – https://tools.ietf.org/html/rfc5126#ref-ISO7498-2

[2] Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) – https://www.ietf.org/rfc/rfc3161.txt

[3] X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP – https://tools.ietf.org/html/rfc2560

[4] Усовершенствованная квалифицированная подпись — Удостоверяющий центр СКБ Контур (kontur.ru)

[5] Поддержка .NET Core (cryptopro.ru)

[6] http://qs.cryptopro.ru/tsp/tsp.srf – TSP-сервис КриптоПро

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

Также я забыл написать немного про подпись штампа времени – он подписывается сертификатом владельца TSP-сервиса. По гайду это ООО “КРИПТО-ПРО”:

UPD2: Про библиотеки CAdESCOM и CAPICOM

В ответ @kotov_a и @mayorovp– Все верно: для .NET Core 3.1 сборки System.Security.Cryptography.Pkcs.dll и System.Security.Cryptography.Xml.dll подменяются, так как поддержка этих алгоритмов в бета тестировании [5], а для .NET Framework 4.8 используется CryptoPro.Sharpei – он был перенесен в состав КриптоПро .NET. Последний, судя по информации с портала документации, работает только с .NET Framework.

Если создать пустой проект на .NET Core 3.1, подключив непропатченные библиотеки, то при обращении к закрытому ключу выпадет исключение “System.NotSupportedException” c сообщением “The certificate key algorithm is not supported.”:

<TargetFramework>netcoreapp3.1</TargetFramework>
...
<ItemGroup>
  <COMReference Include="CAdESCOM">
    <WrapperTool>tlbimp</WrapperTool>
    <VersionMinor>0</VersionMinor>
    <VersionMajor>1</VersionMajor>
    <Guid>e00b169c-ae7f-45d5-9c56-672e2b8942e0</Guid>
    <Lcid>0</Lcid>
    <Isolated>false</Isolated>
    <EmbedInteropTypes>true</EmbedInteropTypes>
  </COMReference>
  <COMReference Include="CAPICOM">
    <WrapperTool>tlbimp</WrapperTool>
    <VersionMinor>1</VersionMinor>
    <VersionMajor>2</VersionMajor>
    <Guid>bd26b198-ee42-4725-9b23-afa912434229</Guid>
    <Lcid>0</Lcid>
    <Isolated>false</Isolated>
    <EmbedInteropTypes>true</EmbedInteropTypes>
  </COMReference>
</ItemGroup>
...

Но при использовании пропатченных библиотек это исключение не выпадает и с приватным ключем можно взаимодействовать:

<TargetFramework>netcoreapp3.1</TargetFramework>
...
<ItemGroup>
  <Reference Include="System.Security.Cryptography.Pkcs">
    <HintPath>.\corefx\artifacts\bin\runtime\netcoreapp-Windows_NT-Debug-x64\System.Security.Cryptography.Pkcs.dll</HintPath>
  </Reference>
  <Reference Include="System.Security.Cryptography.Xml">
    <HintPath>.\corefx\artifacts\bin\runtime\netcoreapp-Windows_NT-Debug-x64\System.Security.Cryptography.Xml.dll</HintPath>
  </Reference>
</ItemGroup>
...

Также код из гайда работает с .NET Framework 4.8 без использования пропатченных библиотек, но вместо обращения к пространству имен “System.Security.Cryptography”, которое подменяется пропатченными библиотеками для .NET Core, CSP Gost3410_2012_256CryptoServiceProvider будет использован из пространства имен “CryptoPro.Sharpei”:

<TargetFrameworkVersion>v4.8</TargetFrameworkVersion>
...
<ItemGroup>
    <COMReference Include="CAdESCOM">
      <Guid>{E00B169C-AE7F-45D5-9C56-672E2B8942E0}</Guid>
      <VersionMajor>1</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <Lcid>0</Lcid>
      <WrapperTool>tlbimp</WrapperTool>
      <Isolated>False</Isolated>
      <EmbedInteropTypes>True</EmbedInteropTypes>
    </COMReference>
    <COMReference Include="CAPICOM">
      <Guid>{BD26B198-EE42-4725-9B23-AFA912434229}</Guid>
      <VersionMajor>2</VersionMajor>
      <VersionMinor>1</VersionMinor>
      <Lcid>0</Lcid>
      <WrapperTool>tlbimp</WrapperTool>
      <Isolated>False</Isolated>
      <EmbedInteropTypes>True</EmbedInteropTypes>
    </COMReference>
    <COMReference Include="CERTENROLLLib">
      <Guid>{728AB348-217D-11DA-B2A4-000E7BBB2B09}</Guid>
      <VersionMajor>1</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <Lcid>0</Lcid>
      <WrapperTool>tlbimp</WrapperTool>
      <Isolated>False</Isolated>
      <EmbedInteropTypes>True</EmbedInteropTypes>
    </COMReference>
  </ItemGroup>
...

Сертификаты

Список установленных сертификатов

certmgr -list, например:

1-------
Issuer            : [email protected], C=RU, L=Moscow, O=CRYPTO-PRO LLC, CN=CRYPTO-PRO Test Center 2
Subject           : CN=test2
Serial            : 0x120007E4E683979B734018897B00000007E4E6
SHA1 Hash         : 0x71b59d165ab5ea39e4cd73384f8e7d1e0c965e81
Not valid before  : 07/09/2015  10:41:18 UTC
Not valid after   : 07/12/2015  10:51:18 UTC
PrivateKey Link   : Yes. Container  : HDIMAGE\\test2.000\F9C9
2-------
Issuer            : [email protected], C=RU, L=Moscow, O=CRYPTO-PRO LLC, CN=CRYPTO-PRO Test Center 2
Subject           : CN=webservertest
Serial            : 0x120007E47F1FD9AE0EDE78616600000007E47F
SHA1 Hash         : 0x255c249150efe3e48f1abb3bc1928fc8f99980c4
Not valid before  : 07/09/2015  09:56:10 UTC
Not valid after   : 07/12/2015  10:06:10 UTC
PrivateKey Link   : Yes. Container  : HDIMAGE\\webserve.001\2608

Добавление реального сертификата

Добавить только сертификат (только проверка ЭЦП):

certmgr   cert.cer

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

Закрытый ключ состоит из шести key-файлов:

header.key
masks2.key
masks.key
name.key
primary2.key
primary.key

Способ с дискетой или флешкой

Скопировать в корень дискеты или флэшки сертификат и приватный ключ (из каталога 999996.000, 999996 – название (alias) контейнера):

  pathtokey mediaflashdrive
 pathtocertclient.cer mediaflashdrive

Выполнить команду по копированию ключа с флэшки на диск, ключ попадет в пользовательское хранилище My.

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

[email protected] – то, что прописано в поле E сертификата (можно посмотреть командой keytool --printcert -file /path/to/cert/client.cer):

csptest     

С жесткого диска

«Ручной способ».

Скопировать приватный ключ в хранилище (контейнер), где <username> – имя пользователя linux:

  pathtokey varoptcprocspkeysusername

Поставить «минимальные» права:

  varoptcprocspkeysusername

Узнать реальное название контейнера:

csptest  -enum_cont  

Ассоциировать сертификат с контейнером, сертификат попадет в пользовательское хранилище My:

certmgr   pathtofileclient.cer  

Если следующая ошибка, нужно узнать реальное название контейнера (см. выше):

Failed to open container \\.\HDIMAGE\<container>
[ErrorCode: 0x00000002]

Установить сертификат УЦ из-под пользователя root командой:

certmgr   uroot  pathtofileCA.cer

Проверка успешности установки закрытого ключа

certmgr 

Если выводится PrivateKey Link: Yes. Container: HDIMAGE\\999996.000\D7BB, то есть и сертификат, и приватный ключ, а если выводится PrivateKey Link: No – связи нет, и использовать такой контейнер для подписи не удастся.

Источник

Добавление тестового сертификата

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

cryptcp      test.csr

Ввести пароль на контейнер test123.

cryptcp      myname.csr

Пароль mysecurepass

Откройте в браузере ссылку тестовый удостоверяющий центр КриптоПро

cryptcp    certnew.cer

Ввести пароль на контейнер. По-умолчанию: 12345678

Удаление сертификата

Проверка сертификата

certmgr   file.sig

Ответ:

1-------
Issuer            : [email protected], C=RU, L=Москва, O=ООО КРИПТО-ПРО, CN=УЦ KPИПTO-ПPO
Subject           : [email protected], C=RU, L=г. Москва, O="ООО ""Верес""", OU=Руководство, CN=Иванов Иван Иванович, T=Генеральный директор
Serial            : 0x75F5C86A000D00016A5F
SHA1 Hash         : 0x255c249150efe3e48f1abb3bc1928fc8f99980c4
Not valid before  : 08/12/2014  09:04:00 UTC
Not valid after   : 08/12/2019  09:14:00 UTC
PrivateKey Link   : No

Подписание пустого файла (размер 0) проходит успешно, но при просмотре сертификатов этого файла выдается ошибка:

Can't open certificate store: '/tmp/tmp.G8cd13vzfZ.sig'.
Error: No certificate found.
/dailybuilds/CSPbuild/CSP/samples/CPCrypt/Certs.cpp:312: 0x2000012D
[ErrorCode: 0x2000012d]

Будьте внимательны!

Просмотр всех атрибутов сертификата

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

Получаем SHA 1 хеши:

certmgr -list -f file.sig | grep 'SHA1 Hash'

В цикле извлекаем сертификаты:

cryptcp -nochain -copycert -thumbprint 255c249150efe3e48f1abb3bc1928fc8f99980c4 -f file.sig -df certificate.der -der

openssl x509 -in certificate.der -inform der -text -noout

Настройка openssl для поддержки ГОСТ:

В файл /etc/ssl/openssl.cnf

 openssl_def # Это в начало файла
#Все что ниже в конец

 
 

 
 

 
 /usr/lib/ssl/engines/libgost.so # заменить реальным файлом
 
 

Проверка:

openssl ciphers        gost
GOST2001-GOST89-GOST89
GOST94-GOST89-GOST89

Экспорт сертификатов на другую машину

Закрытые ключи к сертификатам находятся тут: /var/opt/cprocsp/keys. Поэтому эти ключи переносятся просто: создаем архив и переносим на нужную машину в тот же каталог.

Экспорт самих сертификатов (если их 14):

 i    ;     certmgr   .cer; 

Переносим эти файлы на машину и смотрим, какие контейнеры есть:

csptest -keyset -enum_cont -verifycontext -fqcn

И как обычно, связываем сертификат и закрытый ключ:

certmgr -inst -file 1.cer -cont '\\.\HDIMAGE\container.name'

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

Can not install certificate
Public keys in certificate and container are not identical

Если все успешно:

Если нет закрытого ключа, то просто ставим сертификат:

certmgr -inst -file 1.cer

Так, а что надо на выходе?

А на выходе надо получить готовое решение, которое сделает отсоединенную ЭП в формате .sig со штампом времени на подпись и доказательством подлинности. Для этого зададим следующие критерии:

1. ЭП проходит проверку на портале Госуслуг, через сервис для подтверждения подлинности ЭП формата PKCS#7 в электронных документах;

2. КриптоАРМ после проверки подписи

   1. Заполнит поле “Время создания ЭП” – в конце проверки появится окно, где можно выбрать ЭП и кратко посмотреть ее свойства

      

   2. В информации о подписи и сертификате (двойной клик по записе в таблице) на вкладке “Штампы времени” в выпадающем списке есть оба значения и по ним заполнена информация:

   3. В протоколе проверки подписи есть блоки “Доказательства подлинности”, “Штамп времени на подпись” и “Время подписания”. Для сравнения: если документ подписан просто КЭП, то отчет по проверке будет достаточно коротким в сравнении с УКЭП.

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

   

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

Сервер

Создадим ключ и самоподписанный сертификат УЦ

$ openssl genrsa -out cakey.pem 2048 
$ openssl req -key cakey.pem -new -x509 -out cacert.pem

Создадим файл pkinit_extensions со следующим содержимым

[ kdc_cert ]
basicConstraints=CA:FALSE
 
# Here are some examples of the usage of nsCertType. If it is omitted
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
 
#Pkinit EKU
extendedKeyUsage = 1.3.6.1.5.2.3.5
 
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
 
# Copy subject details
 
issuerAltName=issuer:copy
 
# Add id-pkinit-san (pkinit subjectAlternativeName)
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name
 
[kdc_princ_name]
realm = EXP:0, GeneralString:${ENV::REALM}
principal_name = EXP:1, SEQUENCE:kdc_principal_seq
 
[kdc_principal_seq]
name_type = EXP:0, INTEGER:1
name_string = EXP:1, SEQUENCE:kdc_principals
 
[kdc_principals]
princ1 = GeneralString:krbtgt
princ2 = GeneralString:${ENV::REALM}
 
[ client_cert ]
 
# These extensions are added when 'ca' signs a request.
 
basicConstraints=CA:FALSE
 
keyUsage = digitalSignature, keyEncipherment, keyAgreement
 
extendedKeyUsage =  1.3.6.1.5.2.3.4
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
 
 
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name
 
 
# Copy subject details
 
issuerAltName=issuer:copy
 
[princ_name]
realm = EXP:0, GeneralString:${ENV::REALM}
principal_name = EXP:1, SEQUENCE:principal_seq
 
[principal_seq]
name_type = EXP:0, INTEGER:1
name_string = EXP:1, SEQUENCE:principals
 
[principals]
princ1 = GeneralString:${ENV::CLIENT}

Создадим ключ и сертификат KDC

$ openssl genrsa -out kdckey.pem 2048
# создание запроса
$ openssl req -new -out kdc.req -key kdckey.pem
# подпись запроса
$ REALM=<realm>; export REALM
$ CLIENT=<server>; export CLIENT
# содержимое файла pkinit_extensions выше
$ openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert -CAcreateserial

Переместим файлы kdc. pem, kdckey. pem, cacert. pem в директорию /etc/krb5/

$ sudo mkdir /etc/krb5
$ sudo cp kdc.pem kdckey.pem cacert.pem /etc/krb5/

Включим preauth на сервере. Для этого опишем realm AKTIV-TEST в файле /etc/krb5kdc/kdc. conf

[realms]
    AKTIV-TEST = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
        default_principal_flags = +preauth
        pkinit_anchors = FILE:/etc/krb5/cacert.pem
        pkinit_identity = FILE:/etc/krb5/kdc.pem,/etc/krb5/kdckey.pem
    } 

Включим preauth для пользователя

$ sudo kadmin.local
$ kadmin.local$: modprinc +requires_preauth <username>

Клиент

Отформатируйте токен с помощью утилиты rtadmin

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

# не забываем про ID!
$ pkcs11-tool --module /usr/lib/librtpkcs11ecp.so --keypairgen --key-type rsa:2048 -l --id 45
openssl
OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:librtpkcs11ecp.so
...
OpenSSL> req -engine pkcs11 -new -key 45 -keyform engine -out client.req -subj "/C=RU/ST=Moscow/L=Moscow/O=Aktiv/OU=dev/CN=testuser/[email protected]"

Сервер

Копируем заявку на сертификат (client. req). И подписываем ее.

$ REALM=<realm>; export REALM
$ CLIENT=<username>; export CLIENT
$ openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem

Перезапустим сервер и KDC

 $ /etc/init.d/krb5-admin-server restart
 $ /etc/init.d/krb5-kdc restart

Обратно клиент

Получаем сертификат и записываем его на токен. Также нужно положить корневой сертификат в /etc/krb5/

$ pkcs11-tool --module /usr/lib/librtpkcs11ecp.so -l -y cert -w ./client.pem --id 45
$ sudo cp cacert.pem /etc/krb5/cacert.pem

Изменим файл конфигурации /etc/krb5. conf

[libdefaults]
	default_realm = <realm>
	pkinit_anchors = FILE:/etc/krb5/cacert.pem
# для аутентификации по локальному ключу
#	pkinit_identities = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem
# для аутентификации по токену
	pkinit_identities = PKCS11:/usr/lib/librtpkcs11ecp.so

Пробуем аутентифицироваться

Примечание

Если по каким-то причинам не удалось аутентифицироваться, то можно узнать об причине неисправности с помощью логирования. Для этого в файле настройки /etc/krb5. conf и /etc/krb5kdc/kdc. conf.

[logging]
	default = FILE:/var/log/krb5.log
	kdc = FILE:/var/log/krb5kdc.log
	admin_server = FILE:/var/log/kadmin.log

При этом после этого нужно перезагрузить KDC с помощью команд:

 $ /etc/init.d/krb5-admin-server restart
 $ /etc/init.d/krb5-kdc restart