none
Problem with Authenticode Signatures on .NET services RRS feed

  • Question

  • As recommended in test 'TC3.8.1 Are all executables installed by application signed?' I have bought an Authenticode signature from VeriSign and have applied it to all our executales using Signool. I have also applied them on the executables of our Windows Services (FWIW, everything is written in .NET 2.0). I have noticed that since we have applied those authenticode signatures our services refuse to start automatically for the very first time when they are being installed on a server which doesn't have any Internet access. As soon as we change the firewall configuration so that this server does have internet access everything is working fine. I'm assuming this is because Windows is attempting to contact VeriSign to verify the signature, but is unable to do so and eventually times out after 30 seconds. (also see the remark made by a Daniel on http://blogs.msdn.com/shawnfa/archive/2005/12/13/502779.aspx). I was wondering if anybody else has had this problem and what a possible solution might be?

     

    As some additional information I have added the output of 'sgntool verify /pa' when run against one of our services below:

    Verifying: Server.exe
    Signing Certificate Chain:
        Issued to: Class 3 Public Primary Certification Authority
        Issued by: Class 3 Public Primary Certification Authority
        Expires:   2/08/2028 0:59:59
        SHA1 hash: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx              

            Issued to: VeriSign Class 3 Code Signing 2004 CA
            Issued by: Class 3 Public Primary Certification Authority
            Expires:   16/07/2014 0:59:59
            SHA1 hash: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

                Issued to: Adam Software
                Issued by: VeriSign Class 3 Code Signing 2004 CA
                Expires:   9/11/2008 0:59:59
                SHA1 hash: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

    The signature is timestamped: 26/12/2007 22:20:48
    Timestamp Verified by:
        Issued to: Thawte Timestamping CA
        Issued by: Thawte Timestamping CA
        Expires:   1/01/2021 0:59:59
        SHA1 hash: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

            Issued to: VeriSign Time Stamping Services CA
            Issued by: Thawte Timestamping CA
            Expires:   4/12/2013 0:59:59
            SHA1 hash: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

                Issued to: VeriSign Time Stamping Services Signer - G2
                Issued by: VeriSign Time Stamping Services CA
                Expires:   15/06/2012 0:59:59
                SHA1 hash: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

    Successfully verified: Server.exe

    Number of files successfully Verified: 1
    Number of warnings: 0
    Number of errors: 0

    Thursday, December 27, 2007 4:07 PM

Answers

  • Hi Michael,

     

    Yes, this is an expected behaviour. However have you seen the post Bypassing the Authenticode Signature Check on Startup in the same blog. Using Orcas beta 1 (now by VS 2008), you'll be able to take advantage of a feature in the runtime that disables this signature verification. Your application can now opt out of Authenticode signature verification; which will mean that time to load each assembly will improve (therefore leading to an improvement in startup time if your entry point assembly has an Authenticode signature).  The tradeoff of course is that assemblies will no longer receive Publisher evidence or PublisherIdentityPermission. 

     

    Applications which wish to take advantage of this can add the following line to their .exe.config file:

    <configuration>
        <runtime>
            <generatePublisherEvidence enabled="false"/>
        </runtime>
    </configuration>

    Which will prevent the CLR from verifying the Authenticode signatures of any assembly loaded by the application. 

     

    Hope this helps.

     

    Happy New Year!!!

     

     

    Monday, December 31, 2007 10:39 AM

All replies

  • Hi Michael,

     

    Yes, this is an expected behaviour. However have you seen the post Bypassing the Authenticode Signature Check on Startup in the same blog. Using Orcas beta 1 (now by VS 2008), you'll be able to take advantage of a feature in the runtime that disables this signature verification. Your application can now opt out of Authenticode signature verification; which will mean that time to load each assembly will improve (therefore leading to an improvement in startup time if your entry point assembly has an Authenticode signature).  The tradeoff of course is that assemblies will no longer receive Publisher evidence or PublisherIdentityPermission. 

     

    Applications which wish to take advantage of this can add the following line to their .exe.config file:

    <configuration>
        <runtime>
            <generatePublisherEvidence enabled="false"/>
        </runtime>
    </configuration>

    Which will prevent the CLR from verifying the Authenticode signatures of any assembly loaded by the application. 

     

    Hope this helps.

     

    Happy New Year!!!

     

     

    Monday, December 31, 2007 10:39 AM
  •  

    Thank you very much for your feedback. Happy new year to you too.

     

    I had not seen this post about bypassing the verification. After googling a little put, I noticed on http://support.microsoft.com/kb/936707 that I would have to apply a patch to get this working on .NET 2.0 (which we're currently using). It's unfortunate, but there's probably no other solution I suppose.

     

    Thanks anyway,

    Michael

    Friday, January 4, 2008 2:39 PM