How to code sign managed code InfoPath forms

Overview

I recently spent more time than I’d like to admit trying to code sign an InfoPath form I was trying to publish. We had recently finished up an intranet project based on Sharepoint Services, and the client asked us to create a simple department level timesheet application that they could begin to use to record time & effort spent on project work. This form would allow two different views of the data: 1) Data Entry view and 2) Summary view.

In the data entry view, department employees would be able to maintain their timesheets during the week. At the end of the month, all the weekly timesheets in the department would be merged by the department secretary, massaged a bit, and then exported to an MS Word document that would be rolled up into a report that was presented to the corporate management team.

This last requirement was the kicker. The form would be deployed to a Windows Sharepoint form library – deploy it once to one location and everyone could access it centrally. Clean, quick, easy. However, when the department secretary used InfoPath to export the summary information for the month, InfoPath would actually invoke MS Word in order to transfer that data to it. That method invocation, in InfoPath terminology, requires the highest security level in InfoPath, level 3. As a result, the only way to allow the user to even use the form is to either 1) install it locally on his/her PC, or 2) code sign the form prior to publishing it on the Intranet or network share. Installing the form locally on each PC that needed it would defeat the bggest benefit we got from using Sharepoint. So, we had to code sign the form.

Well, after much weeping and gnashing of teeth, I finally figured out how to get that done. There’s a lot of information on code signing InfoPath forms; however, most InfoPath forms are still developed with script as opposed to managed languages like vb or c#. In my opinion, managed code has yet to gain a foothold all but a handful of shops. As a result, a lot of misinformation persists.

I assume you are using the following:

• Visual Studio.NET 2003
• InfoPath SP-1
• Business logic in InfoPath is written in a managed code language like c# or v.net – not JavaScript or VBScript.

Step 1: Get a code signing certificate

Most of the examples I read when searching for answers to this issue mentioned the process you had to go through to generate your own test certificate – that usually won’t wash when it comes to deploying in your organization. Typically, you have two choices: 1) Use the Certificate Server application built into Windows Server, or 2) Buy a real code signing certificate from a Certificate Authority (CA), like Verisign (verisign.com) or Thawte (thawte.com) (same company).

Verisign charges $399/year; Thawte charges $199/year. There’s no functional difference between the two – go with Thawte.

When you go through the registration process to purchase the certificate, you will be asked to create a password for your certificate – save this password. It’s very important that you store this in a safe place.

You will receive two files from the CA:

• a private key file that you will name something similar to “MyKey.pvk”
• a certificate file that you will name something like “MyCertificate.spc”

Step 2: Import/Export the certificate

Double click the certificate file to bring up the Windows Certificate store and import the certificate.

Now, you will need to export the certificate in a format necessary for code signing. Run the Certificate Export Wizard:

• Right click on your company name within the personal tab of the certificate store
• Click Export
• Within the Export Wizard, click Next and then choose the “DER encoded binary X.509 (.CER) format”.
• Give the cert a file name (i.e. “MyCertificate.cer”) and finish the wizard.

Note: DO NOT choose the “Base-64 encoded X.509 (.CER) format” in step 3 above – this was one of my problems initially when I tried to sign my code – wrong cert type.Step

3: Install and use the PVK Digital Certificate Files Importer

According to the MS website: “This download lets you sign Microsoft Visual Basic for Applications code in your Microsoft Office 2000 programs when using an authenticated digital certificate.” It also lets you sign an InfoPath form as well. Here’s where you can get the utility:
http://www.microsoft.com/downloads/details.aspx?FamilyID=
F9992C94-B129-46BC-B240-414BDFF679A7

Once you download and run the install, it places the Import utility into the Windows directory. Open a CMD prompt, and execute the following command to load the digital certificate and its respective key into the local system store:

C:\>pvkimprt c:\mycertificate.spc c:\mykey.pvk

Note: Your paths to the above files may be different.

Step 4: Setup your form code project to use your new certificate

Copy the .cer and .pvk file into the formcode area of your InfoPath managed code project. In a typical InfoPath project in VS.NET 2003, you will have a project named something like “Project1”, and the formcode will be in a subdirectory in the project called “Project1formcode”. The “Project1formcode” subdirectory is where these two files need to be placed.

If you don’t already have it installed on your PC, grab a copy of the Microsoft Office InfoPath 2003 SDK. Once it’s installed there are two macros that you’ll need. Check this directory:

C:\Program Files\Microsoft Office 2003 Developer Resources\Microsoft Office InfoPath 2003 SDK\Macros

You should see a files called "InfoPathSDK.vsmacros".

Open up VS.NET 2003 and open that file to install the macros in Visual Studio.

If you check out the Macro Explorer, you’ll see two macros under InfoPathSDK:

• IPFullTrust – this sets the trust level of the code to full trust
• SignCode – this code signs the managed code (.dll) behind the InfoPath form.

Note: Ensure within the SignCode macro that the certificate file name (i.e. “MyCertificate.cer”) and the private key file name (i.e. “MyKey.pvk”) match up with the filenames in that macro. If necessary, edit the macro to ensure the file names match up.

Step 5: Sign both the InfoPath form and the managed code behind .dll

This is critical. What we did in the last step was to set things up in the InfoPath managed code project within Visual Studio such that when any compilation takes place, the managed code behind the InfoPath form is automatically forced to a state of full trust and the .dll is code signed.

In this step, we will do the same thing with the InfoPath form itself. Even though it has no script behind it, the form itself is required to be set to full trust and code signed in order for it to be able to make level 3 DOM calls like we need when we invoke MS Word.

So, with Visual Studio open:

• Right click on the form project and click “Open InfoPath”. This dynamically extracts the formfrom the .xsn file and loads it into InfoPath.
• Click Tools | Form Options | Security
• Under the form signing section, check the “Sign this form” checkbox, and then select your certificate
• Click OK
  

NOTE: Don’t expect to be able to save here! This is an extracted form file we are dealing with, so there’s nothing to save – you are signing the form and publishing it in one step. You’ll need to do this every time you publish the form.

Click File | Publish. This will force a fresh compile of the managed code .dll, code sign it, repackage the .xsn file, and prepare it to be published to Sharepoint.

Follow the InfoPath Publish Wizard to publish the form to an existing Sharepoint form library, a new form library or a file share.

That’s all there is to it. It’s not rocket science, but as I struggled to get this accomplished for my client, it became apparent that there was a LOT of incomplete or just plain false information out there on this topic. I hope this saves you lots of time and effort.

Please let me know if any of this doesn’t make sense. Good luck!