In this article, the digital signatures I describe are used for “signing” source code, they are not the digital signatures you would use to sign email. The focus of this article is on digital certificates. The two main reasons you as a developer would use a digital certificate are to:
1. protect your software from tampering after you’ve published it, and
2. guarantee to your customer that your software did in fact come from your company, not a firm masquerading as you.
What files can you sign with a code-signing digital certificate? A wide variety: Microsoft Office documents, ActiveX controls, Java applets, DLLs, CAB files, among others.
If you distribute Microsoft Office macros to people outside your office, whether as Word documents with code in them, Excel workbooks with code in them, or any type of Office add-in, you need to sign these files with a code-signing digital certificate issued by a Certificate Authority. Why?
Because the technology is readily available, affordable, and it gives your customers a high level of confidence in the authenticity of your code. Signed code assures your customers that your stuff is indeed your stuff, not code manufactured by some yahoo who stole your moniker. Signed code also guarantees that your code hasn’t been tampered with and that it hasn’t been corrupted in transit. Given the ease with which Office documents can propagate viruses, using a digital certificate is a smart business decision. The benefit to the customer manifests itself like so. (Note: throughout this article the term “customer” can also be read as “user” since people inside your organization– users–and outside your organization–customers–can be the beneficiaries of your Office VBA projects.)
When the customer opens, loads, or uses an Office file that contains VBA code, and that file has been signed by a digital certificate, all of that file’s functionality will be available regardless of the macro security level setting active on the customer’s PC right then. Furthermore, that functionality is available without the customer having to answer a macro warning dialog each time she uses the tool. The first time the tool is used on the system, if the customer has never before “trusted” the digital certificate’s source company on this PC, that’s when the customer gets to decide what level of trust to give to your digital certificate.
A Certificate Authority is a company that is mutually trusted by code developers and code consumers. A list of Certificate Authorities is available here:
A code-signing digital certificate from market leader VeriSign (the VeriSign Class 3 Developer ID) costs $400 up front and a $400 annual renewal fee. At PRIME Consulting Group, Inc. we use a Thawte Developer Certificate. Thawte’s Developer Certificate costs $200 up front with a $100 annual renewal fee. (Thawte was bought out last year by VeriSign but continues to maintain its Thawte brand.)
(The following two links were unintentionally omitted in the original email version of the article. — Ed.)
What if you’re part of a larger organization and only need to distribute certified code inside the company? Microsoft’s “trust me, it’s me” SelfCert.exe tool won’t cut it. You need to set up a Microsoft Certificate Server that allows your company to act as the Certificate Authority for all its employees. For more information see:
Here are the steps to follow to get your digital certificate, and how to use it to sign an Office document that contains code. Due to space constraints, you’ll find each step’s details in this article’s supplemental Web page:
1. Put one person in charge of code signing.
2. Choose a Certificate Authority.
3. Establish one PC as the “code signing” PC.
4. Apply online for a digital certificate, while on your code signing PC.
5. Pick up your digital certificate using your code signing PC.
6. Turn on timestamping on your code signing PC.
Be sure to timestamp your digital signatures. The precise technique for doing so varies from one Certificate Authority to the next. By timestamping, the software behind digital certificates can verify that a particular signature was applied while the certificate was still valid, meaning, before its one- year expiration date.
Annoyingly, there is only one way to be certain that a file was successfully timestamped when you sign it. You must watch your modem lights (or firewall activity indicator) for a brief flurry of communication between your PC and the timestamping server at the moment that the digital certificate is applied (see next step). There is no user interface or properties sheet for a file to indicate that its digital signature has been timestamped.
7. Run the PVK Digital Certificate Files Importer on your code signing PC.
For more information see:
8. Sign the Office files that store your code using your code signing PC.
Make sure you’re connected to the Internet. Assuming the file is a Word template, open the template, start Word’s Visual Basic Editor, and select the template’s VBA project in the Project Explorer. Now select Tools, Digital Signature, click the Choose button, select your company’s digital certificate from the list, OK, OK. Save the Word template. Once saved, it has been digitally signed and timestamped.
9. Test the signed file on any PC.
You can test on any PC, not just your code signing PC. Set Word’s macro security level to High, close Word, restart Word, and open the signed template. If this is the first time this PC has ever opened a file digitally signed by your company’s digital certificate, you’ll see a Security Warning prompt. After setting this trust level, whenever you open that template on this PC–even with a High macro security level setting–there will be no macro warning dialog and the code behind the template will be silently enabled, as it *should* be for an add-in from a trusted source.
If you don’t timestamp a project, once your system clock encounters a time beyond one year from the date of your digital certificate’s issuance, a Security Warning dialog will state, “A certificate (signing or issuer) has expired.” A timestamp avoids all this inconvenience.