Назад | Перейти на главную страницу

OpenSSL генерирует сертификат с порядком байтов, кодировкой и кодировкой

У меня возникли проблемы с созданием сертификата с помощью инструмента командной строки openssl.

Спецификации закрытого ключа:

«Цифровая подпись с использованием 1024-битного ключа RSA с хэш-функцией SHA-1 (RSA-SHA1-1024)»

Создание его следующим образом

openssl genrsa -out rsa.key 1024

Генерация CSR

openssl req -new -key rsa.key -out csr.csr

Сертификат имеет следующие характеристики:

Я пробовал множество комбинаций из следующего:

openssl x509 -req -utf8 -enc base64 -pkcs -sha1 rsa:1024 -in csr.csr -signkey rsa.key -out server.crt

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

Согласно спецификации, мы должны подписать дайджест сообщения RSA с данным сертификатом. Я немного запутался, почему и как мы должны это делать, может, это ошибочная спецификация?

Техническая документация

я использую OpenSSL 1.1.0f 25 мая 2017 г.

Endianess я даже не могу найти, как установить его с помощью инструмента командной строки openssl, любая помощь здесь будет сильно оценил!

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

Вот как можно создать простой закрытый ключ RSA 1024 и извлечь открытый ключ в отдельный файл:

openssl genrsa -out rsa.key 1024
openssl rsa -in rsa.key -outform PEM -pubout -out rsa.pub

В rsa.pub файл - это то, что вы бы отправили в NTA. Я никогда не слышал, чтобы кому-то нужно было иметь дело с порядком байтов в openssl. Так что я могу ошибаться, но вам, вероятно, не стоит об этом беспокоиться. Кодировка UTF8, вероятно, имеет значение только для реальных сертификатов с текстовыми полями, такими как Тема. Openssl выводит файлы PEM с кодировкой ASCII, что нормально (и нормально), потому что PEM закодирован в Base64. Заполнение PKCS1 v1.5 также является стандартным.

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

echo -n 'signature_from_previous_receipt;2014-01-24;23:59:59;123456789;1250.00;1000.00' > data.txt

Отобразите хеш SHA1, чтобы доказать, что у нас есть данные, соответствующие примеру

openssl dgst -sha1 data.txt

Хеш и подпишите данные, преобразуйте их в base64 без разрывов строк и сохраните в файл.

openssl dgst -sha1 -sign rsa.key data.txt | openssl base64 -A -out data.sig

Гипотетически текст внутри data.sig теперь то, что вы использовали бы для "signature_for_this_receipt" из примера.

Чтобы проверить, мы можем просто сделать следующее, что должно вывести "Verified OK".

openssl dgst -sha1 -verify rsa.pub -signature <(openssl base64 -d -A -in data.sig) data.txt

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

openssl req -nodes -x509 -sha1 -utf8 -newkey rsa:1024 -keyout rsa.key -out server.crt -days 365 -subj "/CN=MyCert"