Now that cross-signing is deprecated, how are you all supporting Windows 7 ?

For some time, we’ve been signing our driver in a slightly complicated way. We first cross sign it using a Digicert certificate and then the cross signing certificate:

$result = &"C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\signtool.exe" sign /f $env:PFX_SECUREFILEPATH /p $env:PFX_PASSWORD /ph /ac "C:\Program Files (x86)\Windows Kits\10\CrossCertificates\DigiCert_Assured_ID_Root_CA.crt" /fd sha256 /tr http://timestamp.digicert.com /td sha256 /as $_.FullName 2>&1

Then we wrap it in a Cab file, EV sign it with an EV signing token and use the MS hardware portal REST API to attestation sign it via the MS Partner Portal. This gives the driver two certificates (ours and Microsoft’s) and ours is also cross signed.

Recently, we tried to renew our general code signing certificate and digicert told us that they no longer support cross signing because Microsoft has deprecated it. They pointed us at this document:

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates

This document seems to suggest that Windows 7 should now be supported via Partner Centre signing alone. However, when I take out the cross sign, I find that our driver will no longer load on Windows 7 (latest updates) and will only load on Windows 10. Others have pointed out that cross-signing is actually required for Windows 7:

https://stackoverflow.com/questions/68302908/windows-ms-signed-filter-driver-doesnt-load-on-win-7-x64-after-updating-driver

So… has anyone else had this issue? How are you now supporting Windows 7 if you have a certificate which doesn’t support cross signing? Digicert tell me that Microsoft alone can now cross-sign drivers.

Here’s the error we get on Win7 and what our cert looks like now:

https://imgur.com/WxcDnLe

My understanding is that there is an issue in Windows 7 with SHA-256 signatures that is being fixed in the near future.

@Jeremy_Hurren said:
My understanding is that there is an issue in Windows 7 with SHA-256 signatures that is being fixed in the near future.

That’s interesting. Can you recall where you heard that? I hope it is near because my cross-signing capable certificate expires in about 30 days at which point I might have to unexpectedly drop support for Win 7 :slight_smile:

@BenStaniford said:
That’s interesting. Can you recall where you heard that? I hope it is near because my cross-signing capable certificate expires in about 30 days at which point I might have to unexpectedly drop support for Win 7 :slight_smile:

So the only public mention of it that I am aware of is https://techcommunity.microsoft.com/t5/azure-virtual-desktop/public-preview-fslogix-release-2105-is-now-available-in-public/m-p/2380996

1 Like

@Jeremy_Hurren said:
So the only public mention of it that I am aware of is https://techcommunity.microsoft.com/t5/azure-virtual-desktop/public-preview-fslogix-release-2105-is-now-available-in-public/m-p/2380996

Ok, thanks. That’s certainly alluding to something which could be it.

Then we wrap it in a Cab file, EV sign it with an EV signing token and use the MS hardware portal REST API to attestation sign it via the MS Partner Portal. This gives the driver two certificates (ours and Microsoft’s) and ours is also cross signed.

Is this a non-PnP driver? The problem with attestation signing is that they replace your CAT file with one that only supports WIn 10. Are you using a fake INF just to get the SYS file signed?

@Tim_Roberts said:
Is this a non-PnP driver? The problem with attestation signing is that they replace your CAT file with one that only supports WIn 10. Are you using a fake INF just to get the SYS file signed?

Yes, I’d forgotten that. We are indeed doing that. As far as I’m aware though, that’s the only way to sign a driver for Win 7 right? I’m not aware of any other way (anymore).

Is this a non-PnP driver?

Yeh, it’s a minifilter.

Ah, it looks as though I should follow Peter’s blog articles more assiduously:

https://www.osr.com/blog/2021/04/08/lost-cause-no-driver-updates-allowed-except-for-win-10/

The workaround “for some” here seems to work for me… Looks like I don’t have to drop support for Windows 7 yet after all…

I hope it is near because my cross-signing capable certificate expires in about 30 days at which point I might have to unexpectedly drop support for Win 7 :slight_smile:

If you are still signing your drivers using cross-certificate, you are risking the revokation of your cert, because Microsoft forbids to do this after July 1 this year.

Geez… I take a couple of days off and poor Mr @BenStaniford has to find my blog post all by himself.

Glad you have a solution that works for you,

Peter

1 Like

@“Peter_Viscarola_(OSR)” said:
Geez… I take a couple of days off and poor Mr @BenStaniford has to find my blog post all by himself.

Glad you have a solution that works for you,

Peter

? Cheers Peter, and thanks for taking the time to write that article.

You asked the question, and it’s a topic near and dear to me because I have several medical device and industrial equipment clients that are indeed running Win7 and really need to support new device firmware in drivers that I wrote years ago.

There is zero interest in updating the OS (and actually for a medical device company that means a whole new FDA and for the industrial equipment client an OSHA review of this Win10 OS thing) so that’s never going to happen … and they really, really need to be able to support the new hardware devices coming out … it literally means a make or break situation for some folks

As @“Peter_Viscarola_(OSR)” points out in his blog, getting a new signature for anything other than Win10 just isn’t going to happen unless the customer buys MS, takes them private, cleans house and sets some new policy … :slight_smile:

What to do, other than nod sadly as I walk away? Well, in my specific circumstance all of my devices are USB based so I have an “out” … rewrite to UMDF from KMDF. Most happily when I wrote those original drivers I used KMDF (but still the porting process is as easy as that handy little porting document states and I have to be porting nice clean KMDF to the UMDF v1.1 of Win7 days which is like chewing broken glass while singing opera) but at least making the pivot to UMDF is at least possible.

UMDF lets me ship drivers that only need to be code signed as a “trusted publisher”, NOT kernel mode signed so they install on Win7 … that’s the whole point of the exercise …

It’s an exceptionally time consuming and laborious process (did I mention that UMDF v1.1 is COM based ?!?) and my SOW’s are usually measured in months of work (even with my handy little UMDF 1.1 framework I’ve cobbled together) and I hear language that would shame a sailor when I present it, but at the end of the day it really is the only way to support Win7 that I can put forward …

My $0.02 response …

1 Like

Hi guys,
I just wanted to clarify. Attestation signing for Windows 10 can be processed without a cross-certificate, right? So, we just sign the driver and cab files with our EV certificate and submit the cab file at https://partner.microsoft.com/en-us/dashboard/hardware/driver/New, correct? Which means that deprecation of cross-certificates doesn’t affect folks not supporting drivers for older Windows OS, right?
It’s just that even though we did support only Windows 10 x64 for a long time now we were still using a cross-certificate while signing the driver.
Thank you.

Which means that deprecation of cross-certificates doesn’t affect folks not supporting drivers for older Windows OS, right?
Not exactly. First, you must now have an EV certificate, while before deprecation you could use a normal certificate (which is cheaper and more easily obtained) plus cross-certificate, sign the drivers with it, and load them with Secure Boot off. Now this path is closed completely. Second, you cannot sign just any driver via Microsoft. For instance, GPL drivers are forbidden to submit (discussion here).

But if your company already has an EV certificate, and attestation-sign drivers for Win10, and always does internal testing either in Test Mode, or with fully-attestation-signed drivers (and never with locally-cross-signed drivers), then indeed, nothing changes for you.

Attestation signing for Windows 10 can be processed without a cross-certificate, right?

Correct, the deprecation of cross-signing has not stopped or changed anything about Attestation Signing for Windows 10.

So, we just sign the driver and cab files with our EV certificate and submit the cab file at
https://partner.microsoft.com/en-us/dashboard/hardware/driver/New, correct?

The only thing you “must” sign is the .CAB file. If all you have is an EV certificate, then yes you would sign it with the EV. Technically the .CAB can be signed with any certificate you have uploaded to your Microsoft Partner Portal account, if you have other non-EV certificates uploaded in addition to your EV certificate.

Note if you want to preserve your option to use these Windows 10 Attestation-signed driver files on a pre-Windows 10 platform, you specifically need to not sign the drivers prior to putting them into the .CAB file. Presence of your (now not cross-signed) signature as the “first signature” on the file will prevent the driver from being considered validly signed by pre-Windows 10 platforms, despite the presence of the Microsoft signature as “an additional signature.” If you’re using the driver only on Windows 10, this doesn’t matter, and presence of your non-cross-signed signature doesn’t prevent Windows 10 from recognizing the Microsoft signature also on the file.

Which means that deprecation of cross-certificates doesn’t affect folks not supporting
drivers for older Windows OS, right?

Essentially correct. We could quibble that even on Windows 10, cross-signed drivers were still being accepted so long as Secure Boot was not enabled. So “even on Windows 10” there is an effect for the deprecation of cross-signing.