Archive for the ‘tips’ Category

Renew your Windows Code Signing Certificates by December 31, 2015

December 14, 2015

Happy Holidays! In this busy time of year, reserve some time for another (hopefully not too expensive) chore that might be unexpected.  Due to the industry push to move from the SHA-1 hashing algorithm to the more secure SHA-2 (e.g. SHA256) hashing algorithm, you may need to purchase or renew your certificates, even if they are still valid.

For various reasons, the deadline for action is December 31, 2015.

Call to Action

Ensure that you purchase or renew (and start using) one or more code signing certificates by December 31, 2015.

The required certificates depend on whether you sign User Mode and/or Kernel Mode Windows modules:

  1. User Mode files (e.g. msi, exe, etc.) must be signed with a SHA-2 certificate starting after December 31, 2015.
  2. Kernel Mode drivers (e.g. .sys files) can be signed with either a SHA-1 or SHA-2 certificate, but SHA-1 is most compatible — even for Windows 10.  But:  December 31, 2015 is the last day you can purchase a SHA-1 certificate.  EDIT 12/29/2015:  Microsoft has rescinded this deadline.

User Mode Q and A

Q:  What happens if I continue to use my old, still valid, SHA-1 certificate after December 31?

A:  Windows will ignore your signature as if your files were unsigned.


After these dates have passed, Microsoft software such as Internet Explorer® and Windows® will reject code signing and SSL certificates that use SHA-1.


On Win 7 and above, blocked on 1/1/2020 if time stamped before 1/1/2016, otherwise, blocked after 1/1/2016 for Mark of the Web files.

Q:  Will there be compatibility issues if I sign with SHA-2?

A:  No, not for User Mode.  (Kernel Mode does have compatibility issues, see below.)  SHA-2 for User Mode is supported in Windows XP SP3 and later.


This is a list of popular software that supports SHA-2:
Windows XP 3 and above (including Windows 8.1, 8.0 and Vista)

Windows Server 2003 and above

Q: I already have a SHA-1 certificate.  Do I have to spend money and buy a SHA-2 certificate also?

A: Contact the Certificate Authority (CA) which issued your SHA-1 certificate (e.g. Comodo, DigiCert, GlobalSign, etc.).  They should give you a SHA-2 version for free, which has the same expiration as your original SHA-1 certificate.

Q: I already have a valid SHA-2 certificate.  Do I need to do anything?

A: No, congratulations, you are good to go!  Just make sure you sign with it starting January 1, or earlier.

Kernel Mode Q and A

SHA-1 Certificate Availability

Q:  I don’t have a SHA-1 certificate, but I don’t plan to sign kernel mode modules yet.  Can I wait to purchase a SHA-1 certificate until I need it?

Q:  I currently have a SHA-1 certificate, and it is valid for some time to come.  Why do I have to renew it by December 31?

A:  December 31 is the last day that you can purchase or renew a SHA-1 certificate.  So it is now or never.  EDIT 12/29/2015:  Microsoft has rescinded this deadline.

CA/Browser Forum

Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. […]

Effective 16 January 2015, CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA-1 algorithm with an Expiry Date greater than 1 January 2017 […]


CAs SHOULD issue SHA-2 only, unless developer is targeting Vista and Server 2008 (for them, CAs MAY issue SHA-1)

Also, I recommend getting a multi-year certificate — On December 7, 2015, I got a SHA-1 version of my DigiCert EV SHA-2 certificate; both are valid through 2018, despite the above warning that the SHA-1 version should expire no later than January 1, 2017  — to minimize the possibility of having to deal with certificate issues again for as long as possible.  When it expires, you will be forced to switch to SHA-2 (or SHA-3 or whatever the standard is by then), and deal with whatever rules are in effect.

However, prior to your new SHA-1 certificate expiring, the industry could disqualify it for kernel mode, the same as it did for SHA-1 User Mode (which is disqualified on January 1).  So try to strike a balance between getting a certificate for too short or too long a time period.

Q: I already have a SHA-2 certificate.  Do I have to spend money and buy a SHA-1 certificate also?

A: Contact the Certificate Authority (CA) which issued your SHA-2 certificate (e.g. Comodo, DigiCert, GlobalSign, etc.).  They may give you a SHA-1 version for free, which has the same expiration as your original SHA-2 certificate.  I have a DigiCert EV SHA-2 certificate, for which I was given a free SHA-1 certificate with the same 2018 expiration date.  I also have a Comodo Authenticode (non-EV) SHA-2 certificate which expires in 2018, and thus far, Comodo has only offered to give me a free SHA-1 certificate that expires on December 31, 2015!  So your experience may vary.

The summary on the MadCodeHook forum is that DigiCert and GlobalSign are proven to still issue SHA-1.  There is a question of whether businesses are treated differently from individuals.

Q: I already have a SHA-1 certificate with a long time left until it expires.  Do I need to do anything?

A: No, congratulations, you are good to go!

SHA-1 vs. SHA-2

Q: Why is SHA-1 better than the newer and the more secure SHA-2?

A:  SHA-1 is completely compatible with Windows XP through Windows 10.  You can sign one driver package for all of these OS’s, using the tried and true method of using a cross certificate.  It remains the only option for XP and Vista.

Q: But won’t my software be more secure if I sign it with with a SHA-2 certificate?

A:  No, the purpose of signing software is to prove that you created it. The way it works is when your customer downloads/installs/loads your software, it is Windows that verifies your signature and reports something like “Verified Publisher:  <the company name from your certificate>.

An attacker can use the more insecure SHA-1 to more easily spoof your signature on software that the attacker creates (e.g. malware).  Such malware would appear to have come from you.  Windows would report “Verified Publisher:  <the company name from your certificate>.  But, this scenario, appalling though it is, can happen even if you sign your legitimate software with SHA-2.  An attacker can still sign the malware with a spoofed SHA-1 signature of yours.  So you can see that whether you sign your software with SHA-1 or SHA-2, it makes absolutely no difference in the likelihood of being spoofed.

Q:  Well, even if my software isn’t more secure by signing with SHA-2, doesn’t signing with SHA-2 make me a good Windows developer and improve the overall Windows ecosystem?

A:  No, if Windows accepts SHA-1, it is vulnerable to SHA-1 attacks, such as the above spoofing example.  The only thing that strengthens the Windows ecosystem is for Windows to invalidate SHA-1, which so far it is not doing for Kernel Mode (but is for User Mode).

(My speculative opinion with no applicable knowledge:  Since MS is invalidating SHA-1 for User Mode, but is continuing to accept SHA-1 for Kernel Mode, perhaps the payoff to do so is not as great as for User Mode.)

SHA-2 Compatibility

Windows 7

Q: I don’t care about XP and Vista.  I only care about Windows 7 and later (8, 8.1, 10). Aren’t these OS’s compatible with the more secure SHA-2?

A: For Kernel Mode, Windows 7 is only compatible with SHA-2 if the little-known update KB3033929, released in March, 2015, is installed.  For marketing reasons such as lack of customer comprehension and technical ability, and the difficulty of installing in certain cases (e.g. having a multiple-boot configuration of Windows and various distributions of Linux or using a non-Windows boot loader), you may not want to make this update a prerequisite for using your software.  (I surely don’t.)

SHA-1 Compatibility

Windows 10

Q: Are there any limitations of signing with SHA-1 for Windows 10?

A: The limitations are described in the Microsoft Code Signing FAQ:

  • A cross-signed driver using a SHA-1 or SHA-256 certificate issued after July 29th, 2015 is not recommended for Windows 10.
  • A driver signed with any certificate issued after July 29th, 2015, with time stamping, is not recommended for Windows 10.
  • A driver signed with any certificate that expires after July 29th, 2015, without time stamping, will work on Windows 10 until the certificate expires.
  • Enterprises may implement a device guard policy to modify the driver signing requirements using Windows 10 Enterprise edition. Device Guard provides an enterprise-defined code integrity policy, which may be configured to require at least an attestation-signed driver. [Ed. An “attestation-signed driver” is one that is signed by Microsoft through the SysDev portal (see below).]

At the very least, you can sign with a certificate (SHA-1, non-EV SHA-2 or EV SHA-2) without timestamping, and it will be good until your certificate expires.  But timestamping is highly recommended so that the signature lasts “forever”.  And even this will work, even though it’s “not recommended” (whatever that means).

Besides this, there is an additional caveat regarding Windows 10 Enterprise.  Windows 10 Enterprise supports a feature called Device Guard, which can be used by IT Admins to set a policy disallowing non-EV certificates (including SHA-1 certificates, as EV is not an option for SHA-1).


8 Required:EV Signers In addition to being WHQL signed, this rule requires that drivers must have been submitted by a partner that has an Extended Verification (EV) certificate. All future Windows 10 and later drivers will meet this requirement.

(Personally, I do not have any customers that are running Windows Enterprise that are setting this policy.)

Q: Isn’t an Extended Validation (EV) SHA-2 certificate required for Windows 10?

A: For Windows 10, an expensive and inconvenient EV SHA-2 certificate is required to use the Microsoft SysDev portal.  But a non-EV SHA-2 or SHA-1 (all SHA-1 certificates are non-EV) are fine if you don’t use the portal.  And it is not required that you use the portal to sign your Kernel Mode software for any current release of Windows.

Q: But I’ve heard that Microsoft requires us to use their SysDev portal for Kernel Mode on Windows 10?

A: No, there is a “transitional policy.”

OSR blog – quoting Microsoft Program Manager James Murray:

Windows 8 style kernel mode code signing will continue to work, as long as the certificate was issued prior to Windows 10 RTM (the cut off).

Q: Um, this says my certificate works only if it was issued before the Windows 10 RTM date.  So isn’t it too late to get a SHA-1 certificate for Windows 10?

A: No, as discussed above, the Microsoft Code Signing FAQ now says certificates issued after July 29 will also work, subject to the limitations above.  Furthermore, the verbatim quote from Microsoft Program Manager James Murray was originally

Cross-signing will continue to work, as long as the cross-signing certificate was issued prior to Windows 10 RTM (the cut off).

Here, it says it is the cross certificate whose date matters, not the developer’s certificate.

However, in discussion on the OSR NTDEV list, messages #95 – 97, it was discussed that the effective date of the cross certificate could not possibly have any bearing on whether the signature was accepted by Windows 10.  As such, the post author intentionally altered the quotation to “clarify” that it was the developer’s certificate that needs to be issued before the RTM.  Here is what the blog now says:

Windows 8 style kernel mode code signing will continue to work, as long as the certificate was issued prior to Windows 10 RTM (the cut off).

In hindsight, it seems that the original wording was the correct one, given Microsoft’s clarification that “any certificate” can indeed be used for Windows 10.

David Grayson’s blog and MSDN thread are additional sources that it is the expiration date of the cross certificate that is important:

However, there is a really nice loophole. For backwards compatibility, kernel-mode drivers signed with a valid cross-certificate that pre-dates Windows 10 will continue to pass signing checks in Windows 10. The cross-certificate from GlobalSign was issued long before Windows 10 and it expires on 2021-04-15. Therefore, you should be able to sign kernel-mode drivers for Windows 10 with a regular GlobalSign code-signing certificate until then.

Please see the April Fools Day announcement from Microsoft:
It says:
“To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10.”

Microsoft continues to be vague.  In addition to the above points, the Microsoft Code Signing FAQ also says

A cross-signed driver using a SHA-1 certificate issued prior to July 29th, 2015 will work on all platforms starting with Windows Vista through Windows 10.

Again, it is not clear whether they are talking about the developer’s SHA-1 certificate, or the cross-signing certificate from the CA.

Anyway, when in doubt, try it!  The DigiCert SHA-1 cert issued after the Win 10 RTM date works for me on Win 10 Pro x64 with SecureBoot enabled. I tested on a Windows 8.1 Hyper-V VM (Generation 2, with SecureBoot enabled). The guest OS is Windows 10 Pro x64, Version 1511 (10586.17).

There are other success stories sprinkled into the threads cited in this post.

SHA-1 – Windows 10 Summary

Microsoft clearly wants their SysDev portal (and EV certificates) to be used for Windows 10, and any allowance of non-EV SHA2 and SHA-1 with cross signing is being done with sheer reluctance and non-transparency.

Microsoft has a history of doing this. I am reminded of a similar situation when MS was encouraging converting from the ANSI charset to the Unicode charset.  Yes, there are advantages to using Unicode (e.g. easier localization), but also disadvantages (e.g. 2x the memory).  And ANSI is still supported in Windows, but is “not recommended”.  But I still use it when it make sense.

Despite Microsoft using vague phrases like “not recommended”, SHA-1 works today on Windows 10, and Microsoft has made a pattern of further relaxing its SysDev portal (and EV certificate) requirements.  The SHA-1 compatibility with previous Windows versions is so great that I recommend using it for Windows 10 until it is definitively prohibited.

To continue using SHA-1, ensure your certificate is renewed for a sufficient time period.


Free 30 day trial
DCSoft RegEditX – Tweaks for RegEdit
When you RegEdit, remember the ‘X’


Hyper-V — Remote Desktop: Good, Virtual Machine Connection: Bad

February 10, 2015

I run Hyper-V virtual machines (VM’s). I copy and paste using the clipboard between the host and VM’s, and between the VM’s themselves. A lot. So it is truly annoying when the clipboard doesn’t work. And no, it doesn’t work if you simply do what comes naturally — find the VM in the built-in Hyper-V Manager, right click, and select Connect.

This opens a window of your VM, using “Virtual Machine Connection”. But this window doesn’t support the clipboard, nor any of the following:  redirected audio, drives, or printers. There is something new called Enhanced Session Mode which does support them, but only if the client OS is Windows 8.1 Enterprise or Windows Server 2012. I don’t know about you, but those aren’t the OS’s I typically put into my VM’s. So this would seem to be a worthless feature.

Thankfully, there is an easy alternative. Just use the Remote Desktop Connection application (connecting to other computers via Remote Desktop), which is built into all Windows. Remote Desktop has for years supported all of the missing clipboard and redirection of client resources such as printers.

[Caveat] Again related to the client OS running in the VM – the client OS needs to support “being a Remote Desktop host” (being connected to via Remote Desktop).  For example, Windows 7 Home Premium does not support this, but Windows 7 Professional/Ultimate does.

[Setup] You will need to enable Remote Desktop in the client OS and know the client’s Computer Name in order to connect to it.

Short wish: One of the things missing from Remote Desktop that VMware Workstation has is dragging the client desktop window to resize it, and then the client “hardware” display settings are changed so that it matches the new window size. The client remains optimally sized, as intended.

One client, One VM

February 10, 2015

Juggling several client projects at once requires some sort of dedicated computer resources for each of them. Happily the state of the art makes it very easy. At first, I used just one computer and just juggled.  Then I installed SysInternals Desktops to be able to switch to different screens for each client.

This proved too little, as each client eventually needed incompatible Visual Studio configurations. For example, the .NET projects benefited from add-ins like .NET Demon (continual rebuilding of the project), but this was incompatible with C++ projects. In addition, some clients required the Qt add-in, different versions of the Windows SDK, some required the DDK, etc. One needed the Dev Express ASP.NET controls, but that license was only for that client and I couldn’t use it for other projects.

Clearly the easiest way to assure an optimum environment for each client was a dedicated PC. While I do have enough computers to do this, so many physical machines makes for a very crowded desk, and I only have one good keyboard, mouse, and 30″ monitor, Happily, the performance of virtual machines makes this an unnecessary cost and inconvenience.

Which virtual machine software is the best? The cheapest and best performing is Hyper-V. Compared to my other favorite, VMware Workstation, it is a Type 1 hypervisor,  which allows for faster performance, and it’s now included free with Windows 8(.1).

So my main development machine is a 3 year old Core i7, with 24 GB RAM and 1 TB SSD. I can run several Hyper-V VM’s with dedicated 4-6 GB of RAM simultaneously. Since most of the time they are just sitting idle, the one or two I am working in are very fast performing.

It is such a productivity booster to be able to Remote Desktop into these VM’s from anywhere on the Internet (although mostly from the Hyper-V host machine itself) with all the apps open exactly as I have left it. As I get older, my memory forgets things like what is the next thing to do for a client, and seeing all the apps there just as it was when I last worked on it saves me many minutes of ramp up time.

So it works great, and I wouldn’t change a thing.  The one irritant is the initial setup of the VM’s.  The number of installs you need to perform grows proportionally to the number of VM’s you create.  But this is not as bad we it could be.  First, we can create a “reference VM” which we clone to start all the new ones; the reference VM has all our must-have apps installed and configured, so these automatically work for all our new VM’s.  This also helps with software that allows only a limited number of installations – when such software is installed, it checks a server on the Internet to see how many times prior the license file was installed.  But after installation, it doesn’t check the Internet anymore.  So if the VM is subsequently cloned, that software is none the wiser.   (I realize this subverts the letter of the license, but not the spirit — I paid for a license to have full use of the software, I can’t help it if the software has a license that does not keep pace with how people use computers today.)

The second thing about all these installs is that they go way faster now, with the SSD.  Even gargantuan packages like Visual Studio and Office install (relatively) very quickly.