I am going to repro this in my lab and see if I can track down what is going on.The CSPs are responsible for creating, storing and accessing cryptographic keys the underpinnings of any certificate and PKI.
Understanding Cryptography Solutions Pro This InThese keys can be symmetric or asymmetric, RSA, Elliptical Key or a host of others such as DES, 3DES, and so forth. There are also 3rd party providers for devices such as smart cards and hardware security modules. For the purposes of this article, I will be addressing the standard Microsoft CSPs and the newer Crypto-Next Generation KSPs, their capabilities and the primary purposes you may use them. To that end, in the comparison tables below, I have broken the providers into three tables. Modern Crypto-Next Generation (CNG) providers that are recommended, followed by legacy CAPI (RSA only) providers and the last table is deprecated providers seldom used anymore. In reviewing this list, the primary things we are evaluating are what types of keys can be used, their size, protections, and compatibility. Supports Key Attestation to allow CA to ensure key is created in TPMVirtual smart card. The algorithm identifier CALGSSL3SHAMD5 is used for SSL 3.0 and TLS 1.0 client authentication. This CSP supports key derivation for the SSL2, PCT1, SSL3 and TLS1 protocols. Derived from Base DSS and Diffie-Hellman Cryptographic Provider. This CSP supports key derivation for the SSL3 and TLS1 protocols. Default RSA CSP. Derivative of Microsoft Enchanced Cryptographic Provider. Supports all the same key lengths, but lacks configurable Salt length for RC encryption algorithms. The Enhanced Provider supports stronger security through longer keys and additional algorithms. Can only generate 128bit RC24 keys, can import smaller. But you can secure the NDES signing keys with a legacy CSP with and HSM. Understanding Cryptography Solutions Free To UseClients are free to use whatever provider you choose unless you are performing key attestation. Also the NDES installer is hard coded to using specific v1 templates configured with these legacy providers. So if you want to use a HSM or alternate provider you have to change the certificates manually after install. When installing NDES, I selected the default Microsoft Strong Cryptographic Provider for both the RA signing and encryption certificate key providers. The NDES server successfully enrolled an RA certificate using the default Exchange Enrollment Agent v1 certificate template. However, the Exchange Enrollment Agent template does NOT have Microsoft Strong Cryptographic Provider checked under the Request Handling tab, CSPs section. There are other providers such as Microsoft Enhanced Cryptographic Provider v1.0 and a few others checked in the CSPs section).
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |