Windows: создание CSR-запроса для сертификата подписи кода или драйвера | Сертификаты SSL – GoDaddy Справка RU

Что такое запрос на подпись сертификата (csr)?

Запрос на подпись сертификата (CSR – Certificate Signing Request) содержит наиболее важную информацию о вашей организации и домене. Это зашифрованный блок текста, который включает информацию о вашей организации, такую как страна, адрес электронной почты, полное доменное имя и так далее Он отправляется в центр сертификации при подаче заявки на сертификат SSL.

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

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

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

CSR обычно содержит следующую информацию:

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

Сертификат Secure Socket Layer (SSL) – это протокол безопасности, который защищает данные между двумя компьютерами с использованием шифрования.

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

Как правило, сертификаты SSL используются на веб-страницах, которые передают и получают конфиденциальные данные конечного пользователя, такие как номер социального страхования, данные кредитной карты, домашний адрес или пароль. Онлайн формы оплаты являются хорошим примером и обычно шифруют вышеупомянутую деликатную информацию с использованием 128 или 256-битной технологии SSL.

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

Apache

При использовании библиотеки OpenSSL в Apache закрытый ключ по умолчанию сохраняется в /usr/local/ssl. Запустите openssl version –a, команду OpenSSL, которая определяет, какую версию OpenSSL вы используете.

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

OpenSSL 1.0.2g  1 Dec 2021

built on: reproducible build, date unspecified

platform: debian-amd64

options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)

compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -

D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-

strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-

Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -

DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -

DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -

DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM

OPENSSLDIR: "/usr/lib/ssl"

Последняя строка OPENSSLDIR определяет путь к файлу. В приведенном примере это местоположение по умолчанию /usr/lib/ssl.

Вариант 1: создать csr

Первое, что нужно сделать, – это создать 2048-битную пару ключей RSA локально. Эта пара будет содержать как ваш закрытый, так и открытый ключ. Вы можете использовать инструмент Java key или другой инструмент, но мы будем работать с OpenSSL.

Чтобы создать открытый и закрытый ключ с запросом на подпись сертификата (CSR), выполните следующую команду OpenSSL:

openssl req –out certificatesigningrequest.csr -new -newkey rsa:2048 -nodes -keyout privatekey.key

Что эта команда означает:

• openssl – активирует программное обеспечение OpenSSL
• req – указывает, что мы хотим CSR
• –out – указывает имя файла, в котором будет сохранен ваш CSR. У нас в примере это certificatesigningrequest.csr
• –new –newkey – создать новый ключ
• rsa:2048 – cгенерировать 2048-битный математический ключ RSA
• –nodes – нет DES, то есть не шифровать закрытый ключ в PKCS#12 файл
• –keyout – указывает домен, для которого вы генерируете ключ

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

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

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

ls *.csr

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

Также вы можете открыть файл .csr в текстовом редакторе, например nano, чтобы просмотреть сгенерированный буквенно-цифровой код.

sudo nano your_domain.csr

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

openssl req -in server.csr -noout -text

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

Вариант 4: генерация самоподписанного(self-signed) сертификата

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

openssl req -newkey rsa:2048 -nodes -keyout domain.key-x509 -days 365 -out domain.crt

Параметр –days установлен на 365, что означает, что сертификат действителен в течение следующих 365 дней. Параметр x509 указывает, что это будет самозаверяющий сертификат. Временный CSR генерируется, и он используется только для сбора необходимой информации. Если вы не хотите защищать свой закрытый ключ паролем, вы можете добавить параметр –nodes.

Центры сертификации не проверяют самоподписанные сертификаты. Таким образом, они не так безопасны, как проверенные сертификаты. Если ЦС не подписал сертификат, каждый основной браузер отобразит сообщение об ошибке «Ненадежный сертификат», как показано на рисунке ниже.

Галопом по европам оставшимся типам

СMS предлагает еще несколько интересных типов сообщений, не охватываемых темой этой статьи. Поэтому буквально по паре слов об оставшихся типах для общей картины.

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

Хешированные данные (данные вместе со своим хешем) используются для проверки целостности сообщения и часто являются содержимым упакованных данных.

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

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

В следующей статье мы подробно остановимся на сообщениях типа enveloped data с использованием российских криптоалгоритмов.

Для чего нужен cms

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

Некоторые из указанных атрибутов носят опциональный характер, но приложение может само определить необходимость их наличия. У каждого алгоритма есть набор параметров, который должен быть согласован на обеих сторонах: для ГОСТ 34.10-2001, помимо открытого ключа, это модуль

p

, коэффициенты эллиптической кривой

ab

и порядок циклической подгруппы точек эллиптической кривой

q

. И все это нужно каким-то образом передать адресату сообщения.

RSA Laboratories в серии своих стандартов криптографии с открытом ключом (PKCS) предложила решение этой проблемы путем определения синтаксиса для защищенных сообщений в следующих стандартах:

Развитием этих стандартов стал стандарт CMS. CMS кроме

определенной заголовком статьи

подписи поддерживает операции шифрования, хеширования и вычисления имитовставки, в том числе и по российским алгоритмам (

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

Всего CMS поддерживает шесть типов данных:

В рамках статьи мы подробно рассмотрим только данные с электронной подписью (signed data).

Чтобы не путаться в терминологии, далее исходные данные, которые мы хотим передать защищенным способом, будут называться данными, а получившееся защищенное сообщение CMS – просто сообщением.

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

Закрытый ключ

Закрытый ключ кодируется и создается в формате PEM на основе Base-64, который не читается человеком. Вы можете открыть его в любом текстовом редакторе, но все, что вы увидите, это несколько десятков строк, которые кажутся случайными символами, заключенными в открывающие и закрывающие заголовки. Ниже приведен пример закрытого ключа:

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQCVqGpH2S7F0CbEmQBgmbiDiOOGxhVwlG yY/6OBQoPKcx4Jv2h
vLz7r54ngjaIqnqRNP7ljKjFLp5zhnAu9GsdwXbgLPtrmMSB MVFHTJvKjQ eY9p
dWA3NbQusM9uf8dArm 3VrZxNHQbVGXOIAPNHTO08cZHMSqIDQ6OvLma7wIDAQAB
AoGAbxKPzsNh826JV2A253svdnAibeSWBPgl7kBIrR8QWDCtkH9fvqpVmHa 6pO5
5bShQyQSCkxa9f2jnBorKK4 0K412TBM/SG6Zjw DsZd6VuoZ7P027msTWQrMBxg
Hjgs7FSFtj76HQ0OZxFeZ8BkIYq0w 7VQYAPBWEPSqCRQAECQQDv09M4PyRVWSQM
S8Rmf/jBWmRnY1gPPEOZDOiSWJqIBZUBznvOPOOQSH6B vee/q5edQA2OIaDgNmn
AurEtUaRAkEAn7/65w Tewr89mOM0RKMVpFpwNfGYAj3kT1mFEYDq iNWdcSE6xE
2H0w3YEbDsSayxc36efFnmr//4ljt4iJfwJAa1pOeicJhIracAaaa6dtGl/0AbOe
f3NibugwUxIGWkzlXmGnWbI3yyYoOta0cR9fvjhxV9QFomfTBcdwf40FgQJAH3MG
DBMO77w8DK2QfWBvbGN4NFTGYwWg52D1Bay68E759OPYVTMm4o/S3Oib0Q53gt/x
TAUq7IMYHtCHZwxkNQJBAORwE 6qVIv/ZSP2tHLYf8DGOhEBJtQcVjE7PfUjAbH5
lr  9qUfv0S13gXj5weio5dzgEXwWdX2YSL/asz5DhU=
-----END RSA PRIVATE KEY-----

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

Инфраструктура открытых ключей: утилита генерации запросов на квалифицированный сертификат

Одним из центральных объектом инфраструктуры открытых ключей (Public Key Infrastructure — PKI/ИОК) наряду с ключевой парой является сертификат, который сегодня фактически является аналогом гражданского паспорта.

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

Сертификат, также как и паспорт, выдается на основании заявления и предоставления ряда документов. Перечень документов для получения сертификата есть на любом удостоверяющем центре, имеющим аккредитацию Минкомсвязи (новое название — министерство цифрового развития, связи и массовых коммуникаций). Заявление на паспорт имеет собственноручную подпись заявителя. В момент получения паспорта заявитель поставит свою подпись и в паспорт, которая будет заверена сотрудником паспортного стола и гербовой печатью. Фотография и умение владельца воспроизводить свою подпись и позволяют идентифицировать его как владельца конкретного паспорта.

По аналогичной схеме происходит и получение сертификата ключа проверки электронной подписи (СКПЭП). Сначала гражданин, желающий получить сертификат, должен приобрести «навык» в проставлении собственноручной подписи. Этот «навык» реализуется через получение заявителем ключевой пары, которая содержит открытый ключ или ключ проверки электронной подписи (КПЭП) и закрытый ключ или ключ электронной подписи, который, собственно, и позволяет генерировать электронную подпись и подписывать электронный документ. Идентификация электронной подписи под документом осуществляется по следующему алгоритму. Из сертификата определяется каким ключом (ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2021 с длиной ключа 64 или 128 байт) был подписан документ. По типу ключа определяется алгоритм хэширования, который использовался при подписании документа. Это может быть ГОСТ Р 34.11-94 или ГОСТ Р 34.11-2021 с длиной хэш 256 или 512 бит. По выбранному алгоритму считается хэш от исходного документа. А по значению посчитанного хэш от исходного документа, публичного ключа (КПЭП) и его параметрам (все это берется из сертификата СКПЭП) и проверяется достоверность электронной подписи под документом.

Для создания ключевой пары используются различные средства криптографической защиты информации (СКЗИ), поддерживающие криптографические алгоритмы ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2021. При этом следует помнить, что использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2021 года не допускается! СКЗИ, которые реализуют различные криптографические алгоритмы и протоколы могут быть как программными, так и аппаратными. Доступ к СКЗИ осуществляется через криптографические интерфейсы. Абсолютное большинство сертифицированных СКЗИ с российской криптографией поддерживает либо универсальный криптографический интерфейс PKCS#11, который поддерживается на всех платформах, либо интерфейс CSP и CryptoAPI от Микрософт на платформах MS Windows (далее MS CSP). Именно эти два криптографических интерфейса и поддерживаются, например, порталом Госуслуг. Именно эти два типа СКЗИ и будут рассматриваться далее:

Следует иметь ввиду, что если есть желание или необходимость работы с электронной подписью не только на платформе Windows, но и на других платформах (Linux, macOS и т.п.), то следует выбирать токены PKCS#11 с поддержкой российской криптографии.

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

Комбинированное поле (combobox) «Выберите токен:» на основном окне содержит список доступных СКЗИ для генерации ключевой пары. Если утилита генерации запроса запущена на платформе Windows и на ней установлены криптопровайдеры CSP с поддержкой российской криптографии, то в перечне доступных СКЗИ («Выберите токен:») будет определен и виртуальный токен «MS_CSP». Так что, если есть желание использовать криптопровайдер MS CSP, то он должен быть установлен в системе до запуска утилиты.

Для добавления поддержки нового токена PKCS#11 достаточно выбрать пункт меню «Управление Токенами->Добавить Токен». Добавление поддержки для нового токена состоит в выборе библиотеки PKCS#11 для подключаемого типа токенов/смарткарт и задании удобного имени (никнайма). При добавлении поддержки нового типа токенов (а также при запуске утилиты, если ранее была добавлена поддержка токенов) при подключенном (вставленном) токене будет затребован PIN-код для доступа к нему:

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

p11conf

:

Выбрав пункт «Управление Токенами->Механизмы Токена», можно посмотреть криптографические механизмы того или иного токена, например, есть ли поддержка алгоритма ГОСТ Р 34.10-2021. Для виртуального токена MS_CSP перечисляются все провайдеры CSP с поддержкой ГОСТ-алгоритмов и поддерживаемые ими механизмы:

Если выбранный токен не поддерживает выбранный тип ключевой пары, то будет выдано соответствующее сообщение:

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

И каждая роль связана с множеством различных OID-ов, включаемых в сертификат. Так, например, для доступа на портал Госуслуг необходимы следущие oid-ы:

{Госуслуги} {clientAuth, emailProtection, 1.3.6.1.4.1.311.20.2.2, 1.2.643.100.2.1, 
1.2.643.2.2.34.6, 1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4, 1.2.643.5.1.24.2.1.3, 
1.2.643.6.14, 1.2.643.3.215.4, 1.2.643.3.215.5, 1.2.643.3.215.6, 1.2.643.3.215.7, 
1.2.643.3.215.8, 1.2.643.3.215.9, 1.2.643.3.215.11, 1.2.643.3.215.12, 1.2.643.3.215.13, 1.3.6.1.4.1.40870.1.1.1, 1.2.643.2.64.1.1.1, 1.2.643.3.5.10.2.12, 1.2.643.6.3.2, 
1.2.643.5.1.24.2.46, 1.2.643.6.45.1.1.1, 1.2.643.5.1.24.2.30, 1.2.643.5.1.28.2, 
1.2.643.5.1.28.3, 1.2.643.3.202.1.8}

OID-ы для других ролей (например, «Площадка Газпромбанк», «Потребитель спирта» и т.д.) можно найти в исходном коде утилиты (переменная oid_roles_bad, оператор:

set oid_roses_bad {. . .}

).

Наличие такого количества oid-ов трудно понять. Речь идет о квалифицированных сертификатах, в которых присутствуют oid-ы ИНН, ОГРН, СНИЛС и т.п., которые однозначно идентифицируют и физическое лицо и юридическое лицо и, кажется, этого было бы достаточно для доступа на портал Госуслуг, да и на другие тоже. Но, Dura lex, sed lex — Закон суров, но это закон.

В поле «Наименование СКЗИ» необходимо указать название СКЗИ (токен/смарткарта, CSP), которое прописано в сертификате соответствия (не путать с сертификатом X509) ФСБ России или другом аналогичном документе, копию которого должна предоставляться в момент приобретения СКЗИ. В последующем значение этого поля войдет в сертификат.

Итак, определившись с СКЗИ и ключевой парой, можно приступать к заполнению электронного заявления/запроса на сертификат ключа проверки электронной подписи (СКПЭП):

Первым заполняется поле «Common Name», в которое заносится полное имя будущего владельца сертификата. Для физического лица это ФИО как в паспорте. Для юридического лица это наименование компании из ЕГРЮЛ. Эта информация для юридического лица автоматически будет продублирована в поле «Наименование организации» («O»):

При заполнении формы проверяется правильность заполнения полей ИНН, ОГРН, СНИЛС (при вводе не цифры поле становится красным, правильно заполненные поля становятся зеленоватыми), адреса электронной почты:

После заполнения всех полей запроса и нажатия кнопки «Finish» в итоге будет получен запрос на сертификат:

Про сертификаты:  Технологии работы с электронной подписью / Хабр

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

Напомним, что ключевая пара содержит два ключа: закрытый и открытый. Открытый ключ, который еще называют ключом проверки электронной подписи, отправляется в запрос на сертификат. Для просмотра сгенерированного запроса, который содержит и открытый ключ, используется меню «Сертификаты->Просмотр запроса»:

Закрытый ключ остается у заявителя на его токене, PIN-код (пароль) от которого необходимо хранить как зеницу ока Своего. А поскольку существует

однозначное соответствие

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

Теперь со всеми необходимыми документами, со сгенерированным запросом на флэшке можно идти в ближайший удостоверяющий центр и получать сертификат. Итак запрос поступает для выпуска сертификата в один из УЦ, созданных с учетом Федерального закона от 6 апреля 2021г. №63-ФЗ «Об электронной подписи»:

Запрос в УЦ пройдет стадии импорта, рассмотрения, утверждения и выпуска сертификата по данному запросу:

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

И вот теперь, когда получен сертификат, осталось положить его на СКЗИ (PKCS#11, MS CSP) (Сертификаты->Импорт x509):

Убедиться, что сертификат находится на токене, можно просмотрев содержимое токена/смарткарты (Сертификаты->Просмотр x509 на токене):

Ну и чтобы это была «броня» (Дайте мне такую БУМАЖКУ! Окончательная Бумажка, Броня. (Собачье Сердце к/ф)), подключим токен к браузеру

Firefox

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

Утилита CreateCSRCAFL63 разработана на

Tcl/Tk

. Для доступа к криптографическим функциям MS CSP и токенов PKCS#11 разработан пакет cwapi, реализующий требования к библиотекам C со стороны Tcl. Реализовать эти требования

не сложно

, но порой отнимает много времени в силу своей рутинности. И тут на помощь приходит общедоступная утилита

SWIG.

, которая позволяет создавать интерфейсные модули между библиотеками C/C и другими языками. Это не только Tcl, но и Java и другие. Проект очень хорошо документирован и имеет прекрасные примеры. Воспользоваться им не представляет труда. В нашем случае для получения интерфейсного модуля был написан простой исходный файл cwapi.i для утилиты swig:

%module cwapi
%inline %{
#include "cwapi.h"
%}
%include "cwapi_SWIG.h"

В файле cwapi.h находятся описания функций из основного проекта cwapi:

#ifdef __cplusplus
extern "C" {
#endif
    int CW_Initialize (char *configdir);
    int CW_Finalize ();
    int addp11mod (char *nickname, char *library);
    int remp11mod (char *nickname);
    char *  lmod ();
    char *  ltok ();
    char *  lcert (char *token, int priv_cert);
    char* createreq (char *token, char *subject, char *keyusage, int keyparams, int pem, char *skzi, char* role);
    char* viewx509 (char *nickname, int CertOrReq);
    char* x509pem (char *nickname);
    char*  x509fromfile(char *token, char *infile, char *trusts);
    int delcert (char *nickname, int priv_cert);
    int p12tofile (char *token, char *nickname, char *outfile);
    char*  p12fromfile(char *token, char *infile);
    char* lmech(char* token);
    char* tinfo(char* token);
#ifdef __cplusplus
}
#endif

Выполнив команду:

$export SWIG_LIB=/usr/local/swig-3.0.12/Lib 
$/usr/local/swig-3.0.12/swig -tcl8   -o cwapi_wrap.c cwapi_.i
$

в файле cwapi_wrap.c получим готовый интерфейсный модуль. Добавляем его в проект cwapi, пересобираем его и получаем новый пакет, который и используется в данной утилите.

Для получения дистрибутива очень удобно использовать утилиту

freewrap

, при этом библиотека cwapi также включается непосредственно в дистрибутив. Исходный код утилиты и дистрибутивы доступны для платформ Windows и Linux.

Хотелось бы упомянуть еще об одной утилите, а именно о tcl2c. Эта утилита «заварачивает» tcl/tk-код в C-код.

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

$cc -o create_csr_С create_csr.c -ltcl -ltk
$

В состав дистрибутивов для платформы Linux включен и дистрибутив на языке С со статическим подключением пакета cwapi.

Как выпустить самоподписанный ssl сертификат и заставить ваш браузер доверять ему

Все крупные сайты давно перешли на протокол https. Тенденция продолжается, и многие наши клиенты хотят, чтобы их сайт работал по защищенному протоколу. А если разрабатывается backend для мобильного приложения, то https обязателен. Например, Apple требует, чтобы обмен данными сервера с приложением велся по безопасному протоколу. Это требование введено с конца 2021 года.

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

Чтобы выпустить сертификат для вашего локального домена, понадобится корневой сертификат. На его основе будут выпускаться все остальные сертификаты. Да, для каждого нового top level домена нужно выпускать свой сертификат. Получить корневой сертификат достаточно просто.
Сначала сформируем закрытый ключ:

openssl genrsa -out rootCA.key 2048

Затем сам сертификат:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

Нужно будет ввести

страну

,

город

,

компанию

и т.д. В результате получаем два файла:

rootCA.key

и

rootCA.pem

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

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

if [ -z "$1" ]
then
  echo "Please supply a subdomain to create a certificate for";
  echo "e.g. mysite.localhost"
  exit;
fi

Создадим новый приватный ключ, если он не существует или будем использовать существующий:

if [ -f device.key ]; then
  KEY_OPT="-key"
else
  KEY_OPT="-keyout"
fi

Запросим у пользователя название домена. Добавим возможность задания “общего имени” (оно используется при формировании сертификата):

DOMAIN=$1
COMMON_NAME=${2:-$1}

Чтобы не отвечать на вопросы в интерактивном режиме, сформируем строку с ответами. И зададим время действия сертификата:

SUBJECT="/C=CA/ST=None/L=NB/O=None/CN=$COMMON_NAME"
NUM_OF_DAYS=999

В переменной SUBJECT перечислены все те же вопросы, который задавались при создании корневого сертификата (

страна

,

город

,

компания

и т.д). Все значение, кроме CN можно поменять на свое усмотрение.

Сформируем csr файл (Certificate Signing Request) на основе ключа. Подробнее о файле запроса сертификата можно почитать в этой статье.

openssl req -new -newkey rsa:2048 -sha256 -nodes $KEY_OPT device.key -subj "$SUBJECT" -out device.csr

Формируем файл сертификата

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

v3.ext

. Обращаю ваше внимание, что это отдельный файл, а не часть bash скрипта.

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = %%DOMAIN%%
DNS.2 = *.%%DOMAIN%%

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

v3.ext

Возвращаемся в наш bash скрипт. На основе вспомогательного файла v3.ext создаем временный файл с указанием нашего домена:

cat v3.ext | sed s/%%DOMAIN%%/$COMMON_NAME/g > /tmp/__v3.ext

Выпускаем сертификат:

openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days $NUM_OF_DAYS -sha256 -extfile /tmp/__v3.ext

Переименовываем сертификат и удаляем временный файл:

mv device.csr $DOMAIN.csr
cp device.crt $DOMAIN.crt

# remove temp file
rm -f device.crt;

Скрипт готов. Запускаем его:

./create_certificate_for_domain.sh mysite.localhost

Получаем два файла:

mysite.localhost.crt

и

device.key

Теперь нужно указать web серверу пути к этим файлам. На примере nginx это будет выглядеть так:

Запускаем браузер, открываем https://mysite.localhost и видим:

Браузер не доверяет этому сертификату. Как быть?

Нужно отметить выпущенный нами сертификат как Trusted. На Linux (Ubuntu и, наверное, остальных Debian-based дистрибутивах) это можно сделать через сам браузер. В Mac OS X это можно сделать через приложение Keychain Access. Запускаем приложение и перетаскиваем в окно файл mysite.localhost.crt. Затем открываем добавленный файл и выбираем Always Trust:

Обновляем страницу в браузере и:

Успех! Браузер доверяет нашему сертификату.

Сертификатом можно поделиться с другими разработчиками, чтобы они добавили его к себе. А если вы используете Docker, то сертификат можно сохранить там. Именно так это реализовано на всех наших проектах.

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

Максим Ковтун,
Руководитель отдела разработки

Как реализовать на практике?

Стандарт CMS/PKCS#7 с поддержкой российских криптоалгоритмов реализован в сертифицированных СКЗИ наших партнеров:

Кроме того, стандарт CMS с российской криптографией реализован в Open Source приложении OpenSSL.

Наша компания поддержала CMS c российской криптографией в продукте Рутокен Плагин. Рутокен Плагин предназначен для использования в браузерах, все криптографические операции производятся аппаратно, «на борту» USB-токена.

Как создать csr

Запросы на подпись сертификата (CSR) создаются с помощью пары ключей – открытого и закрытого ключа. Только открытый ключ отправляется в центр сертификации и включается в сертификат SSL, и он работает вместе с вашим личным ключом для шифрования соединения. Любой может иметь доступ к вашему открытому ключу, и он проверяет подлинность SSL-сертификата.

Закрытый ключ – это блок закодированного текста, который вместе с сертификатом проверяет безопасное соединение между двумя компьютерами. Он не должен быть общедоступным, и его не следует отправлять в ЦС.

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

Большинство пар ключей состоят из 2048 битов. Хотя пары ключей длиной 4096 бит более безопасны, они замедляют SSL-рукопожатия и создают нагрузку на серверные процессоры. Из-за этого большинство сайтов по-прежнему используют 2048-битные пары ключей.

Как создать сертификат ssl

То, как сгенерировать запрос на подпись сертификата (CSR), зависит исключительно от платформы, которую вы используете, и конкретного выбранного вами инструмента.

Мы будем генерировать CSR с использованием OpenSSL.

OpenSSL – это широко используемый инструмент для работы с CSR-файлами и SSL-сертификатами, который можно загрузить с официального сайта OpenSSL. Это инструмент реализации с открытым исходным кодом для SSL/TLS, который используется примерно на 65% всех активных интернет-серверов, что делает его неофициальным отраслевым стандартом.

Клиент

В нашей системе во внешний мир смотрит сервер IIS с ASP.NET web-api с методом, выдающим сертификат по запросу PKCS#10. На клиенте, то-есть на самих демо-площадках, крутится приложение на AngularJs, работающее с

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

— передаем функции плагина createPkcs10 данные полей для формирования запроса PKCS#10, получаем текст запроса.— текст запроса PKCS#10 передаем post-запросом на метод апи, получаем сертификат или ошибку в случае невозможности выписать сертификат.— передаем функции плагина importCertificate полученный сертификат, импортируем его на устройство.

Подпись в cms-формате (signed data type)

Подпись, описанная стандартом CMS, характеризуется следующими особенностями:

1. Данные могут быть подписаны несколькими сторонами (множественная подпись). В таком случае в сообщении будут присутствовать несколько структур SignerInfo с информацией о подписывающих сторонах: значением подписи и необходимой для проверки ее подлинности информацией.
2. Тип данных никак не регламентируется, лишь уточняется, что в качестве данных может быть сообщение формата CMS, то есть подписанное Алисой сообщение может быть целиком подписано Бобом.
3. Подписывать можно не только данные, но и некоторые атрибуты сообщения – хеш сообщения (digest message), время подписи (signing time), значение другой подписи (countersignature).
4. Открытый ключ подписывающей стороны может быть несертифицированным.
5. Подпись может отсутствовать и вовсе.

Данные с электронной подписью используются не только для подписи содержимого и часто используются для распространения сертификатов и списков отзыва сертификатов (Certification Revocation List, CRL). В таком случае подписываемые данные отсутствуют, а поля Certificates и CRLs, наоборот, присутствуют.

Подписанное Алисой сообщение в формате CMS будет иметь следующий вид (серым отмечены необязательные атрибуты):

• Версия синтаксиса CMS Version зависит от сертификатов, типа подписываемых данных и информации о подписывающих сторонах
• Digest Algorithms включает в себя идентификаторы используемых алгоритмов хеширования и ассоциированные с ними параметры.
• Encapsulated Content содержит подписываемые данные (Content) вместе с их типом (Content Type). Содержимое может отсутствовать, тип – нет.
• Certificates предназначен для цепочки сертификатов, отражающих путь сертификации от центра сертификации, выдавшего сертификат, до каждой из подписывающих сторон. Также могут присутствовать сертификаты подписывающих сторон.
• CRLs (Certificate Revocation List) предоставляет информацию о статусе отзыва сертификатов, достаточную для определения валидности сертификата подписывающей стороны.
• Информация о каждой подписывающей стороне содержится в структурах типа Signer Info, которых может быть любое количество, в том числе и нулевое (в случае отсутствия подписи).

Если Боб решает целиком подписать полученное от Алисы сообщение, то используется механизм инкапсуляции, и сообщение будет выглядеть вот так:

CMS предлагает два интересных атрибута, расширяющих возможности обычной подписи: время подписи (Signing Time) и контрасигнатуру (Countersignature). Первый атрибут определяет предполагаемое время осуществления подписи, а второй предназначен для подписи другой подписи (подписывается хеш от значения подписи).

Атрибут Countersignature представляет собой структуру Signer Info с отсутствующим в Signed Attributes атрибутом Content Type и обязательно присутствующим атрибутом Message Digest. Атрибут Countersignature может иметь свой собственный атрибут Countersignature.

Если Боб решит подписать только данные, переданные Алисой, и заодно подписать подпись Алисы, то сообщение будет иметь такой вид:

Проверить версию openssl

Эта команда отображает версию OpenSSL, и ее параметры, с которыми она была скомпилирована:

openssl version -a

Получим примерно такой вывод:

OpenSSL 1.0.1f 6 Jan 2021
built on: Mon Apr  7 21:22:23 UTC 2021
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

Проверка подписанного cms на сервере

Будем генерировать CMS на клиенте и отправлять его на сервер, где проверим подпись и цепочку сертификатов.

Из BouncyCastle задействуем:— Проверку подписи signed CMS— Построение цепочки сертификатов

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

Проверку подписанного CMS делаем так:

// сторим цепочку сертификатов
public void verifyCert(X509Certificate cert)
		{
			try
			{
				// читаем корневой сертификат
				var pRd = new PemReader(new StringReader(cCACert));
				var _cCACert = (X509Certificate)pRd.ReadObject();
				pRd.Reader.Close();


				// список сертификатов для цепочки
				IList certList = new ArrayList();
				certList.Add(_cCACert);
				certList.Add(cert);

				IX509Store x509CertStore = X509StoreFactory.Create( "Certificate/Collection",
			   new X509CollectionStoreParameters(certList));

				//делаем список корневых сертификатов, в данном случае один
				ISet trust = new HashSet();
				trust.Add(new TrustAnchor(_cCACert, null));

				PkixCertPathBuilder cpb = new PkixCertPathBuilder();
				X509CertStoreSelector targetConstraints = new X509CertStoreSelector();
				targetConstraints.Subject = cert.SubjectDN;
				PkixBuilderParameters parameters = new PkixBuilderParameters(trust, targetConstraints);

				parameters.AddStore(x509CertStore);
				// отключаем проверку crl
				parameters.IsRevocationEnabled = false;

				// строим цепочку, если построилась - ок
				PkixCertPathBuilderResult result = cpb.Build(parameters);


			}
			catch (PkixCertPathBuilderException certPathEx)
			{
				throw new PkixCertPathBuilderException(string.Format("Ошибка проверки цепочки, {0}", certPathEx.Message));
			}
			catch (Exception ex)
			{
				throw new Exception(string.Format("Ошибка проверки сертификата: {0}", cert.SubjectDN), ex);
			}
		}

// проверка signed CMS
		public string verifyCms(string cmsText)
		{
			CmsSignedData cms = new CmsSignedData(Base64.Decode(cmsText));
			SignerInformationStore sif = cms.GetSignerInfos();
			var signers = sif.GetSigners();
			var ucrts = cms.GetCertificates("collection");
			//var crl = cms.GetCrls("collection");
			
			// нужно проверять все, но у нас один signer и один сертификат
			foreach (SignerInformation signer in signers)
			{

				ICollection certCollection = ucrts.GetMatches(signer.SignerID);
				IEnumerator certEnum = certCollection.GetEnumerator();

				certEnum.MoveNext();
				X509Certificate cert = (X509Certificate)certEnum.Current;

				if (!signer.Verify(cert))
				{
					throw new CertificateException("проверка подписи не прошла");
				}

				verifyCert(cert);
			}

			return "ok";
		}

Еще раз повторюсь, пример подходит для тестирования или демонстрации решений, работающих с российскими сертификатами.

Сервер

Но вернемся на серверную часть. Итак, у нас есть корневой сертификат в формате PEM и закрытый ключ к нему. Будем выдавать пользовательский сертификат по запросу PKCS#10. Сам запрос также приходит от клиента в текстовом виде, в формате PEM.

		/* тестовый корневой сертификат */
		const string cCACert = @"-----BEGIN CERTIFICATE-----
*** сам сертификат ***
-----END CERTIFICATE-----";

		/* ключ корневого сертификата*/
		const string cCAKey = @"-----BEGIN PRIVATE KEY-----
*** ключ ***
-----END PRIVATE KEY-----";

// выписываем тестовый сертификат
public string generateTestCert(string pkcs10text)
		{
			// читаем приватный ключ
			PemReader pRd = new PemReader(new StringReader(cCAKey));
			AsymmetricKeyParameter _cCAKey = (AsymmetricKeyParameter)pRd.ReadObject();
			pRd.Reader.Close();

			// читаем корневой сертификат
			pRd = new PemReader(new StringReader(cCACert));
			var _cCACert = (X509Certificate)pRd.ReadObject();
			pRd.Reader.Close();

			// как вариант:
			//X509CertificateParser certParser = new X509CertificateParser();
			//var _caCert = certParser.ReadCertificate(Base64.Decode(cCACert.Replace("-----BEGIN CERTIFICATE-----", string.Empty).Replace("-----END CERTIFICATE-----",string.Empty)));

			Pkcs10CertificationRequest _pkcs10;
			// читаем pkcs10
			using (StringReader _sr = new StringReader(pkcs10text))
			{
				pRd = new PemReader(_sr);
				_pkcs10 = (Pkcs10CertificationRequest)pRd.ReadObject();
				pRd.Reader.Close();
			}


			// выпускаем сертификат
			X509V3CertificateGenerator v3CertGen = new X509V3CertificateGenerator();

			var requestInfo = _pkcs10.GetCertificationRequestInfo();
			var subPub = _pkcs10.GetPublicKey();
			var issPub = _cCACert.GetPublicKey();

			// серийный номер
			var randomGenerator = new CryptoApiRandomGenerator();
			var random = new SecureRandom(randomGenerator);
			var serialNumber =
				BigIntegers.CreateRandomInRange(
					BigInteger.One, BigInteger.ValueOf(Int64.MaxValue), random);

			v3CertGen.Reset();
			v3CertGen.SetSerialNumber(serialNumber);
			v3CertGen.SetIssuerDN(_cCACert.IssuerDN);
			v3CertGen.SetNotBefore(DateTime.UtcNow);
			// сертификат на год
			v3CertGen.SetNotAfter(DateTime.UtcNow.AddYears(1));
			v3CertGen.SetSubjectDN(requestInfo.Subject);
			v3CertGen.SetPublicKey(subPub);

			if (issPub is ECPublicKeyParameters)
			{

				// в тестовых примерах можно посмотреть на генерацию с различными алгоритмами, на нужен только GOST3411withECGOST3410
				ECPublicKeyParameters ecPub = (ECPublicKeyParameters)issPub;
				if (ecPub.AlgorithmName == "ECGOST3410")
				{
					v3CertGen.SetSignatureAlgorithm("GOST3411withECGOST3410");
				}
				else
				{
					throw new Exception("нужен алгоритм подписи GOST3411withECGOST3410");
				}
			}
			else
			{
				throw new Exception("нужен GOST3411withECGOST3410");
			}

			// extensions
			v3CertGen.AddExtension(
				X509Extensions.SubjectKeyIdentifier,
				false,
				new SubjectKeyIdentifier(SubjectPublicKeyInfoFactory.CreateSubjectPublicKeyInfo(subPub)));

			v3CertGen.AddExtension(
				X509Extensions.AuthorityKeyIdentifier,
				false,
				new AuthorityKeyIdentifier(SubjectPublicKeyInfoFactory.CreateSubjectPublicKeyInfo(issPub)));

			v3CertGen.AddExtension(
				X509Extensions.BasicConstraints,
				false,
				new BasicConstraints(false));

			X509Certificate _cert = v3CertGen.Generate(_cCAKey);

			_cert.CheckValidity();
			_cert.Verify(issPub);

			var s = new StringWriter();
			PemWriter pw = new PemWriter(s);

			pw.WriteObject(_cert);
			pw.Writer.Close();

			return s.ToString();
		}

Создание csr-запроса и закрытого ключа

1. В консоли MMC разверните узел Сертификаты (локальный компьютер), а затем Личные.
2. Щелкните Сертификаты правой кнопкой мыши, а затем перейдите в следующее меню: Все задачи > Дополнительные операции > Создать настраиваемый запрос.
3. Нажмите «Далее».
4. Щелкните Политика регистрации Active Directory.
5. В поле Шаблон выберите Веб-сервер.
6. Убедитесь, что в поле Формат запроса выбрано значение PKCS #10, а затем нажмите кнопку Далее.
7. Щелкните кнопку со стрелкой вниз рядом с полем Сведения и выберите Свойства.
8. В меню Тип выберите следующие значения, введите соответствующее значение и нажмите кнопку Добавить:
   

   Тип	Значение
   Общее название	Название вашего предприятия или организации
   Организация	Название вашего предприятия или организации
   Населенный пункт	Адрес вашего предприятия или организации
   Область	Область или регион размещения вашего предприятия или организации
   Страна	Страна размещения вашего предприятия или организации

9. Перейдите на вкладку Общие и введите понятное имя для вашего сертификата.
10. Перейдите на вкладку Закрытый ключ, щелкните Тип ключа и выберите Сделать закрытый ключ экспортируемым.
11. Нажмите кнопку OK, а затем кнопку Далее.
12. Нажмите кнопку Обзор, чтобы выбрать расположение для сохранения файла, введите имя файла и нажмите кнопку Готово.

Запрос на подпись сертификата сохраняется в этом файле на локальном компьютере.

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

Установка openssl в debian и ubuntu

Сначала проверим, установлена ли у нас утилита OpenSSL при помощи команды:

dpkg -l |grep openssl

Если пакет OpenSSL установлен, мы получим следующий результат:

ii libgnutls-openssl27:amd64   2.12.23-12ubuntu2.4   amd64   GNU TLS library - OpenSSL wrapper

ii openssl   1.0.1f-1ubuntu2.16   amd64   Secure Sockets Layer toolkit - cryptographic utility

Если вы не видите такого результата, выполните следующую команду для установки OpenSSL:

apt-get install openssl

Установка openssl в red hat и centos

Red Hat (версия 7.0 и более поздние) должна поставляться с предустановленной ограниченной версией OpenSSL. Он предлагает только ограниченную поддержку для IDEA, RC5 и MDC2, поэтому вы можете установить недостающие функции.

Чтобы проверить, установлен ли OpenSSL на сервере yum (например, Red Hat или CentOS), выполните следующую команду:

rpm -qa | grep -i openssl

Эта команда должна вернуть следующий результат:

openssl-1.0.1e-48.el6_8.1.x86_64
openssl-devel-1.0.1e-48.el6_8.1.x86_64
openssl-1.0.1e-48.el6_8.1.i686

Если ваш формат вывода отличается, это означает, что OpenSSL не установлен на вашем сервере. Выполните следующую команду для установки OpenSSL:

yum install openssl openssl-devel

Чуть истории

Синтаксис криптографических сообщений (CMS) впервые был определен в

, который позже был опубликован в качестве рекомендаций

. Спустя еще несколько версий RFC в сентябре 2009 года был принят

, который является действующим стандартом на данный момент.

Под спойлером иллюстрируется тяжелая судьба стандарта.

Расширенная проверка (ev ssl – extended validation)

Центр сертификации проверяет право собственности на домен и проводит тщательное расследование организации, связанной с сертификатом EV. При рассмотрении расширенного запроса проверки соблюдаются строгие правила, и центр сертификации должен проверить следующее:

1. Информация об организации соответствует официальным данным
2. Физическое, юридическое и эксплуатационное существование субъекта
3. Организация имеет исключительные права на использование домена, указанного в сертификате SSL
4. Организация надлежащим образом санкционировала выдачу сертификата EV SSL