- ClickOnce Security Overview
- Internet Explorer Security Settings Affecting ClickOnce
- Configuring ClickOnce Security Permissions
- Understanding and Managing Publisher Certificates
- Signing Application Updates
- User Prompting
- Trusted Applications' User Security Policies
- Trusted Publishers' Permission Elevation
- Adding Restricted Code Sections
- Securing the Application Based on User Roles
- Securing Access to ClickOnce Application Files on the Server
- Where Are We?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding and Managing Publisher Certificates
The publisher certificates used to sign ClickOnce manifests are Authenticode Class 3 Code Signing certificates. This is just one form of an Authenticode certificate.2 There are many different kinds for various forms of authentication and authorization security scenarios.
Publisher certificates are generated with a public-private key pair and additional metadata about the publisher. The organization that creates a certificate is called the certificate authority or certificate issuer. The organization the certificate represents is the publisher. The Windows operating system has a built-in infrastructure for storing and authenticating certificates. There are a number of built-in certificate stores in the operating system, and you can create additional custom stores as needed.
Certificates are based on the concept of a trust chain. If you are presented with a certificate, you can determine from the certificate who the publisher organization is that the certificate represents, as well as who issued that publisher the certificate. From the issuer's certificate, you can determine the issuer's identity, as well as who issued the issuer their certificate. You can follow this chain of issuers back to what is called a Trusted Root Certification Authority. This chain of issuers provides a path of discovery that ensures that if you can verify the identity of all of the issuers in the chain, you have a way to track down and contact the publisher.
This way, if you deploy an application to your machine that is signed with a publisher certificate, and that application does harmful things to your machine, you can track down the publisher through the information in the certificate, or through the information that is retained by the issuer when issuing the certificate. Some certificate issuers include liability insurance as part of their certificate issuance services; this guarantees that if you cannot contact a publisher that was issued a certificate by that authority (to pursue a liability claim), the certificate issuer will assume the liability up to some limited degree.
To support this concept, a number of companies are in the business of verifying the identity of other organizations for the purposes of issuing certificates to them. VeriSign and thawte are two well-known companies who perform these services. The issued certificate (whether a code signing or publisher certificate, or one of the many other forms of certificates) becomes a digital representation of the organization's identity. Certificates from well-known and trusted certificate authorities are installed with the operating system or can be added later, which identifies them as a trusted issuer of other certificates. As a result, if you obtain a publisher certificate from an application vendor, and that certificate has been issued by an organization like VeriSign, you can be relatively certain that the company is who they say they are (they are a legal business entity), and that the organizational information contained in the certificate has been verified by the issuer (which includes the location of the organization or where its business license information can be verified).
The verification chain may be deeper than one level, however. A Trusted Root Certification Authority can issue certificates to themselves or other certification authorities to issue specific kinds of certificates. For example, see Figure 6.8 for the trust chain for a code-signing certificate for my company, Software Insight. You will see that the root VeriSign Class 3 Public Primary CA (certificate authority) certificate was used to issue a VeriSign Class 3 Code Signing CA certificate, which was then used to issue my Software Insight Class 3 Code Signing publisher certificate. To issue that certificate, VeriSign had to verify my existence as a legal business entity. They can do this through articles of incorporation or by verifying that a legal business license has been issued by your state or city, for example.
)
Figure 6.8 Certification Path
You do not have to purchase a certificate from a third-party certificate issuer to use ClickOnce. In an enterprise environment, your domain administrators can generate a certificate for themselves and configure that certificate as a Trusted Root Certification Authority (CA) on all the machines in the enterprise, allowing them to issue publisher certificates to your development organization with a single-level trust chain back to a known CA. Or if you are not concerned with providing any kind of assurances of identity with your ClickOnce publication, you can generate your own publisher certificate with either Visual Studio 2005 or with command line tools.
To make matters even more complicated, there are a number of different file formats that are used for delivering certificates. Third-party certificate issuers usually issue a certificate in the form of a .cer or .spc file. These certificate files usually only contain the public key portion of the certificate, so you can freely distribute them to client machines and install them in those machine's certificate stores. When you purchase a certificate, you also usually receive a separate .pvk file that contains the private key corresponding to that public key. You will need both the public and private key portions of a certificate, in a single .pfx file format, to use it for ClickOnce publishing. You can combine .cer or .spc file portions with the .pvk portion by using the pvkimprt.exe tool that is available from Microsoft downloads.3
There are several certificate stores on your Windows machines that you will use with ClickOnce deployment. Any certificate you use for ClickOnce publishing will be added to the Personal certificate store for the logged-in user when you publish the application. Additionally, if you want to avoid user prompting on the client machine, you will want to install your publisher certificate into the Trusted Publishers store on the client machine as discussed in the section Trusted Publishers' Permission Elevation later in this chapter. If you are installing a publisher certificate into the Trusted Publishers store, you will want to make sure the certificate's issuer is in the Trusted Root Certification Authorities store or the Intermediate Certification Authorities store, and that the root issuer of the trust chain is in the Trusted Root Certification Authorities store (see Figure 6.8).
Generating or Configuring a Publisher Certificate with Visual Studio 2005
If you publish a Windows Application project with Visual Studio without configuring a publisher certificate ahead of time, Visual Studio will generate a self-signed publisher certificate for you. In this kind of certificate, the identity of the issuer and the publisher are set to the logged-in Windows identity of the user.
The public and private key portions of the certificate are placed in a file with a .pfx file extension and the file is added to your project. The certificate is then configured as the signing certificate for ClickOnce publication, and is also added to your Personal certificate store on the development machine. When your application is published, the deployment and application manifest files are signed with this certificate. The .pfx file that is generated is a password-protected file, but when Visual Studio automatically generates the file for you the first time you publish, the password of the generated file is set to an empty password.
You can generate your own certificates through Visual Studio (with the option to password-protect the file), or you can select an existing certificate to use for signing as well. You do this through the Signing tab of your project properties editor (see Figure 6.9).
)
Figure 6.9 ClickOnce Signing Settings
After checking the box that is labeled Sign the ClickOnce manifests, you can either select a certificate from the logged-in user's Personal certificate store on the development machine, from a .pfx file, or generate a new certificate. If you click the Select from Store button, you will see the dialog shown in Figure 6.10 to select a certificate.
)
Figure 6.10 Select a Certificate Dialog
You can see that there are several small challenges to using the Select from Store option. The first is that if you test publishing an application with ClickOnce without first configuring the Signing tab to use an existing certificate, a new certificate is generated each time. Each of those certificates have a different public-private key pair and are distinct certificates, but they all have the same common name, known as CN for short, which will be your logged-in Windows account name (e.g., DOME-M200\Brian Noyes on my current machine). As a result, it is almost impossible to tell which one is which. The other challenge is that this dialog will not let you resize it, and you can see that there are a lot of columns, each with long content, so the usability of the dialog is extremely low.
An alternative to selecting a certificate from the Personal certificate store is to just point to an existing .pfx file for a publisher certificate. This will extract the information in the certificate and use it for signing, as well as install it in the Personal certificate store if it is not already there. You can see an example of this in Figure 6.10 as well—the entry that starts with XPS600 is from a certificate generated on a different machine of mine (named XPS600), and was automatically imported into my Personal certificate store on the current machine when I selected that .pfx file for my certificate. Clicking the Select from File button on the Signing tab gives you a standard file dialog to navigate to the location of your certificate file.
If you click the Create Test Certificate button on the Signing tab, you will be prompted for a password as shown in Figure 6.11. The dialog does not enforce strong passwords; you can leave it blank if desired.
)
Figure 6.11 Create Test Certificate Dialog
After you click OK in the Create Test Certificate dialog, the process is similar to what Visual Studio does if you do not configure a certificate and publish the application.
- A test certificate is generated with the issuer and publisher (labeled Issued By: and Issued To:, respectively, in most places in the UI) set to your logged-in Windows identity.
- The certificate is placed in a .pfx file with the name <appname>_TemporaryKey.pfx with the password you provided set on the file.
- The .pfx file is added to the Visual Studio project files.
- The certificate is imported into your Personal certificate store.
Once you have configured a certificate through the Signing tab, that certificate will be used for any subsequent publications of your application to sign the ClickOnce manifests.
Installing a Certificate in a Store with Visual Studio 2005
Visual Studio lets you install a certificate into any certificate stores on your machine if desired. As described earlier, any certificate that you configure to sign your ClickOnce manifests by generating the file or selecting a file will be installed into your Personal certificate store on your development machine. Additionally, if the certificate is password protected, then you can use Visual Studio to manually install that certificate into other stores on your machine.
Do the following if you want to install a signing certificate into a different store on your machine.
- Click on the More Details button on the Signing tab (see Figure 6.9). This will display the certificate information dialog shown in Figure 6.12.
Figure 6.12 Certificate Information Dialog
- At the bottom of the dialog, click the Install Certificate button.
- This will bring up the Certificate Import wizard shown in Figure 6.13. (This same wizard can be accessed by running certmgr.exe and clicking the Import button in that tool). Click Next to start the process.
Figure 6.13 Certificate Import Wizard
- The second step in the wizard (see Figure 6.14) lets you select which store the certificate will be placed into. Select the radio button labeled Place all certificates in the following store and click the Browse button.
Figure 6.14 Certificate Import Wizard – Store Selection
- The Select Certificate Store dialog shown in Figure 6.15 will display, and you can pick from the available stores on the machine. Select the store you want to place the certificate into, such as the Trusted Publishers store, and click the OK button.
Figure 6.15 Select Certificate Store Dialog
- You will return to the wizard and the selected store will be displayed in the Certificate store field in the middle of the form (see Figure 6.16). Click the Next button to continue.
Figure 6.16 Completed Store Selection Step
- The final step of the wizard (see Figure 6.17) will display, summarizing the import that is about to happen. Click the Finish button to complete the installation of the certificate into the selected store.
Figure 6.17 Certificate Import Wizard Completion
)
)
)
)
)
)
Command Line Certificate Tools
There are several command line tools that come with the .NET Framework SDK or that you can download to assist you in generating, configuring, and managing publisher certificates. To generate a test certificate from the command line, you can use the makecert.exe command line tool. This tool offers more fine-grained options for generating publisher certificates. Run makecert.exe from a command line with the -? switch for a brief summary of options or with the -! command line switch for more detailed options. The makecert.exe tool uses the CryptoAPI under the covers and is available in the .NET Framework SDK binaries (\Bin) folder underneath your Visual Studio 2005 installation (C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin path with a default installation).
To configure certificates with respect to the machine certificate stores, you can use the certmgr.exe tool. If you run certmgr.exe without any arguments, it launches a UI version of the tool as shown in Figure 6.18.
This tool provides a graphical management console for importing, exporting, and removing certificates from the named stores on your development machine. Clicking the Import button shown in Figure 6.18 launches the same wizard discussed in the previous section for installing certificates in stores.
)
Figure 6.18 Certificate Manager Tool
You can also incorporate certmgr.exe in a Windows Installer installation package and use it to configure certificates on a client machine as well using command line options. For example, the following command line will install a certificate in the Trusted Publishers store on a target machine if the certmgr.exe tool is available in the command prompt PATH environment variable.
certmgr.exe -add MyCompany.cer -s TrustedPublisher
Another command line tool to be aware of that was mentioned earlier is the pvkimprt.exe tool. This tool is available for download from Microsoft (www.microsoft.com/downloads) or through the Platform SDK. Pvkimprt.exe lets you take a .cer or .spc file that just contains the public key portion of a publisher certificate, combine it with a .pvk file that contains the private key portion of the certificate, and generate a .pfx password-protected certificate file that contains the entire certificate. To do this, you run the tool with a –pfx switch, also passing the .spc or .cer file path and the .pvk file path. This will bring up a wizard that will step you through the process of providing a password and then exporting the keys to a .pfx file.