Cross signing certs expiring this week, how will WHQL work?

From what I understand looking HERE starting this summer, WHQL signing is the only way to get a driver to load. The thing I do not grasp, is how do we go about running the WHQL tests without a functioning cert? On April 15th my digicert cross signing cert expires. How would I run a WHQL test with a new driver built April 16th? Typically for either a WHQL or attestation signing I would sign using our cert locally, then run the tests, then submit the package (also signed) and MSFT’s portal would add their signature in addition to mine.

Will the WHQL tests be relaxed to run with a non-signed driver? Or do I have to use a test cert? Add if so, will the MSFT portal recognize and strip any test signature that is present? It was fine before, even desirable, to have my company’s signature and MSFT’s but I don’t want a test cert present in a shipping binary even if Windows will ignore it for validation purposes.

-JT

You can test-sign the drivers, and switch the HLK/HCK client machines into test-signing mode. Alternatively, you can sign the drivers with your certificate without a cross-certificate. It will not be a valid kernel-mode signature, but in test-signing mode it will be accepted (except in Windows 7, which requires a SHA-1 certificate, and does not accept a SHA-2 one even in test-signing).

During WHQL signing, Microsoft does not remove any signatures your driver already has (but it will remove the CAT file and generate a new one, signed with MS; CAT files do not support multiple signatures).

Unfortunately, Microsoft’s documentation is still very unclear about the new signing requirements. Technically, there are 4 possibilities of what kind of signature the added drivers could have: completely unsigned, test-signed, signed with your certificate, and signed with your certificates and a cross-certificate (for those CAs whose cross-certificates do not expire soon). But I cannot understand from Microsoft’s description whether each of these possibilities is legally forbidden, or permitted (but not required), or mandatory.

I have been searching for information, and thinking over this whole situation a lot, recently. But I have not arrived to any definite conclusion. Here is the summary of my thoughts. Beware: I’m trying to think logically here, which is always a risky path with legal documents, but it’s the best one I have.

  • If you test-sign the drivers that you add to the hlkx package, this signature will remain on the drivers along with the WHQL signature. It does not seem to violate any of the legal requirements, but it definitely would look weird, and serve absolutely no purpose whatsoever. So I would disregard that option.
  • Adding an unsigned driver to the package will give you a WHQL-only signed driver. Which is fine, but it would make it impossible to identify you as the developer or maintainer of the driver. It would look like Microsoft solely developed, signed and distributed the driver (granted, there’s also the Provider field in the INF, but still). And if anything goes wrong, they will be to blame, not you. (Of course, I’m sure they have protected themselves against it, but nonetheless the first hit lands on their heads.) So, does MS consider it a normal situation? I have no idea. Digital signatures have always been used with the purpose of securely identifying a source of the binary. Did MS decide to throw that purpose into a garbage bin for the drivers? I have no idea. I just could not find any information about whether you must have any signature at all on the attached drivers, or not. Which does not mean there is no such document, of course, I could have missed it. So this is a very questionable option.
  • Adding a signature with a cross-signature is directly forbidden by the document linked above (at least, after July 1). It is possible, that if a cross-signed driver is also WHQL signed, MS would not consider that a violation of the agreement. But as of now, the document does not mention any exceptions from the “no cross-signatures” rule. Therefore, I would be cautious with this one too.
  • And, finally, signing with your certificate without a cross-signature. It may seem the safest bet, but the wording is ambiguous. «You cannot use a certificate that chains to a cross-cert that expires after July 1, 2021 to sign kernel-mode drivers.» Well, let’s suppose I have a certificate, which chains to a cross-certificate that does not expire after July 1 (say, Entrust). If we follow that quote to a letter, I am forbidden from signing drivers using this certificate, even if I do not include a cross-signature. Because it does not say a signature that chains to a cross, it says a certificate that chains to a cross-cert. I agree, that would be completely stupid if MS forbade to use certificates for identifying yourself, just because there happens to exist somewhere a non-expired cross-certificate, which you don’t even use. But after their decision about the whole cross-signature deprecation, I find myself unable to say “MS would never do that because it’s stupid”.

Therefore, as of now, I would consider either attaching non-signed drivers, or drivers signed with your certificate (no cross-certificate). But I cannot choose between these two, each has its pros and contras. I don’t think this puzzle can be solved reliably without contacting Microsoft.

C’mon… You’re making this a bigger deal than it is.

You have one or more cert that are registered with the dashboard. Sign everything with one of those certs, including your driver package, when you submit it for Attestation Signing. No cross-signing. The Attestation Signed package will install only on Win 10.

OR

Don’t sign the drivers, and the package will be installable on Win 7 and Win 10.

Done. No need to ask MSFT anything,

Peter

Well, considering that MS threatens to revoke the certificate if you do anything wrong, I don’t think that being cautious is unwarranted. But that’s just my opinion.

Thanks for the detailed reply, Captain. You’ve touched on some of the concerns I’ve had as well. My CA (Digicert) won’t even issue kernel signing certs any more. I had renewed for 3 years last year and they actually refunded me 2 of those 3 years. They’ve thrown up their hands and indicated MSFT hasn’t answered enough of their questions for them to continue in this space. But as you say, it would still be nice to have our company names stamped on these things. Perhaps a normal code signing cert such as what you would use for a .dll or .exe is the supported path going forward? This cert would validate who wrote it, and the MSFT/WHQL cert would grant it permission to load. Seems pretty simple. But if this is actually the deal why couldn’t the MSFT page simply say so in a single paragraph? :slight_smile:

Well, if you plan to distribute drivers, you will have to WHQL or Attestation sign them. And for that you have to have an EV code signing certificate. So you can just use the same EV for also signing the drivers before adding them into the hlkx package; you don’t need an additional certificate for that.

@“Peter_Viscarola_(OSR)” said:

Don’t sign the drivers, and the package will be installable on Win 7 and Win 10.

Peter, I’ve seen the “don’t sign the drivers” advice a few times. What is the purpose of that? I’ve submitted signed drivers for attestation signing and the returned package installs just fine (modulo the Big Red Warning) on Windows 7. Are you trying to install on older Windows 7 that doesn’t have the KB to allow it to process multiple signatures on a binary?

Here’s one for you: I’m sure it will get shot down in short order (I’ve no doubt missed something), but on Windows 7 why can’t I install my attested-signed binaries in conjunction with a catalog file that I’ve generated with inf2cat and signed with my new, non-cross-certificate-having certificate? There aren’t any KMCS requirements at PNP install time when the catalog file is consulted, right? If the binaries have embedded signatures, is the catalog ever consulted at load/run? Any other sort of Code Integrity thing that may come into play here? I just tried installing a driver like this on Windows 7, and it seemed to install just fine (and no red pop-up!), so I wonder what I’m missing.

Are you trying to install on older Windows 7 that doesn’t have the KB to allow it to process multiple signatures on a binary?

Yes. Exactly.

on Windows 7 why can’t I install my attested-signed binaries in conjunction with a catalog file that I’ve generated with inf2cat and signed with my new, non-cross-certificate-having certificate?

You can. I’ve written about this extensively, most recently here.

Peter

@“Peter_Viscarola_(OSR)” said:

Are you trying to install on older Windows 7 that doesn’t have the KB to allow it to process multiple signatures on a binary?

Yes. Exactly.

I thought that the SHA-256 update also added the dual signature update, and you must have the SHA-256 update, right? Is supporting a non-dual-signature install of Windows 7 really even an option these days?

on Windows 7 why can’t I install my attested-signed binaries in conjunction with a catalog file that I’ve generated with inf2cat and signed with my new, non-cross-certificate-having certificate?

You can. I’ve written about this extensively, most recently here.

I’ve read that article. (It’s a good one.) Unless I misread, though, It doesn’t seem to describe exactly what I’m saying. The article talks about using an attested-signed driver package on Windows 7. I took that to mean: Microsoft-signed binaries, Microsoft-signed catalog file. Indeed, when I install a fully attested-signed package on Windows 7, I get the behavior described in the article: Mean Red Pop-up, but otherwise things work well.

My case however, has me discarding the catalog file that is generated by Microsoft. (Well, keep it for Windows 10, of course.) Instead, using inf2cat, I generate a catalog file, signed with my company’s certificate. (Said certificate no longer chains back to the MS Hardware Root; there is no cross certificate.) I use that catalog file on Windows 7 with the attested-signed binaries: Microsoft-signed binaries, catalog file signed by my company’s certificate. This gets me the nice, friendly “Do you trust [Company Name]?” pop-up instead of the threatening red pop-up, and it otherwise seems to work as well as the fully attested-signed package. That’s the crux of my question: It “seems to work as well,” but I’m not sure I fully understand the ramifications and wanted to make sure I wasn’t missing something subtle. If this works just fine, it make the whole cross-certificate going away nearly a complete non-issue. (I haven’t tried Windows 8.1, but I don’t care about Windows 8.1.)

you must have the SHA-256 update, right?

Yes. The Attestation Signature is SHA-256, after all.

Is supporting a non-dual-signature install of Windows 7 really even an option these days?

IMHO it’s as realistic as supporting ANY Win 7 system.

My case however, has me discarding the catalog file that is generated by Microsoft… Instead, … I generate a catalog file, signed with my company’s certificate.

Using your own signed (but not cross-signed) CAT file is a very clever idea indeed. Good thinking. That does sound like a nice option. I’ll try that as soon as I’m back in the office.

Thanks for that Mr. @Gabe_Jones!

Peter

@“Peter_Viscarola_(OSR)” said:

IMHO it’s as realistic as supporting ANY Win 7 system.

Touché! We have dropped 7 and 8.1 for new development, thankfully. I’m just preparing for the inevitable sustaining work.

Using your own signed (but not cross-signed) CAT file is a very clever idea indeed. Good thinking. That does sound like a nice option. I’ll try that as soon as I’m back in the office.

Thanks for that Mr. @Gabe_Jones!

Honestly, I was quite surprised it seemed to work. Glad to be of service.

My case however, has me discarding the catalog file that is generated by Microsoft… Instead, … I generate a catalog file, signed with my company’s certificate.

That is what we settled on here, as well. Since that’s already what we were doing even with cross-signing: Cross-sign binaries with our own certificate, then have Microsoft sign the binaries and produce the Microsoft-signed Windows 10 .CAT, generate our own separate .CAT that describes the now dual-signed binaries, and then cross-sign our “pre-Windows 10 platforms” .CAT file with our own certificate. Such that we have a single set of binaries, but two different .INFs depending on which platform we intend to install the binaries on.

What has changed now that cross-signing went away is that everywhere that says “cross-sign” now has just a normal non-cross-sign signature. Peter and others had promised that Windows 7 installation “doesn’t really care about the .CAT”, and they were right. No install-time check is balking at absence of a kernel policy signature during installation, and we see just the normal publisher verification prompt we’ve always seen.

Whether this is truly because Windows 7 “doesn’t care” – or whether this is because the check has always involved seeing whether the binary itself can satisfy kernel policy regardless of the catalog signature – I do not know. But with Microsoft’s attested signing signature on the binaries being installed on Windows 7, and no Microsoft root anywhere on the .CAT file signature, it’s working.

@Alan_Adams said:
That is what we settled on here, as well. Since that’s already what we were doing even with cross-signing: Cross-sign binaries with our own certificate, then have Microsoft sign the binaries and produce the Microsoft-signed Windows 10 .CAT, generate our own separate .CAT that describes the now dual-signed binaries, and then cross-sign our “pre-Windows 10 platforms” .CAT file with our own certificate. Such that we have a single set of binaries, but two different .INFs depending on which platform we intend to install the binaries on.

That is very similar to what we’ve been doing previously, except we used a single INF and had two separate CAT files. During install, the installer detects the OS version and renames the appropriate CAT file to the name expected by the INF file.

What has changed now that cross-signing went away is that everywhere that says “cross-sign” now has just a normal non-cross-sign signature. Peter and others had promised that Windows 7 installation “doesn’t really care about the .CAT”, and they were right. No install-time check is balking at absence of a kernel policy signature during installation, and we see just the normal publisher verification prompt we’ve always seen.

Whether this is truly because Windows 7 “doesn’t care” – or whether this is because the check has always involved seeing whether the binary itself can satisfy kernel policy regardless of the catalog signature – I do not know. But with Microsoft’s attested signing signature on the binaries being installed on Windows 7, and no Microsoft root anywhere on the .CAT file signature, it’s working.

Yep. I’m pretty happy with that. While we’ve dropped all pre-Win10 support and could thus get by with just MS signatures, it’s very nice to have this much easier option on the off chance we have to patch our older drivers.

What has changed now that cross-signing went away is that everywhere that says “cross-sign” now has just a normal non-cross-sign signature.

Something that sounds vaguely familiar, but seemed worth mentioning: By “simply putting a non-cross-signed signature everywhere we had previously been putting a cross-signed signature” in our build process, our driver actually failed to load on Windows 7. Specifically a boot-mode driver, so I think this is understandable in that the boot-time check has the leanest and most restrictive test due to not having a full running system yet.

“The problem” is that our non-kernel-policy signature is in “Signature index: 0 (Primary Signature)”, when viewed from SignTool’s perspective. The fact that we then subsequently sent that same driver binary to Microsoft for attested signing, and there is a Microsoft kernel-policy signature in Signature Index: 1 on the same file, is not enough to allow it to load on Windows 7. But the dual-signed binary does load on Windows 10 as a boot-mode driver.

Again, this all sounds very familiar, like this OSR list had encountered or documented somewhere “the cross-signed signature must be Signature Index 0 on your signed file” back when Windows 7 was the latest there was. And no, there was “no real point” to us continuing to put the non-cross-signed signature on the file, other than a customer viewing the signatures on the file and only seeing Microsoft’s name rather than also seeing our name.

So now our name lives on just in the VS_VERSION_INFO :smile:

1 Like

Yes, we have written here repeatedly that to load a Win10 Attestation Signed driver on Win 7, you must not first sign that driver.

Peter