其实CSP主要是对容器里的密钥对操作的，和证书关系不大。容器里的密钥对有两种类型：一种是AT_KEYEXCHANGE，表示加密的密钥对，一种是AT_SIGNATURE表示签名的密钥对。由于美国的出口限制，在MS的CSP中加密的密钥对可以取的密钥最大长度通常会比签名的密钥对短。通常加密的密钥对只会用于加密，签名的密钥对只会用于签名，由于某些原因（例如产生证书请求），加密的密钥对也可以用于签名。我把AT_KEYEXCHANGE和AT_SIGNATURE看作是容器里的两个位置。在智能卡CSP中可以把证书写入容器中，和加密的密钥对对应的证书写到AT_KEYEXCHANGE位置中，和签名的密钥对对应的证书写到AT_SIGNATURE位置中。这里判断依据是证书的公钥和密钥对的公钥相同，而不是证书中的密钥用法扩展。使用Crypto API可以根据证书库里的证书的CERT_KEY_PROV_INFO_PROP_ID找到相对应得容器里的密钥对。CRYPT_KEY_PROV_INFO中的dwKeySpec就是指容器里的密钥对类型。如果在CSP实现的层次根据证书的密钥用法扩展来限制是否能够加密和签名，要先读出证书，这个操作比较慢，估计实现者比较少采用。
事实上，明华EKey的CSP的AT_KEYEXCHANGE和AT_SIGNATURE类型的密钥对都是既可以加密也可以签名的(CryptDecrypt和CryptSignHash是没问题的，没怎么测过CryptImportKey，不知道是不是签名的密钥对能不能成功导入会话密钥)。我没有和你的版本一样的xcsp_eclib.dll，我使用了一个稍微旧一点的版本的来测试。我测试了CryptDecryptMessage函数，发现如果是签名密钥对不管我证书的密钥用法扩展如何设置则解密总是会失败（用MS的CSP也一样）。而使用加密密钥对则可以成功。虽然OUTLOOK可能不是使用CryptDecryptMessage来解密CMS的EnvelopedData的，但是我相信最终都会调用CSP的CryptImportKey解出对称密钥，再解密的。CryptDecryptMessage传给CryptImportKey的是一个Simple-Key BLOBs。我的测试发现EKey好像总是使用加密的密钥对来解密。这可能是这个Simple-Key BLOBs的结构有问题导致解密失败或者EKey的CSP的CryptImportKey有BUG导致解密失败。
看来，如果要使得证书既能加密也能签名，必须首先保证使用的是加密密钥对。产生加密密钥对可以在产生证书请求的时候使用Xenroll来设置，至于使用PKCS#12文件导入的方式要取决于使用的软件是根据什么来判断应该创建什么类型的密钥对。