У тебя сертификат уже имеет привязку к контейнеру (ссылка на закрытый ключ - на странице Общие при просмотре сертификата).
У пользователей - устанавливается через программу настройки КриптоПРО CSP (Сервис\Установить личный сертификат).

p.s. но сделать привязку можно и у себя в приложении, если такое необходимо...

Дабы немного привести в порядок знания участвующих в данном обсуждении уточню некоторые детали:
1) Основные функции CryptoAPI (функции непосредственно экспортируемые из криптопровайдеров) в качестве результата возвращают обычные бинарные данные, никак не кодированные;
2) Кроме базовых функций в CryptoAPI существуют и функции вторичного кодирования бинарных данных, полученных из криптопровайдеров. Кодируют эти функции в формат ASN.1;
3) DER - Distinguished Encoding Rules, определенный набор правил кодирования внутренних структур ASN.1. Для первичного понимания не нужен;
4) Формат ASN.1 в свою очередь представляет собой заранее известную последовательность закодированных данных. Описание структуры ASN.1 в которую кодируются первичные бинарные данные заранее согласован и, например, для сертификатов первично был обозначен в стандарте ITU-T X.509. Сейчас же принято опираться на другой стандарт - RFC5280 (или более раннюю версию этого же стандарта RFC3280);
5) Стандарт PKCS#7 абсолютно не имеет никакого отношения к кодированию сертификата. Он явился первичным стандартом к тому, что в современном мире называется CMS - Cryptographic Message Syntax;

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

1) Функция CertSetCertificateContextProperty(CERT_KEY_PROV_INFO_PROP_ID)
привязывает сертификат к контейнеру с ключами.
При этом оказывается, что она не проверяет ни существование самого контейнера
ни наличие в контейнере ключей ни соответствие ключей из контейнера сертификату.

1.1) Это я ей не указал какие то параметры или она действительно не умеет это
делать ?
1.2) В привязки сертификата к контейнеру с ключами мне не понравился один
момент: получается, что после привязки, любой человек сможет на этом компе
подписать этим сертификатом (ключом) данные. Можно конечно динамически до
привязки создавать контейнер с ключами, а после подписания удалять контейнер
но это ИМНО не лучший вариант.
Вопрос: Можно ли создавать контейнер с ключами по пути указанным мною
(скажем этот контейнер будет на флешке) ?

2) Для подписи данных (файла) с сохранением подписи+сертификат в отдельном
файле (.p7s) использовал функцию CryptSignMessage. Кроме того добавил в
подпись через CRYPT_SIGN_MESSAGE_PARA (cAuthAttr, rgAuthAttr) время создания
подписи (szOID_RSA_signingTime).

2.1) Правильно ли я понимаю, что если в CRYPT_SIGN_MESSAGE_PARA (rgpMsgCert, cMsgCert)
указать не один сертификат (скажем сертификат автора подписи), а несколько
(скажем еще и сертификат издателя), то в файл .p7s будут сохранены все эти
сертификаты ?

2.2) Обнаружил, что CryptSignMessage не проверяет соответствие ключей в
контейнере привязанному к этому контейнеру сертификату
CRYPT_SIGN_MESSAGE_PARA.pSigningCert.
Так же CryptSignMessage не проверяет срок действия сертификата, подозреваю что
она вообще не делает ни каких проверок сертификата - можно ли этим сертификатом
подписывать данные.
Вопрос: Может я ей что то не указал, из за чего она не делает эти проверки ?
Или мне надо самому перед ее вызовом делать необходимые проверки ?

2.2.1)
Если самому, то какие функции CryptoAPI надо использовать для построение
цепочки сертификатов от сертификата пользователя до сертификата
самого верхнего уровня находящегося на текущем компе и выполнения проверок
для этих сертификатов
- подпись издателя на сертификате
- срок действия сертификата
- неотозваность сертификата
Или может для всех этих проверок есть некая одна высокоуровневая функция ?

Кстати, а в подписи издателя под сертификатом пользователя присутствует дата
подписи ? Если да, то надо ли ее проверять ?

3) Для проверки подписи использовал CryptVerifyDetachedMessageSignature.
Параметр PCRYPT_VERIFY_MESSAGE_PARA.pfnGetSignerCertificate не указывал, так
что функция брала сертификат из файла подписи (.p7s).

Похоже, что функция не делает ни каких проверок кроме простой проверки
хешей на манер CryptVerifySignature, разве что ключ она извлекает из
сертификата.
Вопрос: Может я ей что то не указал, из за чего она не делает эти проверки
(п. 2.2.1)?
Или мне надо самому перед (или после) ее вызова делать необходимые проверки ?

3.1) Получилось извлечь из .p7s кол-во подписей и дату самой подписи.
Для этого использовал CryptMsgOpenToDecode, CryptMsgUpdate(,True),
CryptMsgGetParam(,CMSG_SIGNER_COUNT_PARAM,),
CryptMsgGetParam(,CMSG_SIGNER_AUTH_ATTR_PARAM,).
Вопрос: Может есть более высокоуровневая функция для вытягивания из подписи
разных полей ?

То. что для экспорта/импорта из/в контейнер ключевой пары используется пароль я знаю.
А вот как просто для доступа к контейнеру задать пароль я не знаю. Как это можно сделать ?


Вопрос: Как можно создать контейнер на флешке ?


4) Присутствует ли дата подписи в подписи издателя под сертификатом пользователя ? Если да, то надо ли ее проверять, в смысле надо ли проверять что сертификат пользователя был подписан в период действия сертификата издателя ? Или такие проверки не делаются, а весь вопрос заключается в том, доверяем ли мы издателю (СЦ) или нет ?

5) Как проверить, что файл подписан во время действия сертификата я знаю - берем из подписи ранее сохраненную туда дату подписи и сравниваем ее с периодом действия сертификата.
Вопрос: А вот как проверить, что на момент подписания файла сертификат не был отозван ? Может у отозванных сертификатов есть что то типа "даты отзыва" ?

Рекомендую, все же скачать SDK - там есть примеры по работе с CryptoAPI

\sdk\samples\CSP\CreatingKeyContainer\CreatingKeyContainer.c