Вероятно, вы спрашиваете о том, что вам не нужно (см. проблема XY). Какую вы пытаетесь решить задачу?

Здравствуйте.

А доступ к контейнеру зачем потребовался в таком виде?

Через контекст личного сертификата не тот путь?

CertGetCertificateContextProperty ( сертификат, CERT_KEY_PROV_INFO_PROP_ID .. )
выделить память для KeyInfo
CertGetCertificateContextProperty ( сертификат, CERT_KEY_PROV_INFO_PROP_ID .. KeyInfo )

и получаем необходимое:

при запросе... сертификата?

Задача какая?
По имени выбранного СКЗИ подставить тип?
В чем сложность возникла? 80 или 81? Или другие csp еще будут?

Java API сильно отличается от CryptoAPI, поэтому повторение решений для одного API в другом - это напрасная трата сил. "Только alias и пароль" - это неудачная часть Java API, поэтому повторять именно её не стоит. И на самом деле параметров больше: вы в коде зашиваете ещё KeyStore. Так и в CryptoAPI, кроме типа провайдера, вообще говоря важно его имя (это сразу почувствуют те, кто работают, например, с КриптоПро HSM). И чтобы не перегружать сложной логикой прикладное ПО, имя контейнера, тип провайдера и имя провайдера стали атрибутом сертификата - ссылкой на закрытый ключ. Формирование корректной ссылки - это сложная задача, которая решается либо средствами выпуска сертификата, либо нашим ПО - Инструментами КриптоПро (cptools) или certmgr. А сам приклад по сертификату делает CryptAcquireCertificatePrivateKey, либо сразу создаёт или проверяет CMS-сообщения. Если делать спустя рукава, то можно использовать CryptAcquireContext(PROV_GOST_2012_256).