Здравствуйте. У бухгалтера ключ с сертификатом. Я экспортировал его в PFX.

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

Всякие диадоки, сбисы его видят и работают. Но КриптоПро в "Посмотреть сертификаты в контейнере" говорит: В контейнере закрытого ключа, отсутствуют сертификаты.

Пожалуйста, объясните, что происходит.

Я полагаю, у меня как-то не корректно работает закрытый ключ ? Но ведь в реестре всё есть. Выходит у меня сейчас только открытая часть, но её достаточно для каких-то сервисов, а в каких-то может не заработать ?

Не понял. Он же есть в: Сертификаты-Личное-Сертификаты.

А как правильно с ключа экспортировать в PFX? Мне надо на терминальной ферме распространять бухам.

В чем щас у меня могут быть проблемы ?

И о каком контейнере речь?

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

Недобавление сертификата из PFX в новый контейнер очень часто спасает от накладок со сроком действия ключа, сравнительно с которыми мелочь вручную поставить сертификат в контейнер. Если захотите подробностей, то смотрите на форуме https://sedkazna.ru/foru...iew=category&catid=1 где в каждой инструкции кричат что не надо ставить сертификат в контейнер.

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

UPD. Если контейнеры хранить в корне несистемного диска или считывателе директория возможно при помощи символических ссылок сделать контейнеры видимыми нескольким серверам. Либо прикрутить некую синхронизацию. Еще вариант при подключении по терминалу вставлять токен на клиентском месте (токены автоматом пробрасываются по RDP, от установки вручную в хранилище может спасти служба Распространение сертификатов).

Отредактировано пользователем 20 мая 2021 г. 11:44:59(UTC)  | Причина: Не указана

Здравствуйте.
Как писал выше Андрей *, после установки pfx на Windows надо дополнительно экспортировать сертификат в cer-файл, а затем через панель управления КриптоПро CSP установить его.
Добавлю, что на unix-системах (Linux/macOS/iOS) при установке pfx-а сертификат сразу попадает в контейнер и это действие не требуется. В ближайшее время мы выложим финальный релиз КриптоПро CSP 5.0 R2 (сборка 5.0.12000 Kraken), где и на Windows будет такое же удобное поведение: дополнительных действий больше не потребуется.

Отредактировано пользователем 3 июня 2021 г. 9:30:58(UTC)  | Причина: Не указана

К сожалению, в ряде случае такое поведение как раз неудобное, а удобнее как сейчас без сертификата в контейнере.

Причина: отсутствие штатного механизма удаления сертификата из контейнера либо замены сертификата в контейнере. Если сертификат уже установлен, то функция cryptoapi для установки сертификата возвращает ошибку, как и утилита csptest. При различных операциях с внутренним УЦ (для аккредитованных УЦ наверно не так актуально) возможен случай когда выпускается новый сертификат УЦ на тот же открытый ключ (кросс-сертификат, например, сертификат с откорректированными адресами или сертификат, подхватывающий клиентские сертификаты при смене ключа УЦ в Майкрософт УЦ) и в этом случае оставлять "предыдущую версию" сертификата в контейнере будет не самой хорошей идеей.

До сих пор проблема обходилась экспортом в PFX и импортом обратно, что удаляло сертификат из контейнера и можно было установить новый сертификат с тем же открытым ключом. На новой версии криптопровайдера предлагается в таком случае еще и заменять/удалять сертификат в самом PFX? Либо можно сохранить некий исполняемый файл (certmgr.exe ?) от другой версии криптопровайдера чтобы "по-старому" получать контейнер без сертификата? Или можно использовать некий ключ командной строки позволяющий пропустить импорт сертификата в контейнер?

Впрочем, если большинству пользователей удобно получать контейнер с сертификатом, то пусть будет так, однако прошу реализовать идею о штатном механизме удаления сертификата из контейнера либо замены сертификата в контейнере. Хотя бы в виде отдельной утилиты командной строки, напрямую работающей с header.key. Пробовал такую написать сам, но споткнулся на неопубликованном способе вычисления контрольной суммы - удалением сертификата из ASN1 структуры получился header.key идентичный сохраненному до импорта сертификата кроме 4 байт контрольной суммы.

К слову, если контейнер связан в хранилище с другим сертификатом (сертификат 1) чем установленный сертификат в контейнере (сертификат 2), открытый ключ одинаков в сертификатах 1 и 2, то какой сертификат предполагается экспортировать в PFX? Полагаю, если будет экспортировать в PFX сертификат из хранилища, а не из контейнера, то это как раз решит проблему замены. Ну а только в случае неудачного поиска по открытому ключу в хранилище использовать сертификат из контейнера.
Что-то вроде такого:
Дано: "старый" контейнер с установленным "старым" сертификатом.
1) выпускается "новый" сертификат (кросс-сертификат) на тот же открытый ключ;
2) "новый" сертификат устанавливается в хранилище, со ссылкой на тот же "старый" контейнер;
3) "старый" сертификат удаляется из хранилища для однозначного поиска по открытому ключу в хранилище;
4) экспортируется PFX с сертификатом из хранилища (в данном случае найден "новый" в хранилище);
5) импортируется PFX и получаем "новый" контейнер с "новым" сертификатом, плюс меняется ссылка на контейнер в хранилище;
6) тестируем "новый" контейнер и при необходимости удаляем "старый".

Отредактировано пользователем 7 июня 2021 г. 1:00:03(UTC)  | Причина: Не указана