Saturday, August 13, 2016

Installing a Code Signing Certificate, 2016

This is an update to my earlier article about the same subject. This process is much easier than it used to be.

This post was edited on August 1, 2019 to reflect minor changes in the process.

Install a certificate from Sectigo (was Comodo)

  1. Use IE11 for your browser for everything related to the purchase. Don't use Edge or Chrome.
  2. Use Sectigo (formerly Comodo) to buy your Code Signing Cert. They're still the cheapest provider, especially if you go through Tucows and buy a three year certificate.
  3. When filling out the information during the purchase process:
    • Make SURE you click the checkbox to allow the private cert to be exported, or you will be very unhappy.
    • You want a SHA2 certificate, which will do SHA1 and SHA256 signing.
  4. Your private key is generated when you initiate the order, but it is NOT stored in your Cert Store. Therefore, you must start and complete your order on the same machine with the same browser.
  5. After your identity is confirmed, you will receive an email from Sectigo with a subject like ORDER #12345678 - Your Code Signing Certificate is ready!
  6. Install the new certificate by clicking the link in the email. Again, use IE11. When it's done, you'll see something like this:

  7. At this point, your new certificate has been automatically added to your Cert Store.
  8. Verify the installation. Go to Control Panel / Internet Options / Content, click Certificates, select your new certificate, and click View in the bottom right. The certificate will probably be on the Personal page. Make sure you are looking at your new certificate and not the old. You can tell the difference by the expiration date.
  9. Make sure you have the private key. Again on the Certificate page, at the end of the information, right under the "Valid from" dates, you should see something that says "You have a private key that corresponds to this certificate." If this isn't there, you may not have checked the box during the signup process as described in Step 3 above. You will probably need to get the certificate reissued (this is free with Sectigo).
  10. Remove your old certificate. If you are renewing an existing certificate, then keeping the old certificates installed isn't usually useful, and having multiple certificates will break SIGNTOOL if signtool is searching the certificate store. Go to Control Panel / Internet Options / Content, click Certificates, select your old certificate, and click Remove. The old certificate will probably be on the Personal page.

Export the PFX file

A PFX file can be used by many third party utilities. One advantage is that PFX files can be created without a password, which is handy in automated builds if you are using SIGNTOOL. You can see the complete process with pretty pictures at Acmetek. Here's the abridged version:
  1. Go back to the Certificates Page on Internet Options.
  2. Select your new certificate
  3. Click Export...
  4. Click Next.
  5. Select "Yes, export the private key."
  6. Click Next.
  7. Select "Personal Information Exchange - PKCS #12 (.PFX)." (If this option is grayed out, then your private key was not imported).
  8. Check the box labeled "Include all certificates in the certification path if possible." THIS IS VERY IMPORTANT.
  9. You may want to read about the new Windows 10 option, Enable certificate privacy.
  10. Click Next.
  11. Check the Password box.
  12. Provide a password and the confirmation.
  13. Click Next.
  14. Enter a filename.
  15. Click Next.
  16. Click Finish.
  17. If you want to remove the password from the PFX file, use openssl as described in this post from the Wayback Machine. Quick summary:
    openssl pkcs12 -in mycert.pfx -out tmpmycert.pem -nodes
    openssl pkcs12 -export -out mycert2.pfx -in tmpmycert.pem

Sign your code!

If you need some hints on this, see my earlier post.

As of January 1, 2016, all Windows executables destined for Windows 7 or later must be signed with SHA256. If you still support Windows XP and Vista, then you must also dual sign with SHA1. For details, see this excellent article.

Sunday, May 22, 2016

Remote Debugging Visual C++ 2015

This describes how to configure your system to do remote debugging when you are using Visual Studio 2015. There is no installer for the debug DLLs, so you need to work around this problem.

Among other things, these instructions solve this error message:

The program can't start because ucrtbased.dll is missing from your computer.

These instructions take extra steps to handle the case where you are doing DLL builds instead of static linking MFC and CRT.

Note: These instructions should not be used for release versions of MFC and CRT. Those files can be installed with the files in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\1033.

1. Install the Remote Debug Tools

The version you install depends on the bitness of Windows. Most people will therefore want to install the 64-bit version. It will debug both 32-bit and 64-bit applications.
  • Click on Tools for Visual Studio 2015 on the left.
  • Click Remote Tools for Visual Studio 2015.
  • Choose the desired version. The section on top is for Visual Studio Update 2. The second section is for other versions of Visual Studio 2015.
  • Select the desired bitness
  • Click Download
  • Run the installer

2. Create a shortcut to the Remote Debug tool

Next create a link to the remote debugger on your desktop. Below is the command I used. All security is disabled because I'm the only user on my local network. Note the useful "/anyuser" parameter that is very helpful when your test VMs are configured with generic user accounts.

"C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe" /noauth /anyuser  /nosecuritywarn /timeout 10000

3. Copy the MFC and CRT DLL's to your application's Debug directory.

There is no installer for the debug DLLs, so you need to work around this problem.

Let's say your application is in:


Copy the CRT and MFC files as follows. Change MYARCH to be x64 if you are debugging a 64-bit application. This depends on the bitness of your application, not the bitness of Windows.

set MYDEBUG=C:\Projects\MyApp\Debug
set MYARCH=x86

copy "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\debug_nonredist\%MYARCH%\Microsoft.VC140.DebugMFC" %MYDEBUG%

copy "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\debug_nonredist\%MYARCH%\Microsoft.VC140.DebugCRT" %MYDEBUG%

4. Copy ucrtbased.dll into your application's Debug directory

The Universal CRT DLL is from the Windows SDK. It is not in the Visual Studio directory. This is a new file required as of Visual Studio 2015. Make sure you set MYDEBUG and MYARCH as shown in the last step.

copy "C:\Program Files (x86)\Windows Kits\10\bin\%MYARCH%\ucrt\ucrtbased.dll" %MYDEBUG%

Note that the discussion on MSDN about ucrtbased.dll being part of Windows 10 is wrong.

5. Define a network share

Create a network share to your Debug directory. It's a lot easier than copying files around. Let's assume you shared your entire C drive. You can share read-only.

On the VM, mount it as a standard drive. I like to use K:.

Finally, in Visual Studio, in the debugger properties, set the application location to use the network share as the path.

6. Run with remote debugging

Start the remote debugger msvcmon.exe on the VM using the shortcut you created in Step 2.

7. Run the debugger in Visual Studio