Windows HLK Signing Error

Anybody actually TRY it? This lovely little note:

Points to a general page with multiple blog posts… none of which actually contain more information on this topic. And, maybe it’s just me but (a) that first bullet point is ambiguous and horribly written, and I don’t trust MSFT when it comes to these rules anyways, I’ve seen them change WAAAAY too many times.

Peter

1 Like

Thanks for the replies, very insightful and it’s nice to see some sympathy.

I guess I will look into signing the package without the studio. CaptainFlint already posted a link that looks promising. Does anyone know of any other ways or already useable programs for this?

Thanks again.

@“Peter_Viscarola_(OSR)” said:
Anybody actually TRY it?

Many much all the time. We have been submitting packages signed using our non-EV certificate for multiple years now. The last one I personally submitted and successfully signed was July 30, 2021.

The information in that page is simply out of date, and indeed what “what Microsoft originally said would be required.” Attested Signing, HLK and HCK package signing, and even UEFI signing have all worked successfully here using a normal non-EV code signing certificate we have associated to our Microsoft Partner Portal company account.

The only type of signing we currently see Microsoft direction of “still requires that the submission be signed with the EV certificate” is LSA Plug-In signing. But we have not yet had opportunity or need to sign an updated version of the LSA Plug-Ins we have, to actually test that requirement.

Mr @Alan_AdamsThank you. EXACTLY why I asked, because it seems “unlikely” that this policy would change, but…

FWIW, I filed doc bug (that has yet to be acknowledged) on that page requesting clarification. If this is, in fact, NOT the policy then the doc bug should flush this fact out.

Peter

Note the 2nd bullet item in the blue box (sha256) is now being enforced. It might be wise to consider non-ev certs as unsupported / undefined behavior pending a clarification that states otherwise. Good companies don’t write their code based on what some guy on the internet says works or doesn’t work, but rather follows the spec.

Note the 2nd bullet item in the blue box (sha256) is now being enforced

This just means you need to use a specific switch on sign tool.

It might be wise to consider non-ev certs as unsupported

No. It might be wise to just try it and not take the word of some guy quoting some random MSFT doc page that is just as likely to be wrong and right. In fact, in my own humble experience, I’ve certainly found that MSFT doc pages can frequently be LESS likely to be correct than the lived experience of a competent practitioner. Take, for example, all the places that it says that Attestation Signing does not work for Windows Server.

I’m not saying to base a product decision on this. I’m saying, just take something like the Toaster sample, make a driver package, and sign it with one of your registered non-EV certs… and see if it works. Then you’ll know. And post the results here, and then we’ll all know.

Peter

I will try to sign it without the HLK studio. I’ll get back to you all.

@Rourke said:
Note the 2nd bullet item in the blue box (sha256) is now being enforced.

I would also say it’s not “now”… it’s been happening probably since the same year when that information was posted. The block you’re talking about presumably was correct on both counts, “at the time it was written.” But regarding the EV certificate signing requirement for submissions, the information had subsequently become incorrect.

Microsoft stated in October 2016 that after initially intending that EV signatures would be required for all submissions, partner feedback had caused them to change this stance. They now allow submissions to be signed with any certificate you have uploaded to your company account on Microsoft Partner Portal (former Windows Dev Center, former Windows SysDev).

Microsoft stated in November 2017 that starting the next year, SHA-1 digests would no longer be accepted as part of a valid signature on submissions.

Both of these developments were discussed here in this forum, if you search back to those time frames.

IT WORKED!
We used the code snipplet from https://docs.microsoft.com/en-us/windows-hardware/test/hlk/user/hlk-signing-with-an-hsm#code-samples
(I’ll post the code here in case Microsoft decides to alter it or delete the page or something)

public static void Sign(string package, X509Certificate2 certificate)
{
  // Open the package to sign it
  Package packageToSign = Package.Open(package);

  // Specify that the digital signature should exist 
  // embedded in the signature part
  PackageDigitalSignatureManager signatureManager = new PackageDigitalSignatureManager(packageToSign);

  signatureManager.CertificateOption = CertificateEmbeddingOption.InCertificatePart;

  // We want to sign every part in the package
  List<Uri> partsToSign = new List<Uri>();
  foreach (PackagePart part in packageToSign.GetParts())
  {
    partsToSign.Add(part.Uri);
  }

  // We will sign every relationship by type
  // This will mean the signature is invalidated if *anything* is modified in                           //the package post-signing
  List<PackageRelationshipSelector> relationshipSelectors = new List<PackageRelationshipSelector>();

  foreach (PackageRelationship relationship in packageToSign.GetRelationships())
  {
    relationshipSelectors.Add(new PackageRelationshipSelector(relationship.SourceUri, PackageRelationshipSelectorType.Type, relationship.RelationshipType));
  }

  try
  {
    signatureManager.Sign(partsToSign, certificate, relationshipSelectors);
  }
  finally
  {
    packageToSign.Close();
  }
}

Took the thumbprint of our EV from the partner center page. Could then upload the package via the driver submission. After entering the relevant info i could submit it and it got approved all the way through. SUCCESS! But…

I can only select from the following signatures:

But I absolutely need the Windows 10 Validations.
On
https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/create-a-new-hardware-submission
it says:

Select Request Signatures as applicable. This option allows you to specify which operating system signatures (including allowable downlevel operating systems) should be included with your driver. Available certifications vary depending on your driver submission package, so there may not be any certifications listed. Note If you are signing a driver package for a single architecture, only include logs for the intended architecture. For example, to sign for x64 only, submit only the x64 logs.

“May depend on you driver submission package”

I can’t find an option for that in the HLK. Did I miss something somewhere?

IT WORKED!
We used the Code snipplet from
https://docs.microsoft.com/en-us/windows-hardware/test/hlk/user/hlk-signing-with-an-hsm#code-samples
Thanks again CaptainFlint!

In case Microsoft decides to change it or delete the page or something, here is the code:

public static void Sign(string package, X509Certificate2 certificate)
{
  // Open the package to sign it
  Package packageToSign = Package.Open(package);

  // Specify that the digital signature should exist 
  // embedded in the signature part
  PackageDigitalSignatureManager signatureManager = new PackageDigitalSignatureManager(packageToSign);

  signatureManager.CertificateOption = CertificateEmbeddingOption.InCertificatePart;

  // We want to sign every part in the package
  List<Uri> partsToSign = new List<Uri>();
  foreach (PackagePart part in packageToSign.GetParts())
  {
    partsToSign.Add(part.Uri);
  }

  // We will sign every relationship by type
  // This will mean the signature is invalidated if *anything* is modified in                           //the package post-signing
  List<PackageRelationshipSelector> relationshipSelectors = new List<PackageRelationshipSelector>();

  foreach (PackageRelationship relationship in packageToSign.GetRelationships())
  {
    relationshipSelectors.Add(new PackageRelationshipSelector(relationship.SourceUri, PackageRelationshipSelectorType.Type, relationship.RelationshipType));
  }

  try
  {
    signatureManager.Sign(partsToSign, certificate, relationshipSelectors);
  }
  finally
  {
    packageToSign.Close();
  }
}

After that I was able to upload the package to the submitting dashboard. After entering a bit of information I could submit it and it got checked, approved and signed.
SUCCESS!

But…

I was only able to select from the following Signature requests:

But I absolutely need this to be signed for Windows 10.
On
https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/create-a-new-hardware-submission
It says

Select Request Signatures as applicable. This option allows you to specify which operating system signatures (including allowable downlevel operating systems) should be included with your driver. Available certifications vary depending on your driver submission package, so there may not be any certifications listed. Note If you are signing a driver package for a single architecture, only include logs for the intended architecture. For example, to sign for x64 only, submit only the x64 logs.

Available certifications vary depending on your driver submission package

Did I miss an option in HLK somewhere? I looked it over again and couldn’t find anything.

We already have a few drivers submitted there and they do have been submitted for Windows 10 versions, so again not exactly sure where the problem is now.

Any ideas?

@David_Scheele
You are welcome, I’m glad you managed to get it working!

As for signing, the screenshot you gave it cut off too much. These are just the additional signatures. The main signature is listed below, in the Certification block:
https://i.imgur.com/L9BHobw.png
Does your submission have anything like that?

@CaptainFlint
Oh right, how did I miss that??

Yeah but it only shows “Windows 10 19H1 Update”. There is that question again, will I have to test for all Win10 Versions currently out there? Because from this it sure looks like it.

@David_Scheele
It shows the list of target OS versions that you’ve been running tests for (there can be more than one version, if you merge hlkx packages from different test runs for different targets). The real question is, how the selected version affects ability to install the driver on other Windows targets. Unfortunately, I don’t know the answer, but it would be logical to expect that backward compatibility is the primary scenario. Therefore I would suggest testing and signing for older Windows version (like 1607), and use these drivers for all Win10 versions (plus win7/8/8.1, if you need them). Unless your drivers require some newer Windows kernel features, of course.

There is that question again, will I have to test for all Win10 Versions currently out there?

No. We just check all the (applicable) boxes. The resulting driver package just all’s in whatever Windows 10 erosion.

Peter

@“Peter_Viscarola_(OSR)” said:
No. We just check all the (applicable) boxes. The resulting driver package just all’s in whatever Windows 10 erosion.

Sorry, I don’t understand.
You check the applicable boxes… in the submit form?
There are only the “Request Signatures” to check, for older versions.
What do you mean by “just all’s in whatever Windows 10 erosion”?

@CaptainFlint
Thanks again. I’ll be setting up a 1607 setup for now. Guess we will find out if that procedure is the correct “Microsoft-Approved” way.

This has always confused me a little. If you check only the oldest Windows 10 boxes, the resulting package loads everywhere. I’ve never been sure whether the checkboxes are trying to say “I work from here on”, or “I work up through here”, because they certainly aren’t saying “I only work here.”

Yeah, sorry… spell check on my iPad “helped” me with the last post. And I didn’t proof read as I should have.

What we do when we do a submission is we check everything that’s even remotely applicable. So, if we have a 64-but driver, we just check every 64-bit platform. And the driver package works on every version of Windows 10 we try it on.

Peter

I do believe we can say that for Attestation Signing, the selected platform(s) are the “minimum required versions”. Meaning as Tim Roberts said, just choosing the old TH1/TH2 platforms and nothing newer gets you all the Windows 10 platforms.

Selecting more Windows 10 platforms would add more entries to the operating system list in the .CAT file, but because there isn’t currently “a later version of Windows 10 which will consider a .CAT file attributed as TH1/TH2 to be invalid for the current platform”, there isn’t any practical effect from “selecting all Windows 10 platforms.” At least not among the x64 and x86 platforms we target; I won’t speak for ARM.

That said, we definitely did the same as Peter did, and just “selected all of them anyway” when making manual Attestation Signing submissions; even though I did test selecting just TH1/TH2 several times. But now that we have automated the Windows 10 Attestation Signing submissions, our automation is set to request only TH1/TH2 for all builds. And the .CAT is accepted as valid even on 21H1, Server 2016 and Server 2019; as well as current Server 2022 and Windows 11. For what it’s worth.

I do not yet HCK or HLK sign anything, although we’re working towards that. But the same question arises for me there. If I’m distributing a single binary (i.e. no Windows 10-specific build or binary; I do happen to be talking out our software-only drivers and network redirector; no hardware, PnP or Windows Update involved), and I have successfully HCK tested and signed even just for Windows 7 platforms, what benefit to Windows platform acceptance would come from testing for the Windows 10 platforms as well?

Because to my thinking this would be a similar scenario: There is no Windows 10 platform that currently would reject installation of a signed driver with a .CAT that specifies Windows 7 platforms. i.e. The default position of backwards compatibility forever in all versions of Windows means this “driver package created when Windows 7 was the only platform” still intentionally installs under current Windows 10 versions.

So in that case – similar to choosing TH1/TH2 in Attestation Signing as “the oldest platform so that your .CAT will be compatible with everything that came afterwards” – would a successfully HCK tested and signed package for Windows 7 be considered “the bare minimum needed to successfully load even on current Windows 10 platforms?”

Obviously this all changes if and when there is “a line drawn in the sand” where driver packages must have a .CAT targeted to something later than TH1/TH2 to be considered valid on a future Windows 10 / Windows 11 / Server 2022 platform. So I’m looking at it from the perspective of the way things are today.

So… up the thread a bit there was a question about whether the Microsoft policy has changed, and it was no longer possible to sign an HLK submission with a non-EV cert even if you had an EV Cert on-file with the Dashboard.

It’s finally been confirmed that the policy has, in fact, NOT CHANGED. As long as you have an EV Cert on file with the Dashboard, you CAN sign your submissions with a non-EV Cert (that you also have on file with the Dashboard).

The doc page has been updated, and I can go back to relaxing again.

Peter

1 Like