Share via


ClickOnce Deployment and Authenticode

Authenticode is a Microsoft technology that uses industry-standard cryptography to sign application code with digital certificates that verify the authenticity of the application's publisher. By using Authenticode for application deployment, ClickOnce helps prevent the phenomenon of a "Trojan Horse," where a malicious third party misrepresents a virus or other harmful program as a legitimate program coming from an established, trustworthy source. All ClickOnce deployments must be signed with a digital certificate.

The following sections describe the different types of digital certificates used in Authenticode, how certificates are validated using Certificate Authorities (CAs), the role of time-stamping in certificates, and the methods of storage available for certificates.

Authenticode and Code Signing

A digital certificate is a file that contains a cryptographic public/private key pair, along with metadata describing the publisher to whom the certificate was issued and the agency that issued the certificate.

There are various types of Authenticode certificates, each once configured for different types of signing. For ClickOnce applications, you must have an Authenticode certificate that is valid for code signing; if you attempt to sign a ClickOnce application with another type of certificate, such as a digital e-mail certificate, it will not work. For more information, see Introduction to Code Signing (https://msdn.microsoft.com/library/default.asp?url=/workshop/security/authcode/intro\_authenticode.asp).

You can obtain a certificate for code signing in one of three ways:

  • Purchase one from a certificate vendor.

  • Receive one from a group in your organization responsible for creating digital certificates.

  • Generate your own certificate with MakeCert.exe, which is included with the .NET Framework Software Development Kit (SDK).

How Using Certificate Authorities Helps Users

  • A certificate generated using the MakeCert.exe utility is commonly called a "self-cert" or a "test cert". This kind of certificate works much the same way that a .snk file works in the .NET Framework: it consists solely of a public/private cryptographic key pair, and contains no verifiable information about the publisher. You can use self-certs to deploy ClickOnce applications with high trust on an intranet; however, when these applications run on a client computer, ClickOnce will identify them as coming from an "Unknown Publisher." By default, ClickOnce applications signed with self-certs and deployed over the Internet cannot utilize Trusted Application Deployment.

  • By contrast, if you receive a certificate from a CA—such as a certificate vendor, or a department within your enterprise—the certificate offers more security for your users. It not only identifies the publisher of the signed software, but it verifies that identity by checking with the CA that signed it. If the CA is not the root authority, Authenticode will also "chain" back to the root authority to verify that the CA is authorized to issue certificates. For greater security, you should use a certificate issued by a CA whenever possible.

For more information about generating self-certs, see Certificate Creation Tool (Makecert.exe).

How Time-Stamping Can Prevent Unintended Expiration

Even though certificates provide more security, an unauthorized party can obtain a certificate and its accompanying password from its legitimate owner. By default, a certificate issued by a CA is only valid for 12 months. This forces the owner of the certificate to re-verify their identity through the CA, which ensures that compromised certificates can only be used for a short period of time.

Typically, certificate expiration would mean that you need to re-sign your ClickOnce application every 12 months. Authenticode mitigates the need for this with support for time-stamping. When you sign a ClickOnce deployment using a certificate, ClickOnce records the date and time of the signing and embeds it in the deployment's digital signature. So long as the deployment was signed when the certificate was still valid, ClickOnce will allow the application to run even if the certificate has since expired.

Both Visual Studio and the Windows Software Development Kit (SDK) tools for creating ClickOnce deployments, Mage.exe and MageUI.Exe, support time-stamping. To use this time-stamping feature, you must be using the automatic update feature in ClickOnce.

A minimum required version of the .NET Framework must be installed on both the development and end user computers to use time-stamping. The following table lists the versions of the .NET Framework contain the correct version of the CLR runtime for supporting Authenticode time-stamping.

Operating system version

.NET Framework version

Windows XP

.NET Framework 2.0 SP1

Windows Vista

.NET Framework 3.5

Storing Certificates

  • You can store certificates as a .pfx file on your file system, or you can store them inside of a key container. A user on a Windows domain can have a number of key containers. By default, MakeCert.exe will store certificates in your personal key container, unless you specify it should save it to a .pfx instead. Mage.exe and MageUI.exe, the Windows SDK tools for creating ClickOnce deployments, will enable you to use certificates stored in either fashion.

See Also

Concepts

ClickOnce Deployment Overview

ClickOnce Deployment and Security

Trusted Application Deployment Overview

Reference

Manifest Generation and Editing Tool (Mage.exe)