By the end of the last post, we’d managed to sign our application installer with a DigiCert standard code signing certificate using signtool in Windows, but were still being presented with the following dialog: This was an improvement over the red bar that we’d seen when downloading the unsigned version of the same installer, but the text is still quite daunting for the user. On the basis of a 2011 MSDN article on Authenticode code signing, we then ordered an Extended Validation (EV) certificate from DigiCert in the hope that it would remove the warning entirely when downloading the installer. Specifically, the article notes that:

In August 2012, Microsoft announced support for a new type of Code-Signing certificate, the Extended Validation (EV) certificate. These certificates tend to be more expensive and harder-to-use (requiring security token hardware) but have the benefit of providing faster accumulation of reputation for SmartScreen.

I will point out at this juncture that DigiCert customer service were excellent throughout. We notified them as soon as we realised the standard certificate wasn’t going to meet our needs and they immediately credited our DigiCert account with $223 (for the standard certificate) and didn’t revoke the original certificate until we’d received and activated the hardware token that’s required for EV signing. The EV hardware token, including expedited international shipping was $474 (so an extra $251 over the standard certificate) and arrived within 2 working days of ordering. Incidentally, the hardware token from DigiCert was an eToken PRO 72k (Java) from SafeNet Inc: It’s also probably worth noting that we’d read a couple of accounts of having serious problems getting the hardware token to work with Windows running inside a virtual machine. Maybe we were just lucky, but we managed to sign the executable in Windows 7 running inside a VMWare Fusion VM on a MacBook Pro running OS X Mavericks with no issues whatsoever. Without further ado, here’s the procedure for signing a Windows executable using the EV hardware token:

1. Obtain the default token password and install the drivers

On receipt of the hardware token, DigiCert directs you to your online account where you can confirm receipt of the eToken and obtain the factory default password. Note that you are only shown this password once so be sure to record it somewhere. Once you’ve noted down the password, the DigiCert site instructs you to download the SafeNet Authentication Client for Windows. At the time of writing, this was at version 8.2 and weighed in at 49 Mb. A standard installation (as opposed to a BSec-compatible installation, which includes legacy iKey support) adds the SafeNet Authentication Client Tools to the Start menu.

With the SafeNet Authentication Client installed, plug the hardware token into an available USB port. As a brief aside, the token identifies itself as a composite USB device (Class 0) with a VendorID of 0x0529 (Aladdin Knowledge Systems) and a ProductID of 0x0620. The main interface of the composite device is Class 11: Integrated Circuit Card Interface Device (CCID). Typically, Class 11 devices have a slot for a smart card (or Integrated Circuit Card in USB parlance), but in the case of the hardware EV token, the card is effectively integrated into the device, as indicated by the “00000000” in the dwMechanical field of the USB device descriptor:

2. Change the default token password

With the hardware token plugged in, select the “Change Token Password” option from the main menu of the SafeNet Authentication Client, enter the factory default password in the “Current Token Password” field and enter and confirm a new password of your choosing in the “New Token Password” and “Confirm Password” fields. The token we received had hard-coded password requirements of between 8 and 16 characters and a “complexity requirement” of at least three different character types (of the four possible: numerals, lowercase characters, uppercase characters and special characters).

3. Sign the installer or executable

Once you’ve changed the token password, leave the token plugged in and open the Windows certificate manager by pressing Windows-R, typing certmgr.msc and pressing enter. The certificate on the hardware token should appear under Certificates – Current User > Personal > Certificates:
Make a note of the exact text that appears in the “Issued To” column.

Unless it’s already on your PATH, open a prompt and navigate to the directory containing your version of signtool (by default, this is C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin with version 7.1 of the Windows SDK) and invoke signtool with the following options:

>signtool sign
/t http://timestamp.digicert.com
/n "Exact text from the Issued To column" "C:\path\to\the\executable\you\want\to\sign.exe"


The SafeNet Authentication Client should then present a dialog asking for the hardware token password set in step 2 and, assuming the correct password is provided, you should then see the following text in the command prompt:

Done Adding Additional Store
Successfully signed and timestamped: C:\path\to\the\executable\you\want\to\sign.exe

And that’s it! The signature can be verified, as with the standard certificate, by selecting the executable in Windows Explorer, selecting File > Properties and switching to the Digital Signatures tab, under which the timestamped signature should be listed.

Conclusion

The outcome with the EV certificate-signed installer is much more user friendly than with the standard certificate:Clicking “Run” results in the download starting, the text being replaced with “Running security scan” and the installer running immediately on the user’s computer. Success!

I’ve recently made a Windows installer (in the form of a WinRAR self-extracting archive) available for download to one of our clients. When testing out the download link (which is currently just secured using HTTP Basic Auth), I chose to “Run” the installer directly and was presented with Microsoft’s SmartScreen Application Reputation feature, introduced with IE9 in 2010. For an infrequently downloaded, unsigned installer package, the dialog that appears after the installer has downloaded and Windows has run its security scan looks like this:
This is obviously fairly intimidating to the end user. To complete the download and run the installer, the user must click “Actions”, which displays a screen noting that the publisher is unknown, that SmartScreen Filter “reported that this program is not commonly downloaded and is not signed by its author” and presenting three options:

• Don’t run this program (recommended)
• Delete program
• Run anyway

The “Don’t run this program” option is selected by default. This is bespoke software, so it’s never going to be “commonly downloaded”, but is there anything we can do to make the process less user hostile? The first port of call was to obtain a code-signing certificate to use with Microsoft’s Authenticode program. The process is summarized in this MSDN blog post from 2011, but I thought it would be worth documenting the process here since the nuts and bolts of it don’t all seem to be in one place anywhere else:

1. Obtain a code-signing certificate

Since DigiCert were on our client’s list of approved certificate providers, we ordered a 1-year code signing certificate which, at the time of writing, cost $223. After an email asking to confirm the order and a telephone call from DigiCert to confirm contact details, DigiCert emailed through a link to create and download the certificate. Since I was downloading the certificate onto an OS X machine in Chrome, the certificate was automatically added to the login Keychain. If you downloaded the certificate using IE or Chrome in Windows, you can skip to step 3 as the certificate should already be in the Windows certificate store.

2. Export certificate to a .p12 file from Keychain Access

Select the downloaded certificate in your Keychain, ensuring that you’ve first selected the appropriate Keychain and the “My Certificates” category to the left:

Then choose File > Export Items… and save the certificate in “Personal Information Exchange (.p12)” format. After choosing the file location, you’ll be prompted to set a password for the exported certificate (and then for the Administrator password to actually export the certificate):

3. Install signtool in Windows

With the certificate exported to a .p12 file, it’s now time to sign your Windows executable. This is best done in Windows using Microsoft’s signtool command line utility. More information about the utility can be found over at MSDN, but you’ll first need to ensure that it’s installed. The utility is bundled with Microsoft Visual Studio 2005 or later and is included in the Microsoft Windows SDK. If you’ve gone down the route of installing the Windows SDK, you should find that signtool is installed here: C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin

4. Sign the executable

Since I downloaded the certificate in OS X, the appropriate signtool incantation references the .p12 file exported in step 2:

>signtool sign
/t http://timestamp.digicert.com
/f "C:\path\to\certificate.p12"
/p password_you_set_during_p12_export
/a "C:\path\to\the\executable\you\want\to\sign.exe"

Note that the timestamp server option specified by \t is optional, but since it adds a cryptographically-verifiable timestamp to the signature, it proves that the executable was signed when the certificate was still valid, obviating the need to re-sign every signed executable at the time of certificate expiry. Each certificate authority has its own timestamp server, which you should be able to locate in their documentation.

After running the above command (without the /f and /p options if you downloaded the certificate in Windows in the first place), you should see the following at the command prompt:

Done Adding Additional Store
Successfully signed and timestamped: C:\path\to\the\executable\you\want\to\sign.exe

And that’s it. Your executable is now cryptographically signed. You can verify this in Windows, by selecting the executable in Windows Explorer, selecting File > Properties and switching to the Digital Signatures tab, under which the timestamped signature should be listed.

Conclusion

The process of signing a Windows executable with a cryptographic signature is relatively straightforward, but unfortunately this isn’t the end of the road for bespoke software providers who are trying to appear reputable to their users. Once we re-uploaded the file to our web server and downloaded it again, the only change from the end-user perspective was that the SmartScreen warning had a yellow banner in place of the red banner and the red warning “shield” from the original dialog had disappeared:

Clicking “Actions” brings up a dialog with exactly the same layout as with the unsigned executable (including a red “shield”), but the publisher is now listed and the text changes from this:

SmartScreen Filter reported that this program is not commonly downloaded and is not signed by its author.

to this:

SmartScreen Filter reported that this program is not commonly downloaded.

Both dialogs still include the text “If you received this program as an unexpected solicitation, link, or attachment, it might be an attempt to fool you. We recommend that you delete it.” and the recommended option is still “Don’t run this program”:

So the problem we’re having is now exclusively one of “reputation” from the perspective of Microsoft’s SmartScreen Application Reputation software, the workings of which are entirely opaque to us. So the next step here is to upgrade to an Extended Validation (EV) certificate and sign the installer using that. From the MSDN article:

“These certificates tend to be more expensive and harder-to-use (requiring security token hardware) but have the benefit of providing faster accumulation of reputation for SmartScreen.”

Although we don’t have the certificate just yet, DigiCert customer service have already been very good about the upgrade to an EV certificate. They credited back the $223 for our standard certificate back within a couple of hours and won’t revoke the certificate until we confirm receipt of the hardware “e-token” required for EV certificate signing. More to follow!

Update June 25th, 2014: Success with the EV certificate!