locked
Code signing certificates upgrading from SHA-1 to SHA-2, and what this means to click once...... RRS feed

  • Question

  • I received the following note from my code signing certificate provider (Symantec, used to be VeriSign):

    ---------------------------------------------------
    We are writing to tell you about Secure Hash Algorithm 256 (SHA-256 or SHA-2) support on Symantec Code Signing for Individuals and Symantec Code Signing for Organizations. SHA-2 was developed by the National Institute of Standards and Technology (NIST) and is the recommended cryptographic hash function to replace SHA-1 by the end of 2014.
    SHA-2 support is available starting April 1st, 2013 for the following Symantec Code Signing products: Microsoft® Authenticode™, Java™, Adobe® Air® and Microsoft® Office Visual Basic® for Applications (VBA). You will be able to select the option for SHA-2 through the ordering pages, reissue process and via the Application Programmatic Interface (API) for QuickOrder, QuickInvite and Reissue.
    Please note that some older applications and operating systems do not support SHA-2, for example, Windows™ XP Service Pack 2 or lower does not support the use of SHA-2. Java SDK 1.4.2 or higher needs to be installed and used on the server for SHA-2 support for Java server support.
    If you are using a Windows environment, please refer to the following blog for SHA-2 deployment: http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx.

    --------------------------------------------------------------------------------------


    OK, so what does this mean for click once?

    Should I just ignore this because the NIST recommendation is just a recommendation?

    Is the security problem big enough I should talk about upgrading all my downlevel clients (Windows XP SP 2 and Windows Server 2003).   I've got 10k+ customers out there, this won't be simple.

    Does Microsoft have any further guidance about how this related to click once? 

    So click once uses two manifests, an application manifest and a deployment manifest.  I always get the names confused.  My product allows assignment of different versions to different users, so one of these manifests (the one with all the build files) is signed at the time the build was done, and the other is signed at the time the user first logs into the system.  This could mean that since builds hang around for years, the manifest tied to the build would stay SHA-1, while the corresponding manifest tied to the user will have a SHA-2 sign.  Will windows accept this kind of a chain, and allow an install?

    The question is similar to a certificate upgrade, but not quite...

    Thanks,

    Darwin


    ----------------------------------------------- "Cannot find reality.sys ... Universe Halted!"

    Monday, April 15, 2013 6:48 PM

Answers

  • Hi Darwin,

    From what I know, .NET Framework 4.5 has chosen SHA-256 algorithm to sign the manifest by default. However, SHA-1 is used by .NET Framework 4.0. We may get a CryptographicException telling that "the manifest may not be valid or the file could not be opened" when running a ClickOnce 4.5 application on a machine with only .NET Framework 4.0 installed.

    You may find some more details from this thread:

    http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/f5b934d2-e8b9-4401-b038-b84aefbdf836/

    Deployment Manifest is used to describe the ClickOnce deployment, which contains some settings how the application is launched an updated.

    Application Manifest is used to describe an application deployed by ClickOnce, which contains some information of the files and security info.

    Application Manifest and Deployment Manifest should be signed by the same certificate.

    Best regards,


    Chester Hong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Chester Hong Tuesday, May 7, 2013 2:20 AM
    Wednesday, April 17, 2013 6:22 AM