releasedigital-signaturecode-signingdigital-certificate

Should I digitally sign third-party DLLs such as JSON.NET?


I have an application built using a variety of third-party libraries such as JSON.NET.

I would like to ensure that all the DLLs that make up my application are digitally-signed, including the third-party ones. Given that these are not signed by the author, can/should I simply sign the third-party ones myself?


Solution

  • Are you talking about strong-naming or about authenticode signatures? The problem with the latter ones is when the authenticode-signed assembly is loaded, .NET validates the certificate and in some configurations (eg. when OCSP needs to be checked and it's not reachable) this can take dozens of seconds. We had to stop signing our assemblies with authenticode and X.509 certificates due to this.

    Another drawback is that if the signed assembly is used by malware in some way, some not competent wanna-be-specialists in antivirus companies can (a) mark the assembly as a malware and (b) what is worse, complain to Certificate Authority which issued your code signing certificate, and the certificate will be revoked.

    .NET strong-naming (with a keypair without certificate) is more or less your private business.

    Update: Authenticode is usually applied to PE format files (EXE and DLL), SYS and CAB. strong-naming is pure .NET technique.

    The warning message talks about Authenticode signature. Signing the installer is necessary (that's for sure) and is enough to get rid of the message unless system policies are set to allow only running of signed applications (in which case your application's EXE must be signed as well).