none
CertEnroll problem in Windows 7 when using legacy smart card csp and SHA256 hash algorithm RRS feed

  • Question

  • Hello.

    I'm trying the code posted here
    http://blogs.msdn.com/b/alejacma/archive/2008/09/05/how-to-create-a-certificate-request-with-certenroll-and-net-c.aspx
    with a custom smart card CSP (legacy), and I've added code to define the hash algorithm for the certificate request.
    The problem is, when I use SHA1 as the hash algorithm, everything works fine, but when I use SHA256, the application returns an "Internal Error" exception.

    Looking around the forums, I found out that certain MS crypto API's require CNG to work, and since the exception I'm getting seems to be from a layer above the CSP, I'm assuming CertEnroll is trying to call a CNG API which eventually fails.

    Is my assumption correct? If it is, what CNG provider should I develop? Should it be an algorithm provider or a KSP (like the one paired with microsoft's smart card base csp)?
    And if I develop my own KSP, how can I somehow "link" it with my legacy CSP, so that when CertEnroll tries to call CNG API, it knows that it should call it from my KSP?

    Monday, November 12, 2012 2:39 AM

All replies

  • I would contact the provider of the smart card CSP and ensure that it supports SHA256 hashing as a first step, particularly if the CSP is old.  Also tell them which OS you are using.  Also, are you concerned about using SHA1 in your certificate request to protect the signature of the cert request?  Or do the ultimate certificates need SHA256?
    Monday, November 12, 2012 5:08 AM
  • Actually, I'm currently the one maintaining the CSP. Our smart card is capable of SHA256 hashing and our CSP just calls that function, so I'm pretty sure that our CSP supports SHA256.

    The protection from the algorithm isn't really the issue here, but the support for newer algorithms.

    Monday, November 12, 2012 6:17 AM
  • So I can see two ways that your internal error occurs.

    1) The .NET code calls layers of software which simply don't support SHA256, and so your CSP never gets a chance to try to perform a SHA256 operation.  I don't know when (or if) .net uses CNG or CryptoAPI.   But my guess is that this is the problem.

    2) Your CSP code does get called, but your CSP code delegates the SHA 256 to something else which can't handle SHA256.  Although the card may be capable of SHA 256 hashing, your CSP probably does not use the card for such hashing, as the computer CPU is much faster, and you don't need to send your data to the smartcard.  You can confirm that by looking at your implementation of CPCreateHash and CPHashData.

    On which version of Windows XP or Windows 7 did this error occur?

    http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx discussed the complexity of historical SHA256 support.

    For example, http://technet.microsoft.com/en-us/library/ff182351(v=WS.10).aspx shows the use of SHA256, but is dependent on Windows 2008. 

    Good luck...


    • Edited by Andrew7Webb Monday, November 12, 2012 3:43 PM right url
    Monday, November 12, 2012 3:41 PM
  • CertEnroll works with CAPI keys or CNG keys. If you set the ProviderName property on an IX509PrivateKey to a CSP and set ProviderType and KeySpec properties appropriately then CertEnroll will use the CSP.

    CertEnroll uses many CAPI2 APIs; I *think* the CAPI2 APIs may need a KSP in order to support SHA256.

    If you collect CertEnroll logging then I can determine what the failing call is. Instructions:

    certutil -setreg enroll\debug 0xffffffe3
    <repro the failure>
    certutil -delreg enroll\debug

    There should be a file located at c:\windows\certenroll.log OR certenroll.log is somewhere under %userprofile% [sorry; I can't remember the exact path].

    Post the contents of the file and I can have a look.

    To answer your other question: CertEnroll only talks to a CSP or KSP. Not a bcrypt algorithm provider. There is no need to "link" your CSP and KSP. Certenroll will call the provider that is identified by the ProviderName property on the IX509PrivateKey object whether it is a CSP or a KSP. If necessary, your KSP could call your CSP underneath.

    Andrew

    Monday, November 26, 2012 2:59 AM
  • Hi,

    I confirm Andrew sup dealing with SHA-2 algorithms (like SHA256), CertEnroll looks internally for a KSP associated with the legacy CSP and if it fails to find one, it returns an internal error.

    However, I don't fully agree with Andrew on his last statement : You don't have to implement a full KSP to make CertEnroll work with a legacy CSP and there is a way to "link" your legacy CSP and a lightweight KSP  in order to make CertEnroll fully useable with your legacy CSP and this without any change to the enrollment pages and procedure.

    I have developed such a technical solution that works out of the box for any legacy CSP. You can contact me in private if you need more information on that.

    Cheers,
    --
    Mounir IDRASSI
    IDRIX
    http://www.idrix.fr


    Mounir IDRASSI - IDRIX - http://www.idrix.fr

    Thursday, January 10, 2013 3:17 AM