Openssl mac verify error invalid password

PKCS#12 incorrect password error #84

Steps to reproduce

1. Generate any PKCS#12 on examples page with a password.
2. Try to extract key using OpenSSL command with the same password
   openssl pkcs12 -in pkijs_pkcs12.p12 -nocerts -out key.pem -nodes
   the result is an error: Mac verify error: invalid password?
3. Try to import into Windows certification store with the same password using certmgr.msc
   the result is an error: The password you entered is incorrect

The text was updated successfully, but these errors were encountered:

Check this link for some additional explanations about PKCS#12 and OpenSSL/Windows integration. As a small conclusion: Windows will not understand any of PKCS#12 bundles made by PKI.js, OpenSSL will understand only some of them.

Also please carefully read note on the example’s page you were referring to:

I decided to update the issue with some new information. So, not so long ago I found that PKIjs was having incorrect algorithm for MacData processing. That is why all had the problems with Mac verify error . The error fixed already, btw. As for Windows The password you entered is incorrect — this example could produce PKCS#12 files which could be successfully parsed by Windows. The example is running on Node only — Windows is using old 3DES and RC2 algorithms and we do not have them in browser evironment.

Источник

🔐 Как использовать OpenSSL для управления архивом PKCS #12

Что такое PKCS #12 ?

В криптографии PKCS#12 — один из стандартов семейства Public-Key Cryptography Standards (PKCS), опубликованных RSA Laboratories. Он определяет формат файла, используемый для хранения и/или транспортировки закрытого ключа (en:Private key), цепочки доверия от сертификата пользователя до корневого сертификата удостоверяющего центра и списка отзыва сертификатов (CRL). Защита файла осуществляется одним из двух способов: безопасным, с использованием доверенной ключевой пары (открытый/закрытый ключи, подходящие для цифровой подписи и шифрования) или менее безопасным, с использованием симметричного ключа, основанного на пароле. Второй подходит для случаев, когда использование доверенных пар открытый/закрытый ключей недоступны. Формат PKCS#12 — это формат, предназначенный для хранения ключевой пары (закрытый ключ и сертификат), который распознается и используется многими браузерами и почтовыми агентами. В файлах PKCS#12 хранятся одновременно и сертификат, и закрытый ключ (разумеется в зашифрованном виде). Примерная организация PKCS#12 файла показана на рисунке справа.

Как создать образец сертификата.

Файл закрытого ключа example.org.key.

Выполним операции по PKCS #12

Создадим архив PKCS #12, используя

в качестве пароля.

Выведем информацию о файле PKCS# 12 для простой проверки.

Введите пароль с помощью командной строки.

Введите пароль, используя файл.

Извлечение и отображение сертификатов, приватных ключей из архива PKCS #12.

Извлечение сертификатов и закрытых ключей из архива PKCS # 12 в файл.

Источник

viking_k

Записная книжка IT-шника

идеи / интересы / шлак

Итак понадобилось мне получить доступ к единому реестру запрещенных ресурсов, но все оказалось не так просто как хотелось бы.

Вводная:
Сервер на Debian 7
ЭЦП на etoken, в нутре контейнера ViPNet
Необходимо автоматерировать процесс регулярного обращения к реестру запрещенных ресурсов и выгрузки с него списка «плохишей»

Начало войны — Несправедливость:
Под Виндой все работает великолепно. Достаточно установить ViPNet CSP для управления сертификатами и ViPNet CryptoFile для подписи файлов. Все это есть на сайте производителя. Но для Линуксов ничего есть только программа ViPNet CSP, да и та в бета-тестирвании.

Битва первая — Драйвер:
Электронные ключи eToken выпускаются компанией Аладин Р.Д., драйвера можно скачать на соответствующем сайте. Приятно порадовало есть драйвера для платформ отличный от Windows.

Для моего Debian это выглядило так:

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

$ pkcs11-tool —module /usr/lib/libeTPkcs11.so —slot 0 -Ol

Содержимое объекта в слоте можно посмотреть так:

$pkcs11-tool —module /usr/lib/libeTPkcs11.so —slot 0 -a ‘ViPNet Container’ -y data -r
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
.

В общем и целом делаем вывод, что драйвера на eToken встали великолепно, НО ViPNet CSP для линукс его в упор не видит и естественно открыть свой контейнер не может.
Для проверки еще попытался подойти к вопросу со стороны. Открываем наш любимый браузер — Mozilla Firefox, и пользуемся вот такой инструкцией:

Битва вторая — Контейнер

Зализав раны от побоища я обратился за помощью к Windows и таки корректно извлек контейнер из eToken с помощью ViPNet CSP . А так же из ViPNet CSP экспортировал ЭЦП в формат PKCS#12 в файл name.pfx. Счастью не было придела. Но оказалось:

1. На Windows без установленного ViPNet CSP файл с сертификатом name.pfx не рапаковывается, ругаясь на неправильный пароль. Хотя пароль вводился 100% правильный.
Если ViPNet CSP установить то все распаковывается на ура. Без ViPNet CSP так же нельзя провести ниодин экспорт. Эта зараза помещает сикретный ключ в свой собственный контейнер с отдельным паролем. А при удалении забирает все контейнеры на небеса.

2. Утилита P12FromGostCSP так же не может произвести экспорт сертификата в формате PKCS#12 ругаясь на то, что с ViPNet она работать не умеет.

3. На Debian средствами OpenSSL просмотреть файл не удалось. Хотя пароль опять же вводился 100% правильный.

Попытка включить поддержку шифрования по ГОСТ для OpenSSL результатов не принесла.
В общем и целом ситуация складывается безвыходная — с конейнерами ViPNet может работать только сам ViPNet и больше никто. Средств для автоматизации процесов нет ни под Windows ни под Linux.
Битва проиграна.

Битва Третья — Другой криптопровайдер

Подписываем файл запроса на Роскомнадзор:

Источник

Бложег

блог о быдлокодинге

пятница, 15 июня 2012 г.

Использование OpenSource крипто библиотек для работы с ГОСТовыми сертификатами CryptoPro

В данной статье делается попытка ответить на вопрос: возможно ли использовать OpenSource библиотеки для работы с ГОСТовыми сертификатами?
Если коротко, то да.
Для проверки использовалась последняя на данный момент версия OpenSSL (1.0.1с), собранная из исходников с поддержкой gost engine
Для начала нужно установить КриптоПро CSP 3.6 R3, поскольку в нем реализована поддержка экспорта сертификатов в формате pfx. Эту часть работ нужно делать в операционной системе Windows. Не буду описывать подробно этот процесс, скажу лишь, что нужно сохранить приватный ключ в формате CryptoPro на флэшку и импортировать его в хранилище «Реестр». Выгрузив сертификат в файл, например store.pfx (включая приватный ключ), можно вывести приватный ключ в stdout командой

• -info вывести информацию о содержимом файла в формате pkcs12 (.pfx)
• -engine использовать указанный криптографический модуль
• -nodes не нужно шифровать приватный ключ
• -in входной файл

Если вы получаете ошибку вида «unknown PBE algorithm»

То это означает, что вам потребуется другое средство для получения pfx файла, утилитка P12FromGostCSP.exe
Если вы получаете ошибку вида «unknown digest algorithm»

Enter Import Password:
MAC Iteration 2048
Mac verify error: invalid password?
140572666472096:error:2306B076:PKCS12 routines:PKCS12_gen_mac:unknown digest algorithm:p12_mutl.c:88:
140572666472096:error:2307E06D:PKCS12 routines:PKCS12_verify_mac:mac generation error:p12_mutl.c:122:
то скорее всего в вашем openssl нет поддержки ГОСТовых алгоритмов либо вы используете не ту копию openssl.

Если все прошло без ошибок, то в консоли вы получите приватный ключ и сертификат. Скопировав выведенный в консоль приватный ключ (вместе со словами ——BEGIN PRIVATE KEY—— и ——END PRIVATE KEY——) в отдельный файл private.key мы сможем с его помощью создавать ЭЦП.

Команда для генерации примерно следующая:

• -sign генерация подписи
• -inkey путь к приватному ключу
• -in подписываемый файл
• -CAfile файл УЦ
• -signer файл с сертификатом, которым осуществляется подпись
• -engine использовать указанный криптографический модуль
• -out файл, в который будет записана ЭЦП
• -outform формат подписи
• -noattr не добавлять дополнительных аттрибутов в подпись
• -binary считать подписываемый файл массивом байт, а не текстом

К сожалению, Bouncy Castle (версии 1.46), хоть в нем и декларируется поддержка ГОСТовых алгоритмов, не может разобрать формат приватного ключа, так что использовать его для генерации ЭЦП на данный момент не представляется возможным.

UPD:
Bouncy Castle 1.55 уже умеет работать с такими приватными ключами

Источник

exp build iOS enterprise app error: PKCS#12 MAC could not be verified. Invalid password? #1771

Hi, I use expo build the iOS enterprise app and it report the Invalid password error. But I have regenerate the p12 file and reset the password and it still error.

The build error:

I have verify the p12 file password locally and it is correct.

I can publish the iOS app using the same password last week. But it failed today. Is something broken? Thanks.

The text was updated successfully, but these errors were encountered:

Hi @zhaozhiming — what an odd error 😕 A quick google search suggests that sometimes setting an empty password or a password with non-ASCII characters could potentially cause this issue. Could you try setting a different password for your p12 file (maybe a simple, but non-empty, one) and let us know if that works?

My password is very simple. First time I set the password to 123 , second time I set to 111 , but they both failed.

@zhaozhiming — okay, thanks for the info. It looks like we’ve recently changed how we run the signing code on our servers. I’ll ping someone internally and see if we can get this figured out.

@esamelson Thanks. Waiting for your good news.

Same problem, very simple password

@zhaozhiming @jonatanrinckus
I found the issue in our code. The problem occurs only for passwords which have only digits. I’ll add support for them (i’ll fix the bug) soon, but until then you can change your passwords to something that have at least one letter. Please let me know if it resolves the problem for you. Thanks!

Источник

Skip to end of metadata

Go to start of metadata

chroot /app/reductor/
/gost-ssl/bin/openssl pkcs12 -in /cfg/userinfo/p12.pfx -nodes

. /usr/local/Reductor/etc/const
chroot_mount
chroot /usr/local/Reductor/reductor_container/ /gost-ssl/bin/openssl pkcs12 -in /root/p12.pfx -nodes
chroot_umount

Error outputting keys and certificates
140254691182248:error:06074079:digital envelope routines:EVP_PBE_CipherInit:unknown pbe algorithm:evp_pbe.c:167:TYPE=1.2.840.113549.1.12.1.80
140254691182248:error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit error:p12_decr.c:83:
140254691182248:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error:p12_decr.c:130:

Итак понадобилось мне получить доступ к единому реестру запрещенных ресурсов, но все оказалось не так просто как хотелось бы.

Вводная:
Сервер на Debian 7
ЭЦП на etoken, в нутре контейнера

ViPNet
Необходимо автоматерировать процесс регулярного обращения к реестру запрещенных ресурсов и выгрузки с него списка «плохишей»

Начало войны — Несправедливость:
Под Виндой все работает великолепно. Достаточно установить ViPNet CSP для управления сертификатами и ViPNet CryptoFile для подписи файлов. Все это есть на сайте производителя. Но для Линуксов ничего есть только программа ViPNet CSP, да и та в бета-тестирвании.

Битва первая — Драйвер:
Электронные ключи eToken выпускаются компанией  Аладин Р.Д., драйвера можно скачать на соответствующем сайте. Приятно порадовало есть драйвера для платформ отличный от Windows.

Для моего Debian это выглядило так:

Устанавливаем версию java от Oracle. Смотрим версию Java:

#apt-get remove OpenJDK*

Устанавливаем java от Oracle:

#apt-key adv —keyserver keyserver.ubuntu.com —recv-keys EEA14886

#apt-get install oracle-java7-installer

#apt-get install ia32-libs libhal1 opensc pcscd

#dpkg -l | grep libhal1

#dpkg -l | grep libpcsclite1

#dpkg -x libpcsclite1_1.8.4-1_amd64.deb libpcsclite1-amd64

#dpkg -x libhal1_0.5.14-8_amd64.deb libhal1-amd64

#cp libpcsclite1-amd64/usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0 /lib64/

#ln -s /lib64/libpcsclite.so.1.0.0 /lib64/libpcsclite.so.1

#cp libhal1-amd64/usr/lib/libhal.so.1.0.0 /usr/lib64/

#ln -s /usr/lib64/libhal.so.1.0.0 /usr/lib64/libhal.so.1

#dpkg -i SafenetAuthenticationClient-8.0.5-0_amd64.deb
#ln -s /usr/lib64/libeTPkcs11.so /usr/lib/

Список слотов на eToken можно увидеть так:

[Инструкция использования eToken]

Но к сожалению и Firefox тоже не увидел содержимого eToken, хотя само устройство идентифицировал.
Битва проиграна….

Битва вторая — Контейнер

Зализав раны от побоища я обратился за помощью к Windows и таки корректно извлек контейнер из eToken с помощью ViPNet CSP. А так же из ViPNet CSP экспортировал ЭЦП в формат PKCS#12 в файл name.pfx. Счастью не было придела. Но оказалось:

1. На Windows без установленного ViPNet CSP файл с сертификатом name.pfx не рапаковывается, ругаясь на неправильный пароль. Хотя пароль вводился 100% правильный.
Если ViPNet CSP установить то все распаковывается на ура. Без ViPNet CSP так же нельзя провести ниодин экспорт. Эта зараза помещает сикретный ключ в свой собственный контейнер с отдельным паролем. А при удалении забирает все контейнеры на небеса.

2. Утилита P12FromGostCSP так же не может произвести экспорт сертификата в формате PKCS#12 ругаясь на то, что с ViPNet она работать не умеет.

3. На Debian средствами OpenSSL просмотреть файл не удалось. Хотя пароль опять же вводился 100% правильный.

# openssl pkcs12 -in ./name.pfx  -nodes

Enter Import Password:

Mac verify error: invalid password?

Попытка включить поддержку шифрования по ГОСТ для OpenSSL  результатов не принесла.
В общем и целом ситуация складывается безвыходная — с конейнерами ViPNet может работать только сам ViPNet и больше никто. Средств для автоматизации процесов нет ни под Windows ни под Linux.
Битва проиграна…

Битва Третья — Другой криптопровайдер

Еще предстоит…

OpenSSL

Подписываем файл запроса на Роскомнадзор:

#nano openssl.cnf

…

openssl_conf = openssl_def

[ new_oids ]

…

# OpenSSL GOST

[openssl_def]

engines = engine_section

[engine_section]

gost = gost_section

[gost_section]

default_algorithms = ALL

engine_id = gost

# dynamic_path = /usr/local/lib/engines/libgost.so

CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet

Проверяем наличее ГОСТ

#openssl ciphers | tr «:» «n» | grep GOST

проверяем, что у нас нормальный (содержит сертификат и закрытый ключ) PKCS#12 командой:

#openssl pkcs12 -in p12.pfx -nodes

#openssl pkcs12 -in p12.pfx -out provider.pem -nodes -clcerts

#iconv -f UTF8 -t WINDOWS-1251 request.xml -o request.xml

#openssl smime -sign -in request.xml -out request.bin -signer provider.pem -outform DER

Остались не раскрытыми:

• проблемы связанные с ruToken

Ссылки на софт:

• КРИПТО-CSP
• ЛИССИ-CSP, также: утилита P12FromGostCSP, Библиотеки PKCS#11, таинственные утилиты
• ViPNet CSP
• eToken — Аладин Р.Д.

…

openssl_conf = openssl_def

[ new_oids ]

…

# OpenSSL GOST

[openssl_def]

engines = engine_section

[engine_section]

gost = gost_section

[gost_section]

default_algorithms = ALL

engine_id = gost

# dynamic_path = /usr/local/lib/engines/libgost.so

CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet