Announcement: Configuration Manager Documentation Library Update for August 2009

Announcement: Configuration Manager Documentation Library Update for August 2009

  • Comments 5
  • Likes

[Today's post comes from the Configuration Manager Writing Team]

The Configuration Manager documentation library (http://technet.microsoft.com/en-us/library/bb680651.aspx) has been updated on the Web and the latest content has Updated: August 1, 2009 at the top of the topic.

We have only a handful of topics that have been updated this month to correct a couple of broken links and a minor editing clarification.  The main change that I want to draw your attention to is the addition of a single but very important sentence in Certificate Requirements for Native Mode, which is the following for each of the native mode certificates: SHA-1 is the only supported hash algorithm  

When you install the Active Directory Certificate Services role on Windows Server 2008, the Configure Cryptography for CA page of the Add Roles Wizard allows you to change the default hash algorithm of sha1 for other algorithms, such as those from the SHA2 family, including the stronger algorithms of SHA-256 and SHA-512. Only SHA-1 has been tested for native mode communication in Configuration Manager 2007, and there are no plans to extend this support in the near future.  Therefore, all native mode certificates must be issued by a CA that uses SHA-1.

Disclaimer:  The procedures in this blog post are external to Configuration Manager, so you will not find this information in the Configuration Manager product documentation.  However, we realize that PKI is often new to Configuration Manager admins, and aim to share our knowledge and experience to help you be more successful with the product.

How can you tell whether your certificates are using SHA-1 or another algorithm?  Check the properties of the issued certificate, by using the Certificates MMC.  In the Details tab, check the value of the Signature algorithm - it should say sha1RSA.  And on the issuing CA, check the properties of the CA, General Tab - it should display Hash algorithm: sha1 under the Cryptographic settings section.

From customer feedback on the forums (and verified with our own testing), we know that when the site server signing certificate is signed with an algorithm that is higher than SHA-1, the MPControl.log file on the management point displays CryptVerifyCertificateSignatureEx returned error 0xc000a000 instead of the expected CryptVerifyCertificateSignatureEx returned error 0x80090006.

If you have installed Active Directory Certificate Services with a hash algorithm other than SHA-1, you can reconfigure it to use SHA-1 by using the following procedure:

  1. From a command prompt on the server running the CA, type the following: Certutil -setreg ca\csp\CngHashAlgorithm SHA1
  2. Stop and restart Certificate Services.
  3. If necessary, request and issue new certificates.

-- The Configuration Manager Writing Team

This posting is provided "AS IS" with no warranties and confers no rights.

 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • When will the next offline help rollup update be released?

    Also why is it ever since this blogs site turned on this capta thing I cant post when Im signed in?

  • We hope to have a Configuration Manager Help file update for offline use shortly after the release of SP2.

  • Are there plans to address this / add support for SHA-256 in SCCM before the U.S. Government deadline to stop issuing certificates signed with SHA-1?

  • To answer the question "Are there plans to address this / add support for SHA-256 in SCCM before the U.S. Government deadline to stop issuing certificates signed with SHA-1?":

    There are currently no plans to support hash algorithms greater than SHA-1 for Configuration Manager 2007.

  • Changing the hash alogorithm by using the certutil command above only changes it for newly issued certificates. The issuing CA's public key would remained signed by it's superior using the previous hash algorithm, unless you reinstall the CA hierarchy. Is that Ok, or does the CA need to be re-installed? can the root CA be using a stronger hash algorithm than the issuing CA, from an SCCM point of view?

    BTW: saying "there are no plans to fix this" is not an answer. Customers are going to have to compromise their PKI designs because of these limitations. I can see you fixing this in the next version of SCCM and then being proud of yourselves because you fixed it. That does not help, as all the folks who are hit by this situation will not be able to change their PKI. You guys need to take this into consideration before arriving at "there are no current plans to fix this"