Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Windows HLK Signing Error

David_ScheeleDavid_Scheele Member Posts: 13

So I have successfully completed a Windows HLK Test process and got a hlkx package out of it. I had created it unsigned.
I tried uploading that package to the partner center but they wouldn't accept it. Through further googling I found out it needs to be signed afterall.

We have a dedicated machine for signing in our company. On there we installed the Windows HLK Studio (Not the controller) and tried to sign it with the certification-dongle plugged in. But that got us the following error:

And the following Error-Details:

https://pastebin.com/G7rgM0xC

We tried running the studio with administrator privileges, but still the same error.

The Error Message clearly says
"Der OID-Wert war ungültig."
"The OID-Value was invalid."

Does that hint towards something being wrong with our ceriticate?

I couldn't find anything on this online. Pretty stumped now.

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,093

    ...Through further googling I found out it needs to be signed afterall.

    More specifically, it needs to be signed with a certificate that is registered with your dashboard account. Are you using that?

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    ... and it needs to be a proper code-signing certificate.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • David_ScheeleDavid_Scheele Member Posts: 13

    Hi Tim, hi Peter, thanks for the fast replies.
    Well we have uploaded the drivers to the partnercenter in the past too, just not as a hlkx package. They were signed with the same cert, so I'd guess it is the same code-signing certificate on the dongle and in the partnercenter.

    My general process is correct though? Just the HLK-Studio is sufficient for signing, no controller needed?

    I really have no idea how to proceed here. As I said, there are no infos on this online

  • CaptainFlintCaptainFlint Member Posts: 66

    @David_Scheele
    Not sure how HLK Studio signing works, but technically you should not need a controller for it. And if it was missing controller, it probably would not complain about the certificate OID. Where I work, we sign the packages on a separate machine which does not have any HLK tools installed at all, the signing is performed by a simple self-written program based on the code provided here, and it works fine.

    I would recommend to check the certificate's OID, just to be sure (previous accepting the signature might have been caused by less strict checks). In our certificates it's 1.3.6.1.5.5.7.3.3; I don't know if alternative code signig OIDs exist, but they can be checked in the databases online. If that's definitely OK, you could try signing using the program code from the MS documentation, see whether it works, and if not, what error it returns.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,093

    The requirements for a WHQL submission are not so strict. You absolutely need an EV certificate to establish a dashboard account, but once you have that account, your submissions can be signed by any certificate registered with your account. It doesn't need to be EV, it doesn't even need to be a code-signing certificate.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • RourkeRourke Member Posts: 65

    @Tim_Roberts said:
    your submissions can be signed by any certificate registered with your account. It doesn't need to be EV

    Not true. Microsoft has changed this policy:

    Important

    The certificate uploaded and used for all Partner Center submission packages has changed:

    Extended validation (EV) code signing certificates are required for all submissions.

    https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/update-a-code-signing-certificate

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,093

    I'm glad I'm retiring. I don't want to play in their yard any more.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • David_ScheeleDavid_Scheele Member Posts: 13

    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.

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 19

    @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.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    Mr @Alan_Adams ... Thank 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

    Peter Viscarola
    OSR
    @OSRDrivers

  • RourkeRourke Member Posts: 65

    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.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • David_ScheeleDavid_Scheele Member Posts: 13

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

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 19
    edited August 27

    @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.

  • David_ScheeleDavid_Scheele Member Posts: 13

    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?

  • David_ScheeleDavid_Scheele Member Posts: 13
    edited August 27

    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?

    Post edited by David_Scheele on
  • CaptainFlintCaptainFlint Member Posts: 66

    @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?

  • David_ScheeleDavid_Scheele Member Posts: 13

    @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.

  • CaptainFlintCaptainFlint Member Posts: 66

    @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.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    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
    @OSRDrivers

  • David_ScheeleDavid_Scheele Member Posts: 13

    @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.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,093

    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."

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 19

    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.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Internals & Software Drivers 15 November 2021 Live, Online
Writing WDF Drivers TBD Live, Online
Developing Minifilters 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online