In fact, CSP is mainly for the operation of the key pair in the container, and the certificate has little relation. There are two types of key pairs in a container: a at_keyexchange, a cryptographic key pair, and a key pair that at_signature represents a signature. Due to export restrictions in the United States, the maximum length of a cryptographic key pair that can be taken in an MS CSP is usually shorter than the signed key pair. Normally encrypted key pairs are only used for encryption, signed key pairs are only used for signing, and for some reasons (such as generating a certificate request), encrypted key pairs can also be used for signing. I think of At_keyexchange and At_signature as two positions in a container. In a smart card CSP, the certificate can be written to the container, and the corresponding certificate of the encrypted key pair is written to the At_keyexchange location, and the corresponding certificate for the signed key pair is written to the at_signature location. This is judged based on the same public key of the certificate as the key pair, not the key usage extension in the certificate. Using the Crypto API, you can find the key pair in the relative entitlement container based on the cert_key_prov_info_prop_id of the certificate in the certificate library. The Dwkeyspec in crypt_key_prov_info refers to the type of key pair in the container. If the level of the CSP implementation is based on the certificate's key usage extension to limit the ability to encrypt and sign, read the certificate first, this operation is slow, the estimated implementation less adoption. In fact, Ming Wah Ekey's at_keyexchange and at_signature type key pairs are both encrypted and signed (CryptDecrypt and Cryptsignhash are no problem, Not how to test Cryptimportkey, do not know whether the signature key pair can successfully import the session key). I don't have the same xcsp_eclib.dll as your version, I used a slightly older version to test. I tested the Cryptdecryptmessage function and found that if it was a signed key pair no matter how the key usage extension of my certificate was set, decryption would always fail (as with MS's CSP). Using the encryption key pair can be successful. Although Outlook may not use Cryptdecryptmessage to decrypt the envelopeddata of the CMS, I believe eventually the cryptimportkey of the CSP will be called to solve the symmetric key and then decrypt it. Cryptdecryptmessage passed to Cryptimportkey is a simple-key BLOBs. My test found that ekey always seems to be decrypting with an encrypted key pair. This could be this simple-key BLOBThere is a problem with the structure of s that causes decryption to fail or the cryptimportkey of the Ekey CSP has a bug that causes decryption to fail. It seems that if you want the certificate to be both encrypted and signed, you must first ensure that you are using an encryption key pair. The generation of cryptographic key pairs can be set using Xenroll when generating a certificate request, and the way in which the pkcs#12 file is imported depends on what type of key pair should be created based on what software is being used.
Relationship between Windows key containers and certificates
